Ostensibly, Apple could open source the code running on their own baseband hardware (Apple C1). I'm pretty sure the hardware requires signed code for FCC compliance reasons, so you'd never be able to modify it, but as far as I know, nothing prevents them from making the code available.

You're missing my point. To the best of my knowledge, you can't buy a phone that has an entirely open source operating system now; the phone hardware vendors provide closed-source bits preinstalled, and nuking them is problematic at best. More importantly, even if that were not true, you still would not be able to buy an Apple iPhone or iPad with an OS that is pure open source, which makes your concern entirely irrelevant in this context.

This discussion is about what Apple would need to do to satisfy people with privacy concerns when it comes to third-party replacements for Siri on devices that Apple makes. Arguing that you don't trust Apple because parts of the OS are closed source is irrelevant, because you won't ever trust their device in the first place (or any devices, in all likelihood).

Either way, the automatic presumption is that if a consumer does not trust the device maker, that person will buy a device from some other manufacturer. So for the purposes of this discussion, the decision by the consumer to trust Apple is in the past. It was made when they bought the device with a preinstalled OS. Thus we can presume that the consumer in question therefore trusts Apple to a great extent.

What remains, then, is what Apple, as a presumptively trusted party, would have to do to continue to maintain that level of trust in their devices while allowing third parties to inject code that deeply integrates with every app on the system in a highly invasive way.

Well, that rules out 99.9999% of all mobile phones for you, then, with a +/- .0001% margin of error. :-)

That's an arbitrary distinction, though. What percentage of even the most tech-savvy users would actually take the time to audit every source code change to every software update to their phone to make sure it doesn't do something questionable? How many people would be capable of doing it successfully? I'm thinking back to the obfuscated C contest, not to mention thousands of examples of just how easy is to introduce a vulnerability that will get missed by code reviewers for years.

Open source is not even slightly immune to those sorts of issues. It could reasonably be argued, at least on an epidemic level, that we're better off with a larger number of different OS vendors, so that compromising a single vendor will compromise a smaller percentage of devices, but other than the high level of platform divergence that open source tends to bring with it (which has negative consequences for security, too), Open Source really isn't a panacea in a world where vulnerability discoveries are weaponized almost overnight.

If anything, big companies at least have the resources to throw huge amounts of money at prevention, which is something that open source likely does not have.

Correct. There's absolutely no plausible way to do it at an OS level except *maybe* for the camera, and even that can likely be thwarted by recording a video that starts on something innocuous and ends on nudity, because by the time the monitoring algorithm notices the nudity, many frames would already have been sent to the recording app.

But what the device manufacturer can do is require that all apps submitted for app review must comply with those standards and use those tools to check for disallowed content, and block any apps that do not comply from being installed on a device that is owned by someone under 18 (or whatever age is specified by the law in question), including blocking side-loading. You'd still have a handful of parents who unlock the devices for development so that their kids can write apps, but all other young people's devices would presumably be locked down (assuming the parents don't or can't turn that off).

It's fundamentally impossible for an operating system to protect you from the manufacturer of that operating system. That trust is unavoidable.

First, you'll have to build the hotword support for them, because you're not going to want to give random companies the ability to surreptitiously keep the mic hot and listen for the hotword support, because nothing would prevent them from exfiltrating arbitrary amounts of audio. This means developing a framework for running third-party companies' on-device hotword detection models and triggering the execution of that third-party code when the hotword is detected.

Next, you'll need to be able to support running the on-device models, though I guess that already exists.

And if you don't mandate that any prospective provider must give the same level of security that Apple does (e.g. running all cloud-based processing in an encrypted container), you will massively weaken the security of the platform, so to make this even remotely tolerable, you'l need a fine-grained security model to limit what gets shared with that third-party provider. Given that this is going to involve things like sniffing the keyboard in real time, accessing arbitrary text fields in the browser, etc. on command, that is a non-trivial amount of invasiveness, so giving users control over what gets shared and what doesn't get shared could be a nightmare.

I'm sure that's just the tip of the iceberg here.

It could be done, yes. Doing it in a way that respects user privacy would require a lot of careful thought when designing the architecture, IMO.

