Kill Siri (2022)
term7.info
term7.info
I admit that the current sanitized, standardized net is probably better overall. It's certainly more accessible. But I do appreciate sites that make weird personal choices like this.
Rather than starting with a closed system and ripping out the parts that spy on you, why not start with an open system like Linux or OpenBSD?
If anyone with the smallest amount of skill had physical access to my desktop, they could replace the bootloader with a malicious one and get everything when I next log in. While my macbook is secured against basically everyone but top tier federal agents. If I left my macbook in a hotel room, I can reasonably expect it has not been tampered with.
There doesn't seem to be any real version of SIP on Linux. Basically every program I run requires full access to everything. Flatpak is sort of tightening things up but it still has a long way to go to close all the loose ends.
So while I might have more control over my linux machine, I still trust my macbook more.
It does beg the question of which system can be more secure, though. Apple has a decently high bar out-of-box, but they could certainly do more to make MacOS a trustless ecosystem. The simple fact that all of MacOS is basically unaccountable from a programming perspective is both a security flaw and a privacy concern. Whereas a public codebase like Linux receives constant intersectional scrutiny, closed systems like MacOS can't have that same attention. Non-transparent codebases cut both ways: they can hide embarassing bugs from people reading the source, but it can also protect zero-days and backdoors that would have otherwise been identified and fixed. Transparent systems only seek a ground truth.
So... it's a toss-up. I wouldn't put my life on the line if I was a political dissident considering a Macbook, but Joe Shmoe and his wedding photo editing business should have all the security it needs.
GrapheneOS on sufficiently secure hardware (! Unfortunately open-source laptops are very bad in this category), which has to be a Pixel for now trades blows with iphones.
And I just can't see how any security measure which requires hardware can come to Linux desktop.
Why? TPM works just fine. Secure Boot is perfectly usable on most OSes. Hell, even fprintd supports biometric authentication if you're a weirdo. Nothing inherently stops this stuff from being made, certainly not the kernel.
All hardware-based security measures will probably never be supported by Linux, but if your benchmark for disbelief is "any" then boy have I got a boat to sell you!
We are at the point where being bug free is impossible and patching after discovery is not good enough. Secure designs must protect against undiscovered bugs.
There are certainly security and convenience scenarios where MacOS is hard to beat, but no trust-based system can ever be the final say in security.
Classic case of Apache/BSD dual licensing there. Hopefully people learn their lesson and write less software like this in the future, but...
This is not true; Apple’s OSes get plenty of scrutiny by various groups looking to fix (and break!) its software defenses.
This doesn't mean Apple does everything right, of course, but the situation on the other side frequently sucks too even though it nominally should not. And given various choices in their ecosystem (lack of fragmentation, for example) they can and do end up with a better security story in some areas.
Probably because they were traumatized by how much extra work that was (and for a sub-par desktop experience overall), last time they went down that rabbit hole.
I’m in that camp. I ran Slackware on a Compaq laptop in the early 2000’s and it was more work than I would have liked — though I did have more free time then as a student.
I swapped to macOS and have been using that since for work and personal productivity projects, though I do use windows to play games. When my MacBook went on the fritz, I was forced to become acquainted with WSL. And I find it to be pretty usable for my use cases.
My MacBook is a bit aged at this point and probably needs replacement before too long. But now instead of comparing OSes (Linux or windows with WSL vs macOS), I need to think about hardware: battery life, build quality, and performance; my needs in these categories may still favor Apple in the laptop and small form factors.
I want both, privacy and convenience of a Mac OS. I shouldn’t have to compromise.
In this case, Apple may be compelled to turn over device, account or financial data. So don't do anything bad* and lose your privacy privileges!
*Definition of 'bad' subject to local law and interpretation.
So, I would reserve my nuts for better bets.
It could be worse, though. If you're a Chinese iCloud user, your data just gets uploaded right into state-owned servers: https://support.apple.com/en-us/HT208351
They can already protect themselves by using pseudonymous IDs, and by not storing SSN and full names on the same system/network as your browsing history.
I'm struggling to come up with a general example where an adversary would be prevented from accessing the data if they had already compromized the network, so to me, it's just obfuscation with extra steps. Maybe if an adversary, by some miracle, had a non-root shell in database server, but somehow did not have read-permission on the crypto store ???
Physical theft of drives is a valid argument, but even that is a weak one. The data center facilities are very secure.
Someone please make open booting and hardware configuration for a general OS on Arm a reality. Without standard booting I feel that open source OS phones will never exist. They're always behind on driver development leaving users with buggy battery murdering devices that are missing features. Dev's don't want to bother with messy alpha quality platforms. They move slow as they don't have FAANG money so the platforms never gain momentum. Simple general booting will change that - no more recompiling a kernel using some byzantine labyrinth build system - just write an image to SD or USB and boot.
I am confusing them with the issue of getting a kernels built for a lot of the poorly documented hardware that varies a bunch which device trees try to solve but don't. No two vendors agree on how to boot things. I cant just download ubuntu or even openbsd for my phone or tablet as each of those has its own boot loader. Too splintered of a platform.
The SoC is its own static architecture - each vendor sells its own little computer system complete with booting methods. Since the hardware is static there is no need to implement a configuration mechanism which also acts as a discovery mechanism (like PCI). So we can't build a kernel that asks the SoC "Whats inside", instead, the device tree is a list of what hardware exists and where it is mapped in memory.
And that hardware might not be standard or use weird register layouts that don't match other commonly used layouts in other similar devices further complicating the porting effort. The SoC might have a unique USB controller or Ethernet MAC or whatever that needs a new driver. Just lots of duplicated effort for each "new computer" when its all the same hardware inside. And its like this because SoC's are low cost disposable chips - no one cares if you cant port a new kernel because by the time you want a new kernel the thing is already obsolete and expected to be disposed of and replaced with a new gadget.
What could be done? Setting standards for hardware registers - similar to how PC vendors like Intel and Microsoft standardized the dumb basics like ATA, USB, Ethernet, Serial ports and so on. Set standards so we don't need to re-write drivers for every new chip released. Then standardize the boot firmware so the device can boot-strap the hardware to the point where it can load a kernel image via a debug interface, thumb drive, emmc, sd etc. Let the device boot hand the OS its device tree - done.
When my student's first showed me SIRI, I didn't have a smartphone and was basically just going by Stallman ethics (shut up--just saying...).
They said, ask Siri to do anything and she can.
I picked up my students phone and said, "Siri, how do I inactivate Siri?"
They looked nervous and said, "don't ask her THAT!"
I went home and watched "Her https://en.wikipedia.org/wiki/Her_(film)" and thought, .... who knows?
Perhaps a more relevant question to ask your students at that moment might be; why are they anthropomorphizing a program?
> I went home and watched "Her https://en.wikipedia.org/wiki/Her_(film)" and thought, .... who knows?
Me thinks you do :-).
I have no wireless interfaces enabled on my Mac, yet several Wi-Fi services are running.
My Mac doesn't support Universal Control, yet UniversalControl.app is running.
And so on.
One could certainly argue that the fact that unnecessary background processes run unconditionally is sloppy system design, but in the absence of some evidence that they materially affect system operation, I'd just as soon leave them alone.
If one's goal is to run a minimalist system, I can hardly think of a worse starting point than macOS, compared to which even Windows is at least somewhat amenable, given that both WinPE and Server Core exist as vendor-supplied examples.
I say this as a near full-time Mac user since the early '90s.
I have never, not even once, used this intentionally. It just keeps interrupting me when I activate it by accident.
But it keeps happening if I accidentally press my headset button for a millisecond too long. Had been an issue at least since iPhone 5.
I'm not a fan of Microsoft either (and they ain't no saints either - anyway, I primarily use Linux), but if I have to choose between Microsoft-land and Apple-land, I choose the former, because they, at least, are and always have been way better at giving their users choice, and at making everything configurable.
For me, it's not even so much about privacy, or opaqueness, or interoperability (although Apple is abysmal in those ways too, and they matter too). It's about respect, of which Apple demonstrates none.
Even after a concerted effort, the best that the author - someone who appears to have decent technical know-how - could come up with, was a "whack-a-mole" script that kills Siri whenever it rears its ugly head again. Says it all.
- Check the time while doing something else.
- Set timers when cooking or before I need to leave
- Converting units or doing calculations.
- Check the temperature or weather.
- Set the temperature of radiators in specific rooms.
- Announce upcoming calendar events prior to their occurrence, e.g. which bin day is it tomorrow.
- Play/Pause my TV if I'm eating something messy.
- Occasionally for playing music.
Despite this it still feels very limited. I'd use an assistant that integrated an LLM even more frequently. Alexa's biggest drawback is that she isn't conversational, follow-ups only work when they've been explicitly supported. You can't ask her to clarify or correct her in most cases.
Not much work seems to have gone into tightening up the rough edges either. Multi-User support is pretty poor, failing at fairly basic things like "what's on <wife's name>'s calendar tomorrow?". She's unable to answer much about packages as well. Asking her what items are included in the delivery simply prompts her to re-announce that a package is being delivered today.
> Despite this it still feels very limited. Yes, I was actually thinking about this before posting the comment. It can be kind of useful but for very basic things. On mobiles phones is it possible to call emergency services through it?
https://theintercept.com/2017/03/07/wikileaks-dump-shows-cia...
Edit: So, would you trust something that is there with an open microphone 24hs?
Absolutely, although I have similar concerns about any device with a microphone and network connection. Ultimately it was a trade-off, when an OSS alternative of comparable quality exists I'll switch when I have time. The OSS options have come along a fair bit in the last few years and they seem to be quicker at integrating LLMs. Quality hardware seems to be the biggest barrier.
> Yes, I was actually thinking about this before posting the comment. It can be kind of useful but for very basic things. On mobiles phones is it possible to call emergency services through it?
I'd assume so, I don't use it much on my phone but I can ask one of the dedicated Alexa devices to call regular phone numbers/contacts and it'll use my phone plan to do so.
Yes. You do have to trust Apple to tell the truth, just like you trust every vendor to do the same. You can also choose to trust professionals[1] who do compliance/privacy auditing.
Only looking at what is directly visible to you (the filesystem) and jumping to conclusions (these things run Siri) is too shallow a pass to understand at all what is going on, and this blog post is just spreading FUD.
I helped create one of the daemons you link in the blog post, `siriactionsd`, and it was created for the Shortcuts app. It contains a bucket of different services used across the operating system by a series of features all attributed to Shortcuts. We then then did all of the work to wire everything up to a series of understandable switches: in Shortcuts settings. You can turn those switches off and/or delete the app and you have to (again) trust that the engineering team implemented them properly and in a way that you would agree with. Not all engineering teams are equally good, even at Apple.
If you like to understand how your operating system works and what every single process is doing, then I would switch to an open source operating system like Linux.
Try turning off other services and looking for traces of them – you'll turn up similar results. Daemons are baked into the read-only operating system image on all of Apple's platforms and there is no way to uninstall them.
[1] like Will Strafach: https://www.bleepingcomputer.com/news/security/accuweather-i...