The patent clause is bad, but the anti-TiVoization clause is actually worse. According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
Stop spreading this FUD. They would not need to release their root singing keys in this case, just provide a mechanism to allow for other keys to be used (there are various ways to go about doing this without compromising security). The main requirement is that the compiled software can be run on the device.
The most plausible approach is one outlined in another comment in this thread wherein you get a new key when factory-resetting the device and if you don't write it down it's gone forever, but even that approach will likely cause problems with Activation Lock. And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high, and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
Not if a physical modification to the hardware, a set of button presses, a hardware token or a fuse is needed to set said keys.
> And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high
There is little to no risk if physical interaction with the hardware is required for setting keys. If you have physical access and enough time, all bets are off anyway.
> ...and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
There are many people who dream of having the freedom to roll their own firmware on a particular device and it can be done without compromising the security of said device. This was not just about iThing users (who might/not take advantage of this), this was about people spreading FUD about the tivoization part of the GPLv3. Root signing keys don't need to be shared and the only requirement is that the user can take the sources, compile them and then run the result on the target device. As long as the OEM distributing the GPLv3'ed program gives a clear path for running the compiled code on the target device, then it is not a problem.
So much so that in your attempt to find any toehold to criticize it, your comment had to resort to coming up with scenarios that go outside of the system and rely on human vulnerabilities.
The reason nobody mentions this is because the solution is so trivial there's really no point in repeating it each time.
That's only because we live in a world where phones aren't treated like the general use computers they are. MS+OEMs and Apple fought hard for decades to create an appliance mindset around what used to be a user-replaceable component, the OS.
We can just as easily imagine and try to build a world where it's just as easy to mix and match phones with phone OSes as it was to choose DR-DOS instead of MS-DOS.
Hog-wash. Me not allowed to be in control of my own device is the ultimate compromise of my security.
The author of a license is not the person with the legal authority to interpret its meaning.
That is just as absurd.
The opinion of the writer of a legal document carries only tangential weight next to the actual written words of this document.
Also, there's nothing stopping an opinion from a lawyer from being FUD. Apple Legal isn't your lawyer, they don't have a responsibility to tell you the whole truth or give you information that is in your best interest.
Also, it's not like Apple Legal is telling anyone outside the company about this. Apple's not releasing any public statements asking people not to use GPLv3. So how exactly are they supposed to be discouraging its use when the people using it don't know what Apple Legal thinks about it?
Yes there is. Apple doesn't want to use GPLv3 for other reasons (they don't want users to have full control over their machines -- which they've proven time and time again with the iThings). But rather than saying "sorry, we don't want you to be able to control your machines" (which would be bad PR) they spread rumors about "GPLv3 means your software cannot be secure against certain attacks".
> Also, it's not like Apple Legal is telling anyone outside the company about this.
Hence this whole comment thread is a discussion about theoretical views of Apple Legal. My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
Oh come on. You sound like a caricature now. "Not having control over their machines" is not a goal and it makes you sound like a crazy conspiracy theorist to claim it is. Security is a goal, and unfortunately security often conflicts with having complete control over the device. But that's different than saying Apple actively wants to prevent users from having control over their devices.
> they spread rumors
No they aren't. Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
> My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
I do. I know for sure this is the position of Apple Legal. Which is why I said this was their position in the first place.
I agree that security is a primary goal of Apple. And many of the restrictions have a mostly valid security justification. But "ability to have full control of your machine and be able to replace components" is clearly not part of Apple's goals. So they don't spend any time thinking about solving the problem with that constraint.
What security do you get from not being able to replace the window manager? Because if you want to claim that "Apple prioritises users being able to control all parts of their machines, and security prevents this from being possible" then you have to give a security justification for every un-configurable restriction.
> Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
Well, we're talking about it right now aren't we? I'm aware they didn't make any public statements, but this whole discussion is pointless if we are just going to say "I know this is their true opinion and they have no reason to lie to me because they didn't say it publicly, therefore [contentious statement about GPLv3] is effectively correct and there's no point in discussing this further".
> I know for sure this is the position of Apple Legal.
You know that this is what Apple Legal told you, or someone who knows someone at Apple Legal told you. Unless you're part of Apple Legal in which case you've now made a public statement about GPLv3.
This is the very definition of a rumor.
> What security do you get from not being able to replace the window manager?
Well, you could argue that a third-party window manager could be snooping on all of the content visible on your screen (that otherwise isn't available to third-party apps) and could be doing whatever they want with that potentially-sensitive info. But that doesn't even matter, because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work, especially because they'd likely end up with a far-less-stable system as a result".
> Well, we're talking about it right now aren't we?
We are, yes. Apple isn't. No matter what I say on the subject, that doesn't mean Apple is spreading rumors. I don't work for Apple.
> This is the very definition of a rumor.
You're free to accuse me of spreading rumors if you want. And I can't very well deny that because I can't provide any verification, but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
But you can't accuse Apple of spreading rumors because people like me are making statements about this.
And Apple's APIs let you snoop on those events anyway (that's how the semi-third party window manager-managers work), this is not an argument...
> because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work,
...so what you're saying is "they don't want to put the effort into being able to replace core components of the system"? Because that's what I'm saying. I'm just saying it in a less charitable way than that.
> but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
It's only a common interpretation if you believe the rumors about Apple's view (and you're not the only person spreading them). FSF does not make that claim. Effectively everyone who uses GPLv3 doesn't make that claim (as far as I know). The only people that I've seen make that claim are people who say "this is the justification that Apple told me off-the-record but since they said it off-the-record we can't discuss it's merits". Do you see why I would suspect that this rumor spreading is co-ordinated?
We went through this bullshit back with UEFI and GRUB in the Linux community. The agreement was that GPLv3 is fine so long as it is possible to replace the keys (and wiping the machine on key replacement is what you want to happen anyway, so that's fine and it solves the security issues). If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3. And you won't find one. Because it's not a common interpretation in the community that uses that license.
Why do you keep talking about rumors? And why do you keep talking as if this is somehow unique to Apple? I'm pretty sure Apple's not the only company that believes this. In fact, I have no idea why the FSF would even claim otherwise; Apple's interpretation seems to be perfectly in line with the entire point of the anti-TiVoization clause.
If Apple were to accidentally ship GPLv3 software on iOS 11, under whatever interpretation you subscribe to, how is Apple supposed to remain in compliance with GPLv3 without releasing their root signing keys? Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You keep insisting that Apple's interpretation is wrong, but you haven't provided any alternative interpretation.
> If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3
That's a catch-22. There isn't a larger community because GPLv3 is toxic to companies. Nobody else is going to create a larger ecosystem of GPLv3 code because doing so basically means turning into Linux.
Apple's interpretation of "we cannot design a system where you can have signed binaries [where you can replace the root signing keys] that complies with the GPLv3"? That's not what the GPLv3 changes meant.
Please just read the GPLv3 and make up your own mind, this is getting ridiculous. No reasonable interpretation of that section means that it is not possible to design a system that has binary signing and complies with the GPLv3. Apple's current system could not comply without releasing the root signing keys, but that's because they decided to design their system that way.
> If Apple were to accidentally ship GPLv3 software on iOS 11 ...
We're not talking about them accidentally shipping it. We're talking about them deciding to not update to GPLv3, and the justification being "security". Obviously accidentally shipping it would cause them issues, but that's
> Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You might be talking about that. That's not what I was talking about. I was talking about them designing products that explicitly don't allow user-swapping is the problem, and that there is no fundamental reason why you cannot have a secure system that allows user-swapping keys.
Of course a current device would be insecure if the root signing keys were released, because their threat model doesn't take that into account.
> There isn't a larger community because GPLv3 is toxic to companies.
I work for a company that releases GPLv3 software all the time. I've started projects that are GPLv3 as an employee. It's only toxic to companies that don't want to comply with free software licenses.
This is all just more FUD.
> This is all just more FUD.
Please stop calling things FUD just because you don't like it.
I guess you were in a different thread than me. The discussion started with saying that "they don't use GPLv3 purely because of security concerns as they cannot have a secure system". I outlined that yes you can, you said that "currently Apple's system doesn't work that way" and now you're saying that discussing whether or not it is possible to create such a system is off-topic.
Maybe I just misunderstood what you meant, but if that's the case then it still doesn't justify you broadly making incorrect claims about the GPLv3. You should say something like "Because Apple doesn't have the ability to replace the keys by the user, they cannot use GPLv3 as that would make their system insecure". You cannot omit the first part as it makes the statement incorrect.
> Please stop calling things FUD just because you don't like it.
"GPLv3 is toxic to companies" is FUD. It promotes fear through the use of the word "toxic", it promotes uncertainty by challenging a well-established license with vague concerns, and it seeds doubt in whether the license will be toxic to their company. As many companies do use and ship GPLv3 software and aren't being killed by this hypothetical toxicity, this is FUD.
It just so happens that I don't like that you said it, but that's because I don't like people spreading FUD. ;)
Now, I don't know if there is any provision in US law that makes you automatically enter a binding contract if you use code that is accompanied by a license file. It is certainly possible, as you demonstrate intent to enter the agreement. But OTOH, this would be too easy to abuse. Just sneakily replace the LICENSE.txt and add "you agree to pay 50% of your income and your firstborn child"... I don't think many would catch that.
We say "this code is under this license", but actually beneath the hood this means "this code is available for license under these terms".
(In Germany at least the hurdle to enter a contract is rather high. For a time, you were able to get on a bus without paying, and if caught argue that you never agreed to the terms of the bus company... so they had to make a special law against fraudently leeching services.)
Probably.
> Just sneakily replace the LICENSE.txt and add "you agree to pay 50% of your income and your firstborn child"... I don't think many would catch that.
A clause like that is completely unenforceable in the US. Any judge would throw it out.
There are some complexities here (and for Apple's goals with iOS, I totally understand them not wanting to work through those complexities), but for a team that has built the most secure general-purpose computing platform in the world, this isn't an unsolvable problem.
Compared to destroying the security model of iOS in general this is pretty tame, but it is still a non-trivial downside.
I think this design still works if you only allow generating a signing keypair if Activation Lock is disabled? I think that still satisfies the requirements of GPLv3 sect. 6, although we're probably in territory extremely far from settled caselaw.
> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
The "method"/"procedure" is signing out of iCloud, doing a factory reset, and holding down the button. It doesn't interfere with the continued functioning of the modified object code, i.e., of the OS itself, just with any user data present before you started the procedure.
(Sorry if this question is really misguided, I'm not super familiar with the area).
Were I an iOS device owner, I would want the ability to replace the root signing keys on any device I'd own. It'd be my device: why should Apple have the unique privilege of determining what software may run on it?
It's fair to say that the GPLv3, which predates the iPhone, did not anticipate the nuances of people storing all their secrets on a tiny little computer that they keep with them at all times, including when they pass through international borders.
(As others have said, there's ways to make GPLv3 work with the iphone's security model, mainly along the lines of requiring a factory reset whenever you want to add an allowed signing key to the device.)
How does the ability to wipe the phone (and thus the data, and the code compiled and signed by Apple) and replace its signing keys with your own allow an attacker to surreptitiously install a rootkit?
The dangers of physical access to one's devices existed before mobile computing, let alone before GPLv3 or the iPhone.
Nobody could be certain if they were running a trusted version of iOS.
This problem has been solved outside of Apple's garden.
Unlike other mobile operating systems, iOS prioritizes protecting the user's privacy. The real user, not just any household member or employer who might have physical access to the device.
In your described solution, what prevents an abusive/sneaky household member from posing as the user and supplying those "user-configurable" keys without the knowledge of the real user? Nothing? That answer wouldn't be good enough for the Apple "garden" as you call it.
The function "replace keys" can have any other programmable feature attached to it. Wiping out all preexisting data, reseting the phone to factory settings, and sending a message to the original owner is all possible and would make any sneaky behavior very un-sneaky. They could even require some form of 2auth or other technique that people use to authorize themselves to banks in order to get the unit-unique key to make the TPM memory rewritable. GPLv3 don't require that installing new keys are easy, but the real owner must have a method to do it.
Apple sees the iPhone as a hardware security device. Apple wants users to be confident enough in its security that they can use their phones to authenticate financial transactions.
It's great that some phones are modifyable by their users, but I would never ever link my Android phone with my bank account.
Personally I prefer that my hardware security device are controlled and owned by me, not the company that sold the device. Devices not owned by me have an undeniable history of being abused by people who sell such devices, like the case of Lenovo.
If you want to use the history of open devices which their owners can own and control as a case against it, the opposite of company approved software has also a history of abuse. How are all those nice lock down car computers that have been acting creatively during emissions tests. How much trust have they earned, and should people trust them with their bank account for say automatic payment at gas stations?
Because that's not how security works. If you can just add your keys, an attacker could too...
Err, security is about preventing attacks -- not about having evidence that they've happened.
Besides, select "foil", right click "Look up": (OS X Dictionary): prevent
So, not a native speaker, and there might still be some nuance of preventing from even being considered (avert?) in "foil", and you could be technically correct.
http://static.damnlol.com/media/5c5c06b2d9e1d4e9b66725f86dab...
The former is trivially defeated (just breaking the phone, for example, is much quicker and less involved than forcing a factory reset), and not what we were talking about.
Then the attacker installs some apps including some special ones designed to spy on the user.
Then they remove the screen lock, or set the password to something guessable or that turns up as a suggestion when Googling for "I can't get into my phone" and return the device to where the user had it last.
The naive user finds their device, gets in, and notices their data is gone. This is real harm.
Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
I'd have to say your system as described isn't working.
That's only slightly better than losing the phone itself.
> Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
This is more substantial. But if you are talking of the naive user who would not take notice of their Apple account suddenly vanishing from their device, there are easier ways for breaking in to their device without having to wipe it.
Apple's system doesn't work to secure naive users against dedicated attackers. If Apple's system has any design for security (and I agree it does), it's for users who'd notice when their data is wiped.
When you say it doesn't work against dedicated attackers, maybe you are thinking of an iPhone 6 hacked by an Israeli security company paid by the FBI? For one thing, most people don't have the resources of the FBI. And I think Apple has raised the bar significantly in the three or more generations since that device.
If you were to own an iPhone and also apply some conscious awareness to noticing what it does on your behalf to protect your security, I think you would agree it has a lot of very effective measures to protect users.
Social engineering, for one, is much easier against naive unsuspecting users than wiping their phone and hoping they wouldn't bother.
For those who truly care about their own data security though, a wiped phone is an instant siren.
----
I have used an iPhone, though only for a short while, and not long enough to get used to it. I agree it goes a great, great distance to protect users against everyone not blessed by Apple.
But then I have greater data security on my laptop and far greater freedom too, so Apple's offering doesn't seem like a good enough deal to me.
Also with a laptop the use cases generally can tolerate a bit more delay in the login process, with a few seconds being tolerable, whereas with mobile devices a login process over a second starts to get intolerable very quickly as the length of the process increases. Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
Mobile device designers and mobile system designers deal with this stuff every day for years on end. They know a lot about it, and have thought stuff through way more than some of us. It's super easy for you to criticize from a position of relative ignorance (not even a current iOS user...) but I'm pretty sure they are still following the mantra of trying to make stuff insanely great.
Still, you can dream of even better devices. I'm sure the bar will keep being raised. Let's hope we get there to a place where we do have both freedom and security.
> Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
I'm not oblivious to the tradeoffs of security. I know that if I set a long password it only makes every login that much more tedious. And that's my problem to deal with. But to have no choice, no freedom, no chance of owing your device, in the name of "security", is either unmindful or wilfully ignorant of a manufacturer.
----
You keep saying I'm not a current iOS user so I couldn't possibly see the great things iOS does. I merely doubt it could do anything beyond generally security focused OSes. For example, my current mobile OS has a separate decryption password at boot, scrambles the lock screen numeric layout, compartmentalizes my data, hooks into every way apps can request private data and lets me allow/disallow/fake it, hooks into every way apps can even run and lets me choose which to allow/disallow, and still provides me the freedom to run whatever I want and share whatever data I want with whichever app I want.
I'm not dreaming of much more, largely because I already have quite a lot.
I said no such thing. And yet you put it in quotes. This kind of behavior is for reddit, not here.
Apple does give you security; it just has to happen in a different way.
I don't trust Apple to be good from now until I replace my phone. I don't trust Google to be good from now until I replace my phone. It's my phone, not Apple's and not Google's.
Edit: Well, I guess the secure enclave can be trusted. But nothing else can be.
It bothers me that you are confusing Apple's policy choices, which are not inevitabilities nor are they without dissenting opinions, with security, suggesting there is no possibility to satisfy the latter without making the same choices as the former.
Now, I might be lazy or busy and delegate that responsibility to Apple or some other third party. There may be mismatches between my preferred policy and what is enforced by my proxy, but it might still work reasonably well overall. We humans do it all the time. No reason the CEO has to make every single decision themselves.
When the stakes are high and I don't want to risk that nuances of my set policy get lost in translation or when it's about things that are totally outside my proxy's area of expertise, I'd prefer to make the decision myself.
With iDevices, I can't. There's only the delegate model and the only available proxy to choose from is Apple.
PS: Releasing secret signing keys to the whole world is an obviously bogus suggestion. Please stop beating up this strawman.
Don't confuse having secret keys as "security by obscurity".
That's not what the phrase means. Else SSH private keys are "security by obscurity" too...