One of the biggest problems, from my perspective, is the risk of allowing real-time audio input from a background app that the user may or may not be actively engaged with. It's not just data. It's a live mic.

As far as I know, Apple isn't preventing companies from being able to add features and services inside Siri. They're just not allowing companies to replace it wholesale. You can run any arbitrary model that you want to within their frameworks, and you can extend Apple's assistant platform in arbitrary ways. What you can't do is switch to an entirely different assistant front end.

And even if you ignore the security concerns, there are very real usability reasons to disallow replacing Siri outright. Imagine if every app developer had to write twelve different versions of their AI integrations so that their apps would work with the twelve different assistants that users install on their devices. It would break the unity of the platform and make life miserable for developers. Realistically, nobody would support anything but Apple's built-in offerings, so any third-party services would be DOA anyway.

With that said, my opinion is based entirely on what I saw at their keynote on Monday and a quick gut check. I could be very wrong here, and I'm open to contrary opinions.

The DMA means that they are limited in their ability to build systems that favor Apple-provided services over other companies' services. And Siri is a service. So unless they want to allow native Google Assistant, Alexa, etc. alongside Siri, complete with the same level of access to user content, they can't roll it out in Europe. Creating an infrastructure for making that possible while protecting user privacy is genuinely hard.

This is not to say that Apple shouldn't be pressured to do so, but at the same time, I understand why they don't want to do so, and I'm not convinced that there's enough societal or individual consumer benefit from competition in that area to warrant the technical overhead. The EU really should have granted them an exception for this.

What I would like to see is for the EU to force Apple to open their devices up to other companies competing against iCloud. There are potentially *huge* consumer benefits from doing so, and unlike Siri (which has to tightly integrate with on-device content in potentially intrusive ways, which requires continuous microphone access, which has major performance/battery life risk, etc.), there is really no good reason not to demand competition being possible for cloud storage and cloud backup.

What you can do is provide trained on-device models that apps like WhatsApp can use to recognize whether they need to flag content, and flags to indicate whether the user is a minor whose content should be checked by that model.

But yeah, global enforcement of viewing naked pictures is impossible, and global enforcement of taking naked pictures is also impossible unless you don't provide direct access to the camera (which would break a whole lot of apps in fundamental ways).

Having a no-photo phone option would be great for military contractors, who often work where cameras aren't allowed. And while having a camera with me all the time is kind of neat at some level, I also recognize that it has been psychologically unhealthy for a lot of young people — particularly those with body image problems. So requiring cell phone makers to offer camera-free options would actually make a lot of sense. Nudity is just the tip of the iceberg when it comes to teens' use of camera phones.

And it would be way, way easier to remove the camera from a phone than to reliably recognize nude photos on a kid's device in a way that protects privacy reliably. It would also shift the decision to the time of purchase, where parents could decide whether their kids' phones should have cameras, rather than being a bloated, complex piece of software that takes up storage on everyone's devices for a feature that might be used on only a small percentage of devices.

So in every way, that seems like a smarter way to solve the problem, and also a much less narrowly focused solution that solves a bunch of other problems at the same time.

Food for thought.

And if you are a phone manufacturer and you tell them, "Our plan is to ignore your country until the next election, when your government will probably go away anyway," what then? Or if the answer is, "We can either keep England or California, and we choose California," what then?

Something like what they are asking for has to be done in a way that protects privacy all around, including, potentially, privacy of the minor from excessive intrusion by the parents, so you would have to allow an option for the kid to send the content to parents for approval.

For live photographs, that permission would have to be requested by the kid, and the content stored on device, but sequestered in such a way that the kid can't access it without parental approval. Otherwise, if you don't allow the photo to be taken at all, you wouldn't be able to have your kid take photos of art in museums without unlocking their devices (which would defeat the protection purposes), and if the phone automatically sends it for approval (rather than manually), you'd run the risk of kids' selfie porn getting automatically sent to their parents, making their parents potentially legally liable (not to mention probably psychologically scarred).

And all of this has to be done in such a way that none of the data can leave the device for any reason, under any circumstances, without the explicit permission of the owner of the device. That also means zero automatic reporting to anyone that content was flagged at all, because of the risk of such flagging triggering physical, emotional, or sexual abuse of the young people by others with access to those reports (e.g. pervy local law enforcement having a report of who all the bad girls are, or worse, getting access to the photos).

