> 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.