>that they are even working right now on suing Corellium, a company which makes an iPhone emulator (which again, has strong legal precedent), in order to prevent anyone but a handful of highly controlled people from being able to debug their platform.

Anyone can debug their platform, as they have been. You just need to be approved for this specific program.

Apple's case against Corellium is about intellectual property, and it's frankly going to be a slam dunk in court. There's already established precedent with Apple v. Psystar with an almost identical set of facts.

> You just need to be approved for this specific program.

Since not just anyone can be approved, I don't think I"d consider that "anyone".

I mean, I guess technically "anyone" can learn to become a security researcher and spend years building up a "proven track record of success in finding security issues on Apple platforms, or other modern operating systems and platforms", but that's not generally how I think of the term "anyone". ;)

> Since not just anyone can be approved, I don't think I"d consider that "anyone".

I took the parent to mean you "just need to be approved" to do debugging via this program, but not to use other means to do debugging, which you don't need approval for, hence anyone can do.

The deal is that anyone willing to cough up the $100 developer fee is going to be 'approved'. Apple's not in a position to DQ anyone who's even remotely interested in making iOS more secure.

Why not? Their bug bounty program that they had previously was quite selective, for reference.

Yep, definitely designed to be a barrier that's just enough to say "look we're doing something", but restrict enough so that most won't bother. Sort of like their repair program.

I tend to like Apple in general, I think they do a lot of things right, but I feel there are a few things they do that are clearly about money and not the purported reasons. I guess no company is impervious to that.

"Look we're doing something"? Apple has a well-regarded security team that is among the largest in the industry. The locked platform is part of the premise of their security model. You can disagree with that; many smart people do. But you can't pretend that anything other than unlocking the platform constitutes a half-measure.

Apple's security model is not the only one that exists, and its model has the additional benefit of giving them the ability to control software distribution for the platform.

I'm actually not in disagreement of either points. I think they just need to stop with the whole see people can do stuff. Own it, I like the locked environment and security.

That said, on the back end outside of devices, they don't implement the same precautions. IE encrypting iCloud data / backups where they have limited access. I would like consistency is all.

One way or the other.

In what way do they not "own it"? They've been owning the fact that it's a closed system for 40 years, when tech nerds complained about their products being "appliances".

I'm more on the side of their argument that they have to lock the phone down without their own ability to access the data (which I agree with), but falling back on encrypting the backend the same way (buckling to Federal pressure).

I would love it to be encrypted through out. Even it if means, that if I lose access I may not be able to get it back. It's a tradeoff. The marketing position of being secure is factually true for the phone, but they imply the data is when in fact it really isn't.

>not just anyone can be approved

Anyone can take advantage of the unpatchable bootloader flaw on iDevices with the A11 SOC or earlier that allows you to exert full control over the device and any current or future version of iOS that runs on it.

>For security researchers, this is a huge boon, which should help them analyze any version of iOS that will run on an iPhone X or older. Since iOS research really can’t be done on a device that hasn’t had security restrictions lifted somehow, this will likely become one of the most important tools in researchers’ toolkits. This can benefit iOS users, as it can enable researchers to locate issues and report them to Apple.

https://blog.malwarebytes.com/mac/2019/09/new-ios-exploit-ch...

You don't need Apple's permission.

What happens when iOS 20 comes out and the A11 can’t run it? Is it suddenly okay then to ask Apple’s permission? I don’t think the court would hold up a bootrom exploit in an older chip as good enough for research purposes (what if an exploit only affected the A12 and A13 for some reason?)

How about some of the new features in Apple's recent chips? Is there a way to research those?

Oh, I understand where you were going now. Sorry, I should have read your post a bit more closely.

I do agree with saagarjha and jedieaston's sibling comments, however. Checkm8 is great, but it's temporary.

> Anyone can debug their platform, as they have been.

Apple would not like “anyone” debugging their platform. The fact that people have jumped through hoops to do so is considered a bug and something that they actively try to prevent.

