It may not have been in the spec, but if it was widely known that the chip could do it, then it very well could be the case that people purchased the chip because of that, in which case the company unjustly benefitted from the widespread belief that it was supported, and is now seeking to further unjustly benefit by forcing those buyers to spend more money if they want to keep that feature.

Their failure to explicitly make clear that this was a bug and fix it in a timely manner is at least potentially an implied representation that could be subject to promissory estoppel.

In other words, they're probably doing something that violates the law, but we won't know for sure unless someone cares enough to sue over it.

Nope. You forgot the government factor:

($Fox + $Payment - (corporate_income_tax_rate * $Payment)) + ($Roku - $Payment = $Fox + $Roku - (corporate_income_tax_rate * $Payment).

So depending on what state the income is earned in, Anywhere from about 21% to about 30% of that could be going to taxes. So they could easily save $400M in taxes if that payment happens to be at least $1.3 billion or so. I doubt that's the case, of course.

The most critical skill is knowing when you're going into an AI rathole, shutting it down, and coding the relevant bits from scratch. There's nothing like wasting more time on iterative refinement than it would take to write the code by hand to sour an engineer on the use of AI.

The top 1% of the U.S. have $55 trillion dollars. The total U.S. national debt is only $38 trillion. That costs the government $1.4 trillion every year in interest alone. Leveling the playing field by capping everyone's total savings at 8 million per person would wipe out the national debt completely.

Mind you, wiping the national debt out still won't help as long as the Republicans keep overspending and undertaxing to the tune of two trillion a year, but even that should be easily fixable by more sound tax policy, coupled with laws mandating that the federal budget be revenue neutral or positive going forwards.

We've done the math. Have you?

I assume you're saying Pro is massively better for your workload. IMO, thinking is either good or bad, depending on whether it moves you closer to or farther away from correctness.

For example, I've seen certain types of workload (e.g. anything involving image recognition or image segmentation) be massively better with Flash, because Pro overthinks things and ends up changing perfectly correct answers to be wrong, either by coming up with creative ways to misinterpret the prompt or by screwing up the JSON image segmentation fragment so that it can no longer be parsed.

And I've also found that LLMs struggle to understand existing terms in a different context that they weren't trained on. As a result, I've had to substitute nonsense terms in place of terms based on common English words and phrases so that it won't ignore my definitions of those phrases in context and substitute its own understanding of their meaning and give incorrect results. The more thinking you allow, the more likely it is for that to occur.

RAW, video, anything that grabs stills in real time...

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.