Obviously it’s impossible to know unless you’re sitting in on union discussions, but there is a perverse incentive at play. If one fears automation taking their job, I could see resistance to allowing any automation “foot in the door” so to speak.
If anyone is downvoting because they think this is wrong (vs just being low content and largely unhelpful) I’m interested in what alternative explanations exist.
This tech has existed for many years in motor vehicles and works reasonably well in far more complex environments than literal rails. It doesn’t seem at all like a challenging technology problem.
The things that come to mind are: failures of politicians to enact requirements, negligent or greedy rail infrastructure and/or train ownership, and unions afraid of lost jobs.
> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
You don't get such prompts on macOS if the app uses the system file picker, which they nearly all do.
You will get prompts for certain sub-directories of $HOME if the app directly opens them using POSIX or similar, so for example, anything running in a terminal emulator, or inside a virtual machine. Developers will see these prompts a lot more often than regular users do. MacOS doesn't let apps read directories but not files.
This is the sane solution. And not unlike what Android does in the end, with the difference that they have a share panel instead of an open panel: so you initiate the process from the app that owns the file rather than the one that wants to access it.
But GUI apps on Linux are so fragmented that getting everyone to use the same open panel is hopeless.
> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
And what is even the concern about that? I don't mind software knowing that my ssh key is in ~/.ssh/id_ed25519. Maybe if you see a 500 byte ~/.ssh/id_rsa that's an issue, but then the real issue is the tiny key
Thinking about threat scenarios of directory structure access, I'd be much more concerned about exposing that I have ~/documents/work/mergers/2027/[secret]_WarnerBros-Fox.docx
But only being able to see the file name would still be a huge improvement over being able to open the document and exfiltrate it
macOS does this for select directories. You either give access to all of `Documents` or none. It's also not great for notification fatigue, as you get like 8 popups at once in iTerm2. If you choose not to give access to a directory, you'll need to go to system settings to change this.
So, for a "better" system, we'd need to ask for every directory and you better hope the program doesn't try to glob all files in every directory and overload the user in prompts. Or you can "Allow all" or something, and then we're back at square one where the program has too much access.
The cybersecurity refusals, the biology refusals: https://blog.stephenturner.us/p/benchmarking-ai-biosecurity-... and the sexual activity refusals are all a form of censorship. Their purpose is the same as what the Chinese government would claim as being the reason to censor information on things like Tianenmen square.
I worry that rational takes like this end up completely lost in the battle between motivated parties who yell far louder, but have minimal investment in actual outcomes for those who will be depending on these technologies. The debate over self-driving vehicles is another example.
One minor off-topic comment, I like the quiz at the bottom of the article. It could be neat to have sites implement something like this to discourage people from commenting without reading and absorbing some of what they've read. It seems it would be fairly straightforward to implement with an LLM summary/questions.
Maybe this is a dumb comment, but couldn’t you just turn the phone off? You’d have to trust that the setting to disable Bluetooth when powered down is reliable and configured correctly, but if your use case is that sensitive even carrying a smartphone seems questionable.
No; if a phone has both a non-removable battery and a baseband modem, then various laws require that modem to be wired directly to that battery (and to the phone's microphone) and to able to be activated in response to a legal wiretap order, even when the phone itself is nominally "powered off."
(And this doesn't even require that the phone stay connected to the network after the wiretap-enable packet is received. Rather, while the phone is "powered off", the baseband modem might sit there passively acting as a bug, capturing conversation through the microphone onto a bit of NAND onboard the modem; and then, once the phone is powered on again, the baseband modem will take the opportunity to silently play back whatever it's recorded to the tower.)
> if your use case is that sensitive even carrying a smartphone seems questionable.
The issue is that, if you're an actual honest-to-god spy (or investigative journalist...) trying to poke their nose into the goings-on of some government, then you want to draw as little suspicion to yourself as possible; and it's much more suspicious to be going around without the subject government's favorite citizen-surveillance tool on your person. In fact, to blend in, you need to be constantly using your state-surveillance-device to communicate with (decoy) friends and coworkers, doom-scroll, etc.
This is why spies are fans of the few remaining Android phone brands that offer designs with removable batteries. When meeting with a contact, they'll still slip their could-be-bugged-phone into a faraday bag, to cut off its network connectivity; but they'll also remove the phone's battery before putting the phone into the faraday bag, to inhibit this class of "powered-off" record-to-NAND-style baseband wiretap attacks.
(Of course, these are just ways to secure a phone you own + can determine wasn't subject to a supply-chain attack. If two people are meeting who aren't within the same security envelope, then either of them might be trying to surreptitiously record the conversation, and so their phones (or anything else on them) might contain a tiny bug with its own power source, that would stay active even if the macro-scale device's battery was removed. For such meetings, you therefore want to leave all electronic devices in a soundproof safe, in another room. Which will also implicitly act as a faraday cage.)
> if a phone has both a non-removable battery and a baseband modem, then various laws require that modem to be wired directly to that battery (and to the phone's microphone) and to able to be activated in response to a legal wiretap order, even when the phone itself is nominally "powered off."
I have seen phone schematics for many generic Androids, and at least for them, this comment is complete BS. The AP loads the firmware for the modem when it's turned on and boots it, and completely powers off the modem when asked to turn it off, e.g. in airplane mode. No idea about Apple though, they tend to Think Different™.
reply