> And with this much at stake, they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
LAPSUS$ was prolific by just bribing employees with admin access. This is far from theoretical. Just imagine the kind of money your average nation state has laying around to bribe someone with internal access.
I started to write a comment about how low they probably were able to bribe people for but found this article [0] which put the number higher than I expected:
> One of the core LAPSUS$ members who used the nicknames “Oklaqq” and “WhiteDoxbin” posted recruitment messages to Reddit last year, offering employees at AT&T, T-Mobile and Verizon up to $20,000 a week to perform “inside jobs.”
That said, this is but one instance and I'd imagine that on the whole they are able to bribe people at much lower numbers. See also: how little it takes to bribe some government officials.
The cost for access can be surprisingly low. Not all that many years ago it was pretty cheap to pay an editor at wiki or DMOZ or any of a few dozen other 'trusted sources' on the internet to get something added, or removed. I stopped traveling in those circles a long time ago, but I know that they are still very active and the cost is still surprisingly low.
While not code level access, these sorts of things are far more common than anyone wants to admit to.
If they were looking to access government back doors at these providers then it would not be your usual hack - and worth a lot more. I have no idea if this is how an entire domestic surveillance network got strung up, but it would make sense at those numbers (though those numbers still seem very low for such a betrayal and potential consequences)
And because it is surprisingly difficult to distinguish between 'oops' and 'malice' a lot of the actual perps get away with it too, as long as they limit their involvement. In-house threats are an under appreciated - and somewhat uncomfortable - topic for many companies, they don't have the funds to do things by the book but they do have outsized responsibilities and pray that they can trust their employees.
Also hard to track when the offending employee is a contractor or simply exits stage left to another company. Where he could also offer up his services to make another "blunder" that would grant access to these groups.
Another framing would be we will release your mother if you plant this backdoor. Could be a good plot for a short story? This attack vector has been available to Nation States since ages ago, stealing blueprints etc. Why are we acting surprised that this could be applied more effectively in digital age?
But on the other hand, adding LLM with strong guards (not yet here but doable for popular attack vectors) into the human loop can drastically eliminate insider factor, imho.
> they can afford to simply buy your software dependencies, or to offer one of your employees some retirement money in exchange for making a "mistake".
Orthogonal, but in similar spirits: the FAANG part of big tech paying less, doing massive layoffs, and putting enormous pressure on their remaining engineers might have this effect too in a less directly malicious way.
Big tech does layoffs, asks engineers to do "more". This creates a lot of mess, tech debt, difficult to maintain or SRE services. Difficult to migrate and undo, difficult to be nimble.
These same engineers can then leave for startups or more nimble pastures and eat the cake of the large enterprise struggling to KTLO or steer the ship of the given product area.
> This game is not suitable for those who are easily disturbed. Individuals suffering from anxiety or depression may not have a safe experience playing this game. For content warnings, please visit https://ddlc.moe/warning.
Then the plus version even added in-game content warnings?
* It's possible - very likely even - that even if somehow P=NP, the fastest algorithm for any NP problem turns out to be something like n^1000, which is technically P, but not practical in any way.
* The proof may not be constructive, so we may just know that P=NP but it won't help us actually create an algorithm in P (nitpick: technically if P=NP there's a construction to create an algorithm that solves any NP problem in P time, but it's extremely slow - for example it involves iterating over all possible programs).
> What this tells me is that the actors with the best models (and Anthropic apparently has one so good and expensive it is outstripping compute supply) they will find the exploits first and probably the ones that are hardest to find
Presumably we would not give the AI models to the "good guys" because then they would also find and patch these vulnerabilities?
Someone's "good guys" are just someone "bad guys". Access to a valuable resource/tool that provides some sort of power and utility will be just another contended item.
> The current Japanese leader is also a war mongerer, so I'd bet they also threatened to enter the war on USA's side if their ships weren't allowed to pass.
The amount of misinformation foreign people have about Takaichi-san is staggering. She is by no means a "war mongerer" and the Japanese constitution has clear limits that prevent Japan from doing virtually anything. The reason why Japan can get a pass is because they specifically have diplomatic relations with Iran, and when she met with Trump, she promised absolutely nothing due to constitutional limits.
The most an average person in the west knows about Takaichi is that she "said" Japan would go to war with China for Taiwan. That's of course not true, but the person you're replying to also thinks Spain is on Iran's side. They are clearly misinformed or lying to fit their narrative.
Why would she promise anything to Trump? She just wants Iran to let them through, USA isn't blocking anyone here, USA isn't a part of that conversation.
In non-English texts it is not unusual to see English honorifics like Sir, Lord, Lady, Duke etc. or even Dr., Mr., Mrs.
Similarly, in English texts it is not unusual to see foreign honorifics besides the actual names.
It is quite frequent for someone who otherwise does not speak another language to address foreigners as they would be addressed in their own language in formal situations where politeness is expected, e.g. using Herr or Frau for a German, and so on, or using Takaichi-san or Takaichi-sama (more formal) instead of translating that to Mrs. Takaichi.
I think that when speaking about a prime minister, formal language is not inappropriate.
Trump is probably the most obvious chief of state whose name would look completely inappropriate in the context of using formal polite language, but this should have been an exception.
It seems incredibly silly to me that this is being rushed into systemd and other linux components. I understand Apple making changes, and even Canonical, but systemd is not run by one corporation and there is no reason to adhere to a badly written law. Why play along with the charade? If root is root, the "age verification" field does not make any sense.
Why are these changes being made on a worldwide basis when the laws that have been introduced are a relatively small fraction of the world? California isn't going to go after individual systemd maintainers. Will California go after Torvalds? I doubt it. Apple? Surely, but this is, quite frankly, a ridiculous thing to even suggest for inclusion into these setups.
Open source is driven by contributions. Most of the time, if someone wants a feature, implements the feature, and submits a reasonable PR to a project, that project will have the feature. In this case, the PR appears to have been written by someone who is not a regular SystemD contributor, and (through a bit of Googling) works for a FinTech company with no obvious interest. I can't comment on why that individual wanted to add support.
However, once someone added support, the question for SystemD is not if it is worth implementing, but if it is worth merging. At this point, it becomes a simple case of "the most intolerant wins". For people who care about complying with CA style laws, this feature is critical. For people who don't care, this feature is fine. I doubt it will even make it on mosts lists of SystemD feature bloat that most people don't care about.
This is the same reason a bunch of the food in your pantry is certified kosher. No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
> No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
Contrary to perceived politics, many Muslims will eat kosher food because it's a superset of halal rules (excl. alcohol).
It's a globally consolidated certification through organizations like the Orthodox Union. This is unlike halal which is local and has many scammers offering to pencil whip compliance. This means many Muslims will prefer kosher to "halal" food to avoid due diligence on the certification agency.
To tie this into age-verification, companies and ecosystems will use the strictest method that makes them globally compliant. Consumers will prefer that convenience even in the presence of intense political beliefs.
A bank that uses seamless OS-level age checks everywhere will win against one asking manually in the jurisdictions it isn't required.
I hope everyone’s bank knows how old they are— what with all the documentation we have to cough up to keep us safe from Terrorism , patriot act, 9/11, never forget, etc
Two corporations, e.g. Canonical and Red Hat, might suffice.
I hope everybody remembers how systemd was thrust upon the community by having Gnome largely depend on it. This was mostly done by efforts of Red Hat, and that sufficed.
Okay, but why do this now? If it’s such an important feature and unrelated to the barrage of legislation, why was this not implemented a few months or years ago?
Because someone came with a pull request for this; this additional field was meant to support a feature in something else they were working on (an xdg portal). It was a simple PR that addressed a need that the programmer had. And it was accepted.
California has both vendors and clients that are big enough to warrant immediate compliance. A very measurable chunk of Linux is from corporations, most major advancements are corporate backed in some way.
I think the most obscene thing here is that macOS is now littered with permission prompts for camera, background execution, etc, but makes no effort to stop even industry partners from spraying the disk with dozens of files that can’t be removed easily.
That's because this particular sort of cyber security is merely theatrics with the goal of reducing user agency and increasing paranoia and vendor lock-in. The user facing friction is the goal. There will always be scams and viruses; the only practical outcome will be that you have less control over your computer, and Apple/MS/Google have more. See: Sideloading, Wayland, UWPs, iOS JIT, Windows XP and 7 still being used for accessibility
I often have apps on my Mac or iPhone that ask for permission to see my camera, microphone, contacts, etc etc that I don't want it to see. But I do want other apps to be able to access those things.
Being able to stop those apps from accessing before they do instead of trying to fix it after is incredibly valuable.
Sure some users just accept everything, but that is not an argument against them existing in the first place.
Those examples are very reasonable. However I also had Mac OS suddenly treat all m4a files on the system as potential malware and it blocked any attempt at opening them. Why did it do that? Because I checked the "set as default app" option, one minute after I had already opened the same file using the same application. The only way to open the files was by entering the password in the settings app each time - but re-setting the same app as default in the file's Get Info dialog got rid of that "protection" system-wide without any password prompts or extra permissions. I don't see how that was supposed to help with security.
This has been a thing long enough for online guides to exist that explain how to get rid of it. Fortunately, because setting the default program in a second place to get rid of a security barrier wasn't my first guess. When does a bug start to become an undocumented feature?
We are moving away from the old world where you can trust the applications you are running on your computer, to today's world where you can't. The unix permission model is based on apps running as your user having access to every device and file you, the user, have access to. The threat was "other system users trying to access your files and devices" but now the threat is "applications you run trying to access your files and devices." OS vendors have been slow to adapt to this new threat model.
Even today, any rando application I download and run can read and/or write to any file on my system that I own and have permission to read and/or write, unless I go out of my way to run it in a chroot, a container, a jail or whatever. That's just poor security in a world where nearly every commercially developed application is an attacker.
To be fair, this is partly because of the internet.
If you install random apps and it destroys your PC, you can fix that by having backups. By contrast on work computers with important data, everything is supposed to be locked down and you can't install random apps. But then we started to increasingly connect devices to the internet.
Now gaining access over a smartphone essentially means being able to send payments via the banking apps. People are sending money with crypto so they are susceptible to simple clipboard swap attacks that are almost impossible for the user to detect until it happens. Then there is all the personal data that can be stolen that can be used for other attacks in the future.
Essentially the amount of damage you can take by losing access has increased much faster than the security devices meant to prevent.
To make matters worse, the security devices that are marketed to the average user tend to be exploitative rather than trustworthy (e.g. OneDrive).
It feels like instead of protecting users developers seem more interested in creating something that only does half of the job and then blaming the user for not knowing how to do the other half, so a comprehensive solution for the problem is never created.
I think there are a lot of things that users can be protected from:
1. Protect users from attackers external to the computer
2. Protect users from attackers who are other users on the computer
3. Protect users from applications run by other users on the computer
4. Protect users from applications they themselves run on the computer
5. Protect unprivileged (non-root) users from their own actions
6. Protect privileged (sudo/root) users from their own actions
OSes have been historically OK at 1-3. Not great or even good. There have been a lot of remote code vulnerabilities and local vulnerabilities over the years.
OSes have pretty much ignored 4 until maybe a decade ago, and are making token progress toward it, but I don't think many of them take it very seriously.
OSes have instead started to crack down on 5-6, which I'd argue isn't even the job of an OS.
macOS now implicitly sandboxes your Documents, Downloads, and Desktop folders. Random apps can’t read from those locations without triggering a security prompt.
> this particular sort of cyber security is merely theatrics with the goal of reducing user agency
Literally all security features carry the hazard of being used for oppression and being ineffective or counter-effective. That's how constraints work.
You need two things for a security feature:
- a segmentation under which a behavior is considered unsafe / unsecure (arbitrary, subjective)
- a technical solution that constrains the behavior of <thing> in <usage context> so that the aforementioned is mitigated
So something being "a tool of oppression" or "a tool of safety" is a matter of your alignment with that segmentation. And it being a theater or not is a matter of functional soundness given a threat model. So is its tendency to become counter-effective.
Constraints are just constraints. Whether they're effective and whether you're disadvantaged by them are both separate, independent matters. Empirical too.
I think we're on the same side in principle. The ability for people to interact with the wider world using general purpose computers that they fully control should be sacrosanct, and attempts to interfere with that such as remote attestation, app store exclusivity, and developer verification are evil.
Sandboxing apps by default is not that. The principle of least privilege is good security. If I vibecode some quick and dirty hobby app and share it with the world, it's better if the robot's mistake can't `rm -rf ~/` or give some creep access to your webcam.
The user should be able to override that in any way they see fit of course.
I think there's some controversy regarding that programs are limited in what extent they can access each other. You need sudo to do global hotkeys/keylogging, probably accessing pixel contents of other apps, etc. I suppose they mean it only prevents some specific threats while leaving open goals in other, even more easily exploited places
You often cannot even tell what the permission prompts are for. Sometimes they have generic names like a programming language is requesting something. Not sure what that’s about.
those are interpreters, the language is interpreted by a binary called `ruby` or `python`, for example, so that happens to be the process that's requesting the permission
LAPSUS$ was prolific by just bribing employees with admin access. This is far from theoretical. Just imagine the kind of money your average nation state has laying around to bribe someone with internal access.
reply