More importantly, this ideally should be done such in a way that it would be technically infeasible to comply with any future law mandating automatic reporting. And this is the truly hard part, because I have no idea how you'd pull that off. Mitigating the risk of future government overreach is actually the hardest aspect of this sort of detection from a privacy perspective, and given how many government officials are frothing at the mouth, breathlessly demanding such privacy violations, it's easy to see why such protection is so important.

Doing this right is potentially challenging to get right, and there are a lot of sharp edges. Worse, those sharp edges could cause regulatory problems in other countries, and because cell phones don't stay in one place, that can be a nasty problem.

Give them a ten-year implementation deadline with an eight-year design deadline. To be blunt, if England wanted this in six months, they should have asked in 2016.

Most out-of-warranty service isn't done at dealers, because they tend to massively overcharge compared with independent garages. Most out-of-warranty repairs are done with parts salvaged from wrecked vehicles, i.e. they are factory parts.

Repair for $4k + labor or replace for $9k. Still not a write off.

Nissan Leaf batteries can be obtained for $4,000 to $14,500, depending on capacity. I assume that is plus installation, but not certain. That's considerably less than what the resale value would be after the repair, so not a write-off.

Okay, sure, in Canada, where the number of EVs is already low and access to used parts is almost nonexistent, someone scrapped a single copy of an extremely unpopular toy EV with a tiny battery that sold only 22,000 units in total that model year worldwide.

That's not an EV problem. It's an ultra-rare car problem. Rare ICE cars have the same problem.

FWIW, when you can actually get them, used batteries for that model of car cost only about $4k. But you'll probably spend another $2,000 on shipping it by boat from Europe, because there are more people living in my immediate neighborhood plus the one across the street than there are 2017 Ioniq EVs in all of North America.

So let me restate that. There are no *popular* EVs that are getting scrapped because of the cost of battery replacement. After all, you could make that battery from scratch today for about $3,000, give or take, if somebody actually cared to do so. But they don't, because there's no market for it. You could also replace all the cells in that battery for under $3k, not including the labor. So a $50k estimate falls into "don't make me laugh" territory. It's a ludicrously inflated price, probably because they don't actually have any of the batteries left, and would have to spin up a production line just to build more. :-D

These are not use cases. These are driver incompetence.

First, modern EVs typically have support for telling you how much range you have left at your current speed, and telling you whether you need to slow down to reach a supercharger without running out of juice. The number of times I've had range anxiety in almost a decade of driving my Model X is in the single digits, and I've never run out.

Second, most people charge their EVs overnight, which means you aren't ever waiting for for the vehicle to charge. Or they charge at work while they are working. Five minutes for a refill is an eternity compared with the roughly zero minutes that the average EV user spends.

No, the problematic use cases are:

• Towing. This depletes batteries or fuel a lot more quickly, and EVs just don't have the battery capacity to do it well. What is needed here is a universal standard for powering cars from a secondary battery in the trailer.
• Apartment dwellers with no access to at-home charging. This is mostly solvable through a combination of incentives for apartment complexes to provide charging, laws requiring new apartments to have charging, and market pressure, but it doesn't happen overnight.
• Ultra-high-miles-per-day driving. If you're driving more than the range of the car every day, an EV might not be for you.

For approximately every other use case, EVs are better hands down.

WTF are you talking about? People replace EV batteries all the time. They also rebuild packs by swapping out modules. There are companies that specialize in doing so, and have a high rate of success. They charge single-digit thousands of dollars to rebuild a Tesla battery, depending on how many modules have to be replaced and other factors.

The number of EVs written off because of battery repair costs should be within the margin of error of being zero, because there are no used EVs that are worth less than $10k at this point. Even the cheapest, low-end EVs with a tiny battery are worth that much.

And if the number isn't zero, it is likely because some cars have such an undersized battery pack that nobody would want the car even with a refurbished pack, and therefore it isn't worth the effort to do so. While this might be a good reason not to buy short-range EVs (under 200 miles of range), it isn't a reason to avoid EVs in general.