Yes social engineering can be incredibly effective. I completely agree, but there is a bit of an obsession with it these days and imo it’s over indexed, because at the end of the day the type of social engineering detailed in that report typically just provides access.

In some cases, the target is important enough and has enough organizational power that accessing the network as them is sufficient, but that’s not often the case. What that means is that in those other cases social engineering (which in that report you cited is often just phishing) is providing, typically, internal network access. An attacker will have to move through the network and exploit software typically to continue their attack. There are many points in this chain that the weakness lies in software or configuration. If effort was placed on making those systems better it would likely see better results than hyper focusing on the social engineering, which is significantly more difficult to stop, especially with all of the things you mentioned on the horizon.

My point is then that even if it is a part of 74% of breaches, according to Verizon, it’s not necessarily sufficient and is often paired with software level exploits.

And I know this because my company does plenty of red teaming, and we use social engineering but at the end of the day the more interesting result comes from a software exploit or just abusing a weak configuration.

I have found the exact same type of bug shown here probably over a dozen times, most of those long before AI was writing code.

Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don’t make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by “shit programmers” misses the real issue: there was either no system or an insufficient system to test features and define security requirements.

I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than GET /secrets.json.

There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn’t.

I don’t think they meant everything literally goes in the same direction, but more like what is discussed here https://www.scientificamerican.com/article/do-we-live-inside-a-black-hole/ (this article was shared elsewhere in this post)

Add SepiaSearch URL as default search index

I updated my weird wording but… you and they said something about the default [index] URL

If OP asked when global search was implemented the answer is 5 years ago. If they asked when SepiaSearch became the default index then sure, ChatGPT was wrong, but I’d bet they asked the first question

https://github.com/Chocobozzz/PeerTube/releases/tag/v2.3.0

ChatGPT is correct? The irony of people confidently asserting that ChatGPT is wrong, while being wrong, seems to be lost on the crowd here. Kinda makes you understand why ChatGPT is often so confident even when wrong.

In May 2020, Framasoft published a roadmap of the software for the later half of the year and created a fundraising campaign requiring €60,000 for aiding the development.[18] Five months later (in October 2020), PeerTube announced that they reached their fundraising goal of €60,000 after a €10,000 donation from Debian.[19][20] Throughout the later half of 2020, PeerTube has added features such as global search, improved playlists, and more moderation tools

End 2020, the meta-search engine Sepia Search was launched by Framasoft, allowing a global search on all PeerTube instances at once. As of 2021, Sepia Search covered close to 800 individual instances

https://en.m.wikipedia.org/wiki/PeerTube

https://github.com/Chocobozzz/PeerTube/releases/tag/v2.3.0

I don’t want to tell you one way or the other because it’s kinda dubious anyway, but if all services run as the same user the need for root is kinda moot when it comes to crossing between services or expanding the scope of an attack. Of course it is better than all things running as root, but if I popped a machine as some “low privilege” user that still had access to all running services I’m not sure I’d care so much about escalating to root.

Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I “escape” containers all the time in my job because of configuration issues, poorly considered bind mounts, or the “contained” service itself ends up being designed to manage some things outside of the container.

Might be valid to not consider it with the services you run, but that reasoning is very wrong.

It did give the right answer…

Gonna be even worse now too with the National Park Service cuts: there are so many foreign tourists at the parks. As there should be too! Our National Parks are amazing!

You can unlock the bootloader on a Pixel in about a minute.

I can understand some people finding the whole process a bit daunting, but it’s not actually that difficult with Graphene.

LXC is containerization. Both it and Docker are using the same kernel APIs.

Not really, but I’d probably try to organize those into sub structures where it made sense. A data structure holding the UI state and FFT data all flat is kinda messy imo since it becomes unclear what is actually required where.