That doesn't change the fact that you're able to do security research on Apple products without their permission.

Apple gives me a locked box, I complain that I can't open it. You're saying that I shouldn't because some people have figured out how to pick the specific lock they're using, even though Apple doesn't want to people to do that and their next lock is not pickable using that technique anymore. Oh, and the pickable locks will be obsolete in a few years. Do you see the problem?

It's not illegal for you to do security research and Apple is not attempting to make it so. You'd like it to be more convenient to do security research and that is what this program is designed to do. I don't see why it's unreasonable for Apple to have terms you need to agree to to benefit from this program.

I think it is not unreasonable for Apple to make security research convenient without adding onerous restrictions on how it is done. Many other platforms do this already, too–actually it's the norm for most of them.

> Apple gives me a locked box, I complain that I can't open it.

Well, if you don’t like closed boxes, just don’t buy a closed box.

Part of the point of security research is that practically 0% of consumers are capable of doing this research themselves and making informed purchasing decisions. Security researchers hold businesses accountable when consumers can't.

In light of that, your argument is "Just don't hold Apple accountable!", which Apple would love... but that would also be harmful to consumers.

> Part of the point of security research is that practically 0% of consumers are capable of doing this research

Well, then by that statement alone security researchers aren’t just “anyone”.

I don’t see a problem in a company imposing restrictions that make finding vulnerabilities harder for everyone in general provided they are willing to allow security researchers to jump those restrictions.

In fact I actually see it as a big win, since now bad actors have significantly higher costs while good actors that are legally liable have lower barriers of entry.

...but these hurdles (at least the ones I know of from the bug bounty program; and which I see elsewhere in this thread do seem to apply to these devices also) contain things like clauses most security researchers consider unethical (holding bugs indefinitely without public disclosure no matter how long it takes Apple to fix the issue) and seems to exclude people who don't generally show Apple in a favorable light.

