1. Do a request to `chrome-extension:///`. It's unclear to me why this is allowed.

2. Scan the DOM, look for nodes containing "chrome-extension://" within them (for instance because they link to an internal resource)

It's pretty obvious why the second one works, and that "feels alright" - if an extension modifies the DOM, then it's going to leave traces behind that the page might be able to pick up on.

The first one is super problematic to me though, as it means that even extensions that don't interact with the page at all can be detected. It's unclear to me whether an extension can protect itself against it.

Citation needed?

> This was common knowledge after the Snowden stuff.

Not to me, it isn't? As far as I'm aware, most of the Snowden stuff were centered around PRISM, which allowed widescale wiretapping of internet backbone, as well as agreements with big cloud providers to allow tapping into their data.

I haven't seen anything indicating that there was widespread compromise of personal computing devices at such a deep level of the root of trust. I haven't seen any indication that the NSA has a backdoor in the earlyboot CPU of any device, whether that is the Qualcomm boot processor, the Intel Management Engine or the AMD Platform Security Processor (which all have similar capabilities and hidden firmware).

If I missed anything/have links to research into these backdoors, I'd like to see them!

Now whether this downside justifies the massive problem it causes on false positives...

Don't we have enough examples showing that this simply cannot work long-term, because the for-profit enterprises will _inevitably_ grow larger than the government can handle through antitrust? And once they reach that size, they become impossible to rein in. Just look at all the stupid large american corporations who can't be broken up anymore because the corporation has the lobbying power and media budget to make any attempt to enforce antitrust a carrier killer for a politician.

I think it's very myopic to say that corporate structure is the "best solution".

Says who? You can totally do code reuse using manually-written dynamic dispatch in "rust without traits". That's how C does it, and it works just fine (in fact, it's often faster than Rust's monomorphic approach that results in a huge amount of code bloat that is often very unfriendly to the icache).

Granted, a lot of safety features depend on traits today (send/sync for instance) but traits is a much more powerful and complex feature than you need for all of this. It seems to me like it's absolutely possible to create a simpler language than Rust that retains its borrow checker and thread safety capabilities.

Now whether that'd be a better language is up to individual taste. I personally much prefer Rust's expressiveness. But not all of it is necessary if your goal is only "get the same memory and thread safety guarantees".

This is very different from, say, the minio situation, where they were actively removing feature before finally closing development down entirely. Whether tailwind will end up going down this route, time will tell. But as of right now, I find this reading to be quite uncharitable.

This makes writing robust code under those systems a lot easier, which in turns makes debugging things when it goes wrong nicer. Now, I'm not going to say debugging those systems is great - SELinux errors are still an inscrutable mess and writing SELinux policy is fairly painful.

But there is real value in limiting where errors can crop up, and how they can happen.

Of course, there is stuff like FUSE that can throw a wrench into this: instead of an LSM, a linux security product could write their own FS overlay to do these kind of shenanigans. But those seem to be extremely rare on Linux, whereas they're very commonplace on Windows - mostly because MS doesn't provide the necessary tools to properly write security modules, so everyone's just winging it.

And then you get security product who have the fun idea of removing privileges when a program creates a handle (I'm not joking, that's a thing some products do). So when you open a file with write access, and then try to write to the file, you end up with permission errors durig the write (and not the open) and end up debugging for hours on end only to discover that some shitty security product is doing stupid stuff...

Granted, thats not related to ACLs. But for every OK idea microsoft had, they have dozen of terrible ideas that make the whole system horrible.

I personally doubt SAK/SAS is a good security measure anyways. If you've got untrusted programs running on your machine, you're probably already pwn'd.

The bigger problem is if the UK has an extradition treaty with the country you live in.

It has, though it has mainly been under the "breach of contract" approach and not under "copyright infringement" approach. See https://en.wikipedia.org/wiki/Open_source_license_litigation

To give you an example: I can release a binary (without sources) under the MIT - an open source license. That will give you the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of said binary. In doing so, I would have released the binary under an open source license. However, most people would agree that the software would not be open source under the conventional definition, as the sources would not be published. While people could modify it by disassembling it and modifying it, there is a general understanding that Open Source requires distributing the _sources_.

This is very similar to what is being done here. They're releasing the weights under an open source license - but the overall software is not open source.

It's still unclear whether it really is removed. They turned scanning into something voluntary, and then said big chat providers must do _something_ to monitor abuse. It seems _very_ likely that the regulatory bodies/courts will decide that the bar they must clear to meet this "something" is client-side scanning.

And I agree that the regulation still has a lot of hoops to jump through to be implemented, and will likely be further tweaked. But it's _very_ important to keep raising our concerns, otherwise there will be no pressure to change the currently problematic legislation.