Doesn't this mean that no matter how securely your phone is locked, Apple (and probably the three-letter agencies) can always unlock it by installing an appropriate update?
Not necessarily. If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
BUT you must trust the entire Apple trusted chain to protect you.
> If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
But we already established unlocking is not possible, so going with the argument it's implied there is a side-channel. Nothing, but a secret in your brain is something only you can (willingly) provide. Especially not biometric data, which you distribute freely at any moment. RFID can be relayed, see carjacking.
If you can side-step the password, to potentially install malware/backdoor, that's inherently compromising security.
If the data you care about is encrypted with a token locked behind your passcode input, and it's not theoretically brute forceable by being a 4 character numeric only thing, then not easily, no.
Could they produce an update that is bespoke and stops encrypting the next time you unlock, push it to your phone before seizing it, wait for some phone home to tell them it worked, and then grab it?
Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
(It's also something of a mutually-assured destruction scenario - if you ever compel Apple to do that, and it's used in a scenario where it's visibly the case that 'the iPhone was backdoored' is the only way you could have gotten that data, it's game over for people trusting Apple devices to not do that, including in your own organization, even if you somehow found a legal way to compel them to not be permitted to do it for any other organization.)
> Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
The attack situation would be e.g. at the airport security check, where you have to part with your device for a moment. That's a common way for law enforcement and intelligence to get a backdoor onto a device. Happens all the time. You wouldn't be able to attribute it to Apple collaborating with agencies or them using some zero-day exploit. For starters, you likely wouldn't be aware of the attack at all. If you came home to a shut-down phone, would you send your 1000$ device to some security researcher thinking it's conceivably compromised, or just connect it to a charger?
If you can manually install anything on a locked phone, that's increasing the attack surface, significantly. You wouldn't have to get around the individual key to unlock the device, but mess with the code verification process. The latter is an attractive target, since any exploit or leaked/stolen/shared key will be potentially usable on many devices.
But eff isn’t going to come to my aid if it’s isn’t a big story, like wireguard. We’re all just arguing circularly around the fact that companies with massive footprints can and do operate in a manner where it’s assumed that zero access is the industry standard for “normal users”
Qubes OS is a niche security-oriented operating system that runs everything in VMs with about 70k users [0]. Even less users contribute with amazing things like running in RAM [1] or using very minimal VMs with Debian and Fedora [3] to minimize the attack surface and bloat.
And at this point, it appears running code through an LLM to translate it eliminates copyright (and thus the licence), so $Anycorp can use it.
Our stuff is AGPL3 licenced and if this present trend continues we might just switch to MIT so at least the little guys can take advantage of it the way the big guys can.
I think the whitewashing of code through LLMs is still unproven if it actually works for a reasonably complex project and also it’s still kind of legal Wild West - I think no one knows for sure how it will work out.
Only if they provide the software or software as a service. Then I suspect it's good enough if the modifications or forks made are shared internally if software is used only internally, but on the other hand I'm not a lawyer.
Employers might argue that such internal use and distribution would fall under the “exclusively under your behalf” clause in the GPLv3, which is inherited by the AGPLv3.
In reality most $Evilcorp have policies against AGPLv3, which is why projects can make moneh selling a less-restricted enterprise license for the same code.
I often hear this but I don’t really understand it. Not saying you need to explain it to me but what is the issue with AGPLv3 that turns those corporations away?
To my non-lawyer eyes it looks like MIT or Apache2 but modifications need to be made public as well.
If you don’t make any modifications then it should be fine?
Or do most $Evilcorp aim to make modifications?
Or is AGPLv3 something like garlic against vampires (doesn’t make sense but seems to work)?
AGPLv3 includes that “distribution” includes essentially communicating with the service over the network, as opposed to the GPL concept of like, sending a shrink wrapped binary that someone downloads and runs themselves.
So basically they are worried that they have no way of avoiding one or more of their tens of thousands of engineers “distributing” it to customers by including it in some sort of publicly accessible service.
AFAIK there’s no settled case regarding what level of network communication qualifies - like if I run a CRUD app on Postgres and Postgres was AGPL, am I distributing Postgres?
Now the second part is that you only have to give out your changes to the AGPL software to those that it was “distributed” to. Most people aren’t changing it! If anything they’re just running a control plane in front of it…
but it goes back to the corporate legal perspective of “better safe than sorry” - we can’t guarantee that one of our engineers, isn’t changing it in some way that would expose company internals, then triggering a condition where they have to distribute those private changes publicly.
This is the point. They can use and modify it, but they also have to share their modifications, i.e., help its development. Yet most megacorps never even touch this license.
Run OpenSnitch for a while and you'll quickly realize how much of your system does phone home. Off the top of my head:
- GNOME Shell (extension updates without a way to disable this, weather),
- GNOME Calculator (currency exchange rates),
- NetworkManager (periodic hotspot portal checks in most configurations),
- GDB (debuginfod enabled by default),
- Firefox (extension updates, push notifications, feature flags, telemetry, ..., some parts cannot be disabled),
- VSCodium (Open VSX callbacks even when installing extensions from disk with updates disabled, JSON schema auto-downloads, extensions making their own unsolicited requests, ...),
- Electron (dictionary updates from Google servers, no way of disabling; includes any application running on top of upstream Electron, such as Signal, Discord, etc.),
- GoldenDict (audio samples fetched from the Internet on word look-up, no way to disable)
Of course, this is nothing compared to Windows [0] and macOS [1], but the malpractice of making Internet connections without asking, by default, has unfortunately been finding its way everywhere since modems stopped making audible sounds.
Having read about PRISM and seen the leaked dashboards of Paragon Graphite (said to be used by ICE), and with LLMs bridging the gap between mass and targeted surveillance, I don't want any of this.
Approximately 10-15 years ago I used an early Android app that synced contacts across multiple (local) accounts and deduplicated and merged them. It had Internet permission for some reason; on asking the developer why a dedicated contact management app would need to go online (in a time where I was using XPrivacy to prevent other apps from seeing my contacts), they said there was no real reason for it, and it was removed in an update two days later. This is the only time I've ever seen an app remove the ability to access the internet, and I really wish it was more common.
Of course, about 5-6(?) years ago Google removed it from both the play store and my devices (I allowed it because silly me assumed I could still get it again) because it requested a sensitive permission and didn't support runtime permissions.
Per se? No, maybe with the exception of GNOME Shell which literally runs code from the Internet unsandboxed. Can the traffic they silently generate be used for malicious purposes? Absolutely.
Wasn’t it KDE that had malware in its theme store not too long ago? Let that sink in for a bit. You changed around some icon themes and it executed arbitrary code.
And let’s not pretend that kde wouldn’t have an extension system if it could - but it’ll never have one because implanting one in that c++ spaghetti nightmare will never happen.
But if not, I'm not criticizing GNOME in isolation here. It's just what I use and what I'm most familiar with. KDE has the same issues and it does have an extension system too. It's called KNewStuff.
Problem with updates is that without automatic ones, users could stay on outdated systems and possibly get hacked through some vulnerability(of which there are many). While on the other hand, having explicit confirmations for each network request would be crazy annoying.
Maybe some middleground of having the tool OP sent built-in would be a good option.
I run all my systems with all outgoing connections blocked by default, and yes, it is annoying.
But it wasn't always this way, and so, I don't think it has to be. People just need to start paying attention to this.
The impact of a lot of those vulnerabilities would be mitigated if the affected programs didn't connect to the network in the first place.
As for updates in general, I really like the model adopted by Linux update managers and BSD port systems. The entire repository metadata is downloaded from a mirror and cached locally, so the search terms never leave your machine. Downloads happen from the nearest mirrors, there's no "standard" mirror software (unless rsync and Apache count?) so they don't report what was downloaded by whom back to any central system and you can always host your own. Everything is verified via GPG. And most importantly, nothing happens on its own; you're expected to run `apt/dnf update` yourself. It won't randomly eat your bandwidth on a metered connection or reveal your OS details to a public hotspot.
Simple, non-invasive, transparent, (almost) all-encompassing, and centrally configurable.
It contains Firefox and Chromium. You are right that they may call home, but at least it's very limited and easily configurable. Could be too much for you but fine with me. Also Debian does change their config by default to minimize privacy issues: https://news.ycombinator.com/item?id=32582260
It's far from easy in the case of Firefox [0], and the last time I tried, some .mozilla.com domains would still get pinged. Chromium doesn't even have an official guide. The only options I found to be reliable are source-level patches, i.e. ungoogled-chromium and LibreWolf.
Note that LibreWolf still leaves some of the stuff on for you to manually disable (dom.push.connection.enabled, extension updates).
I agree that push connections should be disabled. Maybe it can prompt you the first time you try to subscribe to one as to whether you're like to turn them on; this would annoy me personally, but also not break features by default. The annoyance hardly matters as websites already put an in-page prompt up before using the API, iirc because of Apple restrictions.
Enabling extension updates by default seems like a smart thing, though, as long as you can turn them off easily (there should really be a setting for this), and possibly a 6-month reminder to update them (similar to the refresh your profile reminder when you haven't used the browser in for a while). Extension updates happen, and many of the most widely used extensions (eg. ublock origin) really should be updated every time it's available. Better that than having the extensions go online to fetch and run arbitrary payloads because you know they will if disabling updates gets popular enough.
Waydroid allows to run Android apps that don't require SafetyNet. If your bank forces you into the duopoly with no workaround, it's a good reason to switch.
Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.
You can also use SB with your own keys (or even just hashes)...just because Microsoft is the default included with most commercially sold PCs—since most people use Windows on their PCs—doesn't mean SB is controlled by them. You can remove their signing cert entirely if you want. I have done this and used my own.
Plus they signed the shim loader for Linux anyways so they almost immediately gave up any "control" they might have had through SB.
Won't removing the Microsoft key prevent UEFI option ROMs from PCIe cards from loading when Secure Boot is enabled?
Is it even possible to install firmware containing an oprom resigned with a custom key onto, say, a modern Nvidia GPU, without the entire firmware bundle being signed by Nvidia's own key?
That's the idea! "Allow" the user to install any apps they choose. (I put "allow" in quotes, to emphasize how bizarre it is that a few platform vendors get to decide what all of humanity is "allowed" to do with their computing.)
GP here. I agree in spirit but there’s a technical difference between ”approved to distribute” and ”approved in an App Store”. Specifically, you can distribute software for Windows and Mac outside of their stores, but you still need to have a code cert which means you’re under their mercy. This is the model Google wanted to transition Android to recently: keeping the APK path (no App Store) but gatekeep developers through signature enforcement etc.
reply