(And no: I entirely disagree that "bad actors" have significantly higher costs because of this, as bad actors can do illegal stuff like buy internal developer protocols off the black market from corrupt factory employees: there was a massive expose about this in Forbes last year. Hell: Apple bugs are actually less valuable on the black market now than Android bugs because there are so many of them! Apple's attempts to hide their devices from public scrutiny is about PR, not part of some coherent security strategy.)

If this doesn't impact costs for bad actors, it's hard to see how it impacts costs for good actors, since, in the status quo ante of this program, both good and bad actors shared the same vectors to get kernel access to devices. Apple is, on this page, explicit about the notion that this program doesn't impact vulnerability research done outside the program. In what way does this program do anything but add an option for good actors?

I may just not be understanding you; maybe we just agree that this program doesn't change a whole lot.

> If this doesn't impact costs for bad actors, it's hard to see how it impacts costs for good actors, since, in the status quo ante of this program, both good and bad actors shared the same vectors to get kernel access to devices.

Oh come on... I am a security researcher, and I have definitely had multiple opportunities to buy a stolen prototype device (as I am sure you would have also... but I also assume you don't need it as your company is one of the only companies in this space I have seen actively consulting for Apple--which I frankly feel like maybe you should be disclosing here? I guess you might still not have access to dev-fused devices as I have some vague memory of figuring out that you worked on server security... still :/--so maybe you don't pay as much attention or are as tempted as those of us on the outside); like just about every legitimate person who stumbles upon this, I said no, as I don't want to do something actively illegal (such as trafficking in stolen goods). Are you seriously trying to argue that I should be doing actively illegal things to do research?

> I may just not be understanding you; maybe we just agree that this program doesn't change a whole lot.

I never claimed the program (which I will assume you mean the device program, though I think this also mostly applies to the bug bounty program itself) did? I said "anyone who wants to should be able to buy such a device" and "this ends up feeling like yet another flat gesture" (and then cited numerous specific ways in which Apple clearly works against security research on their devices).

You are then here responding to a comment where I am defending against someone who is claiming anyone can do security research (as Apple can't legally stop me... which is "technically true" but "useless" as they can still sue me--as they did my friends at Corellium--and I can't afford to defend myself) and this device is sufficient as anyone can get one (if only they are willing to get over a few "hurdles") by explaining why most security researchers would not take part in these programs (which is, in fact, an argument for why this program "doesn't change a whole lot"). The argument is that Apple needs to do _more_, to put good actors (who have nothing but these programs and bootrom exploits for older devices) on the same level as bad actors (who have comparatively little issue doing research).

(1) I know you're a security researcher.

(2) I'm a software developer at Fly.io.

(3) Latacora, my previous security company, did no work at all for Apple.

(4) I have no idea what you mean by "server security"; you are probably thinking of someone else.

(5) I'm not asking whether you think it's OK that Apple sued Corellium. Most people in software security are not happy that Apple sued Corellium; I'm not going to be the oddball pissing into the wind this time with a contrary take.

If we agree, we agree, and it sounds like we do: one might not believe that the SRDP meaningfully improves security research on the iPhone, but it's hard to make an argument that the SRDP _harms_ it.

(Of course, I'm talking about Matasano Security / NCC Group ;P. I knew people there when you all worked out of the Dental Fabulous--no clue if you still do--and had some incredibly awkward run-ins involving Apple people, as everyone on all sides wanted to pretend that no one knew anyone else, due to what I'm sure was a ton of NDAs, explicit and implied... it was pretty epic, actually, as one of the people involved was essentially a "double-agent"! Regardless, I'm willing to believe that you had just left before all of these contracts with Apple had happened, and it certainly undermines the premise that you yourself don't need one of these devices to do research, so "point still taken".)

I left Matasano more than 6 years ago. Unfortunately, Matasano SFBA moved from the dentist's office (which I have fond memories of) to Sunnyvale. What I'll say right now is: I have the same disclosable interest in Apple's security as most veterans in software security: they're an elite employer and I have a bunch of friends there.

(The more important disclosure is that I don't specialize in the kind of work that would likely benefit from an unlocked phone.)

It gives researchers who don't want to do illegal things debugging access to the kernel, whereas previously this was not possible on newer devices because the only way to do that outside of Apple was to somehow (illegally) obtain access to a development-fused iPhone.

Yes; I'm asking, how does providing that new option harm software security researchers?

I understand the subtext that Apple could more efficiently help software security researchers by freely unlocking phones, but I'm not here to litigate that.

I was just responding to the part where you mentioned that good and bad actors had the same access before this program, which isn't true. (And it still probably isn't true, since I hear these devices are research fused and you can buy developer fused devices–or more recently, swap out your production-fused device's CPU–from the black market.)

To individual researchers, yes, this gives them a new option–I guess that is good? What I am concerned about is that it is an attractive option for them and they get locked into whatever disclosure timeline/research focus Apple wants them to have. You could of course say that they could leave the program at any point and go back to how it was before, but I think people are generally reluctant to lose access to things.

And on this note, people are also extremely reluctant to too horribly piss off the gorilla: I called Apple out on the morality of these clauses with a pretty harsh and personal speech during the initial bug bounty program meeting, and I had a bunch of people come up to me afterwards telling me they agreed strongly but were too afraid that Apple would lock them out if they were to say anything themselves (and of course, I was never invited to any subsequent meetings, not that any of us--even among the people at Apple who championed me being at the meeting in the first place--ever believed I would be: I sort of get the impression that some of them mostly wanted to demonstrate to their managers that what they were doing wasn't universally liked, but understood the fear).

The morality of which clauses? Can you be more specific?

Arguments about the legitimacy of Apple's locked platform are among the most boring we can have on HN, and date all the way back to the origin of HN. But arguments about the specific terms in the SRDP, or even Apple's bug bounty, are super interesting.

> The morality of which clauses? Can you be more specific?

I was already very specific: "holding bugs indefinitely without public disclosure no matter how long it takes Apple to fix the issue" is the exact quote that I used after "clauses most security researchers consider unethical" in the comment that you replied to and which we were arguing about ;P.

In said comment, I noted that I wasn't sure if that clause only affected the bug bounty program, or if it also applied to the security device research program (which is crazy as the terms are right there: I must have just let them all blur together in my head); of course, as this is Apple we are talking about, there was no real risk that they would have suddenly decided to be reasonable, and so they are even more explicit about this immoral clause in this new program.

https://developer.apple.com/security-bounty/

> Researchers must: Not disclose the issue publicly before Apple releases the security advisory for the report. (Generally, the advisory is released along with the associated update to resolve the issue).

https://developer.apple.com/programs/security-research-devic...

> If you report a vulnerability affecting Apple products, Apple will provide you with a publication date (usually the date on which Apple releases the update to resolve the issue). Apple will work in good faith to resolve each vulnerability as soon as practical. Until the publication date, you cannot discuss the vulnerability with others.

I have many friends who believe in simultaneous disclosure, and I know many people who believe in "responsible" disclosure (with its associated deadlines before public disclosure); I have met almost no one who believes that this "tell Apple and give them indefinitely long to fix the issue without telling anyone else about it" disclosure model is legitimate (I'm sure they exist, but they are certainly a small minority).

This has also been discussed in a different thread on this same post https://news.ycombinator.com/item?id=23920454 with a link to someone from Google Project Zero expressing their disappointment with these same clauses "which seem specifically designed to exclude Project Zero and other researchers who use a 90 day policy".

https://twitter.com/benhawkes/status/1286021329246801921?s=1...

How many consumers do in depth security analysis on devices before buying them? You are in a bubble of you think that’s normal behavior. And to do such research on a device, wouldn’t you need to buy a device? You’re going to buy a device to research if you should buy the device? And sales numbers would indicate that most people are confident enough in Apple’s security.

There's a locked box, and there's the box that spies on you and also looks uglier to some people. Not much of a choice, is there?

Are you talking using or research ? For research, android is obviously much easier. As a user, sure, you may have your preference. Asking for Apple's cooperation in doing research on Apple devices seems quite antithetical to Apple's overall approach to business. I don't see why there should be any such expectation. I feel that once a company gets large enough (in stature, revenue, etc.), everyone bestows upon it certain qualities and expectations. It's not reasonable to do so. Large coal/oil company won't become environment friendly no matter how much money it makes.

Using.

Not only a flat gesture, I think this by this they are actively gunning for companies like Corellium and will have a huge amount of control over security researchers who join the program. Disclose your bugs to us on our terms or have your access yanked? Pretty yikes. (And this is completely ignoring the rest of your comment, because it's pretty clear that they don't want consumers with debuggable iPhones.)

We don't have to speculate about this; Apple is actively gunning for Corellium. Your best tip-off to that was them suing Corellium.

Oh, I know that Apple is gunning for Corellium, my question was if this specific thing was meant to be another arm of that dispute (it probably is).

In the sense that Apple probably wouldn't have done it if Corellium had never existed, sure.

The reason I imagine this comes up as a thread of discussion is because Apple promised they would do this long before Corellium existed--at least four years ago: the meeting I was at--and I heard it had likely even been shelved!... but it has seemingly now become something to bother with doing, and as far as anyone can tell it is because Apple's lawsuit with Corellium non-trivially tries to claim that Corellium can't use certain "obvious" defenses because their emulator somehow competes with and carves into the market for Apple's promised security research device program, which is in some sense the Daikatana of this community. So to people who might otherwise think "oh, Apple loves security researchers: look at this program as proof!" the real thought should be "Apple is likely only doing this at all to help them win a lawsuit and injunction against a company which provides the tools used by a lot of security researchers" (a lawsuit which also wants to push through Corellium so they can attack their customers).

Apple's lawsuit is about infringement of their copyright. And that gives them exclusive rights over their intellectual property without any conditions. Legally, their case isn't better or worse because of this program. The likely reason they announced it just before suing Corellium is to avoid giving the impression that they were attacking the security research community in general, rather than Corellium specifically.

My hope is that they'll settle the case and Corellium's assets go to Apple and the founders become employees and continue to work on their product, because clearly a virtualized service is better than a physical device. But perhaps there are other legal reasons I'm not aware of why they'd still want to do this program with physical devices.

You have a misinterpretation of the strength of copyright: there are a lot of legally protected (both by statute and by case law) things you can do with someone else's copyrighted works as long as you don't copy them (and even if you do make some copies, it is sometimes OK; I've cited this case a couple times already on this thread, but see Sega v. Accolade: Accolade ended up winning this case despite the fact that they had to actually make "infringing" copies in order to accomplish their goal of software interoperability).

Apple's case directly cites their Security Research Device program in the first paragraph of introduction on "Corellium's Infringing Product"... and, notably, also pushes into the idea that one of the things Corellium supposedly infringed was Apple's GUI Elements, which feels a bit ridiculous to me... (I don't feel like Apple had their best lawyers work on this one ;P).

> Corellium is “a startup that sells a product that allows users to create virtual instances of almost any iOS device in the world.” Corellium’s product creates exact digital replicas of Apple’s iOS, iTunes, and GUI Elements (referred to here as the “Corellium Apple Product”), available via either Corellium’s web-based platform or a privately installed, Corellium-provided platform. Corellium admits that its product will compete with Apple’s iOS Security Research Device Program.

Their case also attempts to directly push at the problem using DMCA Section 1201 language, and notes that one of the things that Corellium is used for is to jailbreak your device; the language used claims that these jailbreaks--which are the alternative constantly cited here for what security researchers can use to learn about and test on iOS (ironic, as they are themselves failures of security)--are "unlawful ends" (which isn't true, but the fact that Apple wants this to be true so hard demonstrates their distaste for people being able to access their own hardware).

> The Apple Corellium Product also provides users with the ability to “jailbreak” virtual iOS devices. Jailbreaking refers to the act of modifying iOS to circumvent the software restrictions that prevent unfettered access to the operating system. Corellium openly markets the ability of its technology to “jailbreak... any version” of iOS. Corellium provides its jailbreaking technology to all its customers, regardless of their purpose.

> On April 1, 2019, Corellium again highlighted the unlawful ends to which its product is aimed by publicly acknowledging that it had given access to its platform to the developers of code used to jailbreak iOS devices called “unc0ver,” so the developers could test the jailbreaking code “on any device running any firmware” and distribute that code to the public. Within weeks, those developers released a new version of unc0ver that allowed jailbreaking of iOS 12.6 In other words, Corellium has admitted not only that its product is designed to circumvent technological protection measures Apple puts in place to prevent access to and infringement of its copyrighted works in iOS, but that it has aided and abetted the creation and trafficking of other software that is also designed to circumvent those same technological measures.

Sure. I think we're all on the same page about this.

If anyone could buy this device, then tons of scammers would buy them, install malware, and sell them to people as normal phones. They could then control banking apps and whatever else they wanted.

Most such devices (e.g. "development kit" devices for game consoles) look very different than the release product. Usually in such a way that it'd be impractical to use them casually for your personal needs.

In other cases, e.g. Android/Chromebooks, there's a common, immutable early chain-of-trust that stays the same between production and development devices (or in this case, between rooted and unrooted devices); which pops up a message during boot warning that a device is currently a development/rooted device, and therefore should not be trusted for production use-cases. It could just-as-well also say "DO NOT BUY THIS PHONE ON THE SECONDARY MARKET; IT HAS BEEN TAMPERED WITH, AND CANNOT BE TRUSTED WITHOUT FACTORY RE-VERIFICATION" — and then users told repeatedly in the company's messaging to look for messages at boot before buying.

Most, maybe, but look at all of the Developer Transition Kits Apple has been distributing - they’re Mac Mini bodies with Apple Silicon inside. There’s no reason to think this won’t be an iPhone chassis with modified guts.

This will likely be an iPhone that looks identical to a production one, both inside and out. Perhaps there will be a serial number on it or something.

I agree, but I think there are non-technical people who would happily buy a cheap iPhone on Craigslist or Facebook and enter in all their iCloud or banking info without rebooting or looking at warnings.

Who is honestly going to buy this highly sought-after iPhone, backdoor it and flip it for a discount on Craigslist in an attempt to what, hack a random person? And you can just prevent that by doing something simple like disabling the App Store…

First, my argument only applies to when these are common and not highly sought after (see the top level comment I replied to). Not necessarily a random person, but having an easily obtainable rooted iPhone would absolutely enable targeted attacks against wealthy/famous people.

Think of it like a classic USB drop attack but a bit more expensive: you install your remote management code on a phone, box it up like new, and drop it at the door of someone wealthy's house. I'd bet they would happily assume it's a wrong delivery and start using it if it's an upgrade over their current phone.

Again, if you make the research iPhones unmistakable people will figure it out. And yeah, people ignore strange markings or click through warnings, but if you make it impossible to do the thing they want to do then they literally cannot ignore it.

I agree with the first sentence, but disabling the app store would greatly hamper security research, since you can't debug third party apps.

You'd just download the IPA manually and self-sign it or whatever. Basically just make it unmistakable that this device is not normal and block normal people from being able to use it as normal without realizing it's a development device.

I doubt they would cost the same as regular iPhones.

Does it matter what they cost if scammers could net tens/hundreds of thousands for a single one? (Assuming they pick targets right)

People with tens/hundreds of thousands of dollars are buying iPhones from random third parties?

It's easier than that. You simply modify the special phone to broadcast the unlock PIN being entered in realtime. You set the background to the same wallpaper as the target's phone.

You swap it physically for the target's phone on the table, netting you the target device.

Moments later, when they pick up a phone that looks just like their own and enters a PIN several times, you now have both their phone (from when you swapped it) and the PIN to unlock it (from the broadcast), allowing you full use of the device, offline, at your leisure. The target is now confused why their phone isn't unlocking, and may not detect the attack for hours.

Apple really should put these audit devices in a big, boxy, couldn't possibly-be-mistaken-for-an-iPhone case.

> The target is now confused why their phone isn't unlocking, and may not detect the attack for hours.

You might as well let the user in while you’re at it, so it’s truly undetectable.

> Apple really should put these audit devices in a big, boxy, couldn't possibly-be-mistaken-for-an-iPhone case.

Someone in Shenzhen is spinning up their CNC machine as you speak to change that to “you could probably show it to a Genius and they wouldn’t be able to tell at a glance”.

You couldn’t, without the data on the stolen target phone. The attack ends with the victim in physical possession of the security research device.

I was thinking that the board might need to be larger, too, to make sure it couldn’t easily be transplanted.

> I was thinking that the board might need to be larger, too, to make sure it couldn’t easily be transplanted.

Wouldn't that be costly from an assembly perspective? Economies of scale and all that.

Idk, this all seems much too spy-novel-esque for me. You could also install a hidden camera in the victim's room, or modify the phone to capture the video-out signal.

Apple is retaining ownership of the devices, as mentioned in the article. They are not for sale. The per-device cost is not hugely relevant.

It sounds like a spy novel because spies spy on people who use regular, everyday hardware. A rooted iPhone is an extremely useful tool to that end.

> It sounds like a spy novel because spies spy on people who use regular, everyday hardware. A rooted iPhone is an extremely useful tool to that end.

Do you know of any instances where this happened with devices that can be rooted? (Computers, most Android phones, iPhones vulnerable to Checkm8)

Barton Gellman wrote about this very thing happening to his iPad (remote jailbreak/root) when he was working with Snowden, in his book Dark Mirror.

The leveraging of Android malware for espionage (corporate and military both) is well-documented in the media.

So get a regular iPhone, disable the lock-screen timer, slap an app on it that mimics the unlock screen. No specialty hardware needed.

You could do that with jailbroken phones today.

A scam that requires an individually targeted bespoke device that nets tens or hundreds of thousands (how does that even work? how would the proceeds be exfiltrated untraceably?) is just a really expensive way to have a very short career as a scammer.

The move is in line with their reputation. Handing out a bunch of research devices which come with a catch is a great way to exert more control and influence over vulnerability reporting, and skew the bargaining power when it comes to disclosure. I expect the motivation is largely genuine to encourage security research that bolsters their platform, but also stems in part from an increasing fear of PR ramifications outside their control.

"I'm handing out a bunch of water bottles; sign up here. The contents remain my property so when you're done please urinate back into them and return to me on demand."

Honestly had to think about whether your offer was a good deal.

If only open source software licenses could have predicted the level of vertical integration control their software would be used in. Apple continually violates the good will of developers and puts forth their own bad will. I'm tempted to make up an 'MIT minus non-free platforms' agreement. If the OS can't be completely emulated and freeley installed without restriction, then you can't use the library.

I'd like to see Apple survive having to recreate half their software from scratch.

They made APFS in (probably?) less than ten years :(

The license structure you suggest sounds kind of interesting.

Sounds like you might want GPL?

Probably AGPL

Go ahead. See how nobody uses your library.

Consider Android is open source and people have been able to get root access on devices since the beginning.

Still, it seems for overall security to have this program exist then not have a program at all.

To be fair (as a problem we have is that there is a small oligopoly of players and they all mostly suck), the original Android G1 was a locked down device: to get root on it required you to buy the Android ADP1 (which cost a lot more and had serious limitations with respect to apps from the Market); we only got root on it due to a bug (so the same as with iOS... it was just a dumber bug ;P). But yeah: Android wouldn't be usefully open source to anyone if you couldn't at least build your own device to test and run it on, and they clearly support that and they even provide emulators (and, thankfully, more recent, first-party Google devices are nice and open: Google learned their lesson there pretty quickly).

The 'android' that you get from your phone vendor definitely isn't open source. The AOSP project is and the distro from your vendor will have parts of it that can be traced back to the source.

But the android ecosystem as a whole is not 'open source' and not 'open' like people like you tell about. Almost all access is due to hacks and bugs, not because the boot loader and the OS came with the option for user access on the inside.

> The 'android' that you get from your phone vendor definitely isn't open source.

But it's so, so far ahead of iOS in openness. You can sideload apps. You can spin up Android in a VM. You can buy Android devices with unlocked bootloaders and install your own roms or drivers or kernel modules or whatever else. The system can be made yours to command.

iOS doesn't even let me run my own code in userland.

> iOS doesn't even let me run my own code in userland.

This has been possible for a long time. Yes, there are some hoops to jump through (7 day time limit per signing unless you pay), but to say it doesn’t allow you to run your own code is just wrong.

Limited userland code.

What code do you want to run that you can’t in any way? How is running that more important than the alternative?

Code that can generate new executable pages on the fly, code that can access the various databases on my phone, code that modifies how the system applications work…I think that's fairly important and useful, especially since the alternative is…you can't do that at all? What's the issue?

That's somewhat tangential to the item at hand isn't it? We are talking about open source, not about hackability or the rather vague term of 'openness'. One could argue that a device that is usable to a lot of people is 'open' and devices that all require their own teaching/learning are not.

And the method by which you get root, which involves unlocking the bootloader and using a custom recovery to flash the su binary and an app to manage it, is in itself enough of a deterrent that only people who know exactly what they're doing do it. It's impossible to root accidentally, you have to install adb/fastboot on your computer and follow instructions. And then every time it boots there'll be a warning that the system has been modified.

Google though... I really hate their stance with SafetyNet. It's as if they're trying to say "your device can either be fully useful or fully under your control, but not both".

I still don't get why iPhones absolutely can't have unlockable bootloaders.

In fairness, no one is really developing for the .NET ecosystem without VS licenses either. I’m sure it’s theoretically possible but MS de facto runs the same scam.