Hacker News new | ask | show | jobs
by joycey 3769 days ago
I believe the difference is that Apple/Google are okay with turning over user data on a case-by-case basis provided there's a proper subpoena from a judge, but not okay with building a tool for the FBI that will allow them to look at any user's data. The former is equivalent to allowing the government to open your mail and wander around your house provided that they've obtained a search warrant. The latter is equivalent to building a tool that would allow the government to open anyone's mail and wander around anyone's house without a search warrant.
2 comments

I don't think Apple has been asked to build a tool, just to help unlock a single device.

I think Pichai is making a distinction between handing over data they already own (eg. a Gmail account) and data stored on user-controlled devices, which must be hacked to access.

Which is interesting, since he's essentially admitting that their push to send everything to "the cloud" makes their users less safe from governmental snooping (justified or not). Of course, we already knew that, but it's curious to see Google's own CEO say it.

Actually, this is a quite interesting distinction to consider. There is significantly more danger in hacks which can "scale" due to centralization and non-physical access compared to physical access.

In the case of cloud data, the government should be held to a higher standard of restriction, because all of the data is in one location, and requires only a single "factor", the identity of the target to collect data for. This applies to both "encrypted at rest" and "encrypted in flight" data.

But for data encrypted at rest on actual physical devices, there's an inherent '2-factor' security to the private invasion. The government must not only know the identity of the target to collect the information, they must possess the physical device as well. ("something you know" + "something you have")

This means, IMHO, there is far less danger, and far less scalability to "one off" hacks like the ones being requested to Apple. They don't scale to Snowden-level dragnets, they don't present low transaction cost barriers to acquisition.

The dangerous think for decentralized data is having an active attack on the device, or something which intercepts the data "in flight". These are scalable attacks you need to worry about. E.g. "push a key logger to every iphone software update"

Perhaps the law needs to make a distinction to warrants for 1-factor data vs 2-factor data, due to the inherent danger of 1-factor data, given that it scales easily to monitoring millions with little transaction cost.

So in this regard, I think there should be MORE push back for collection of cloud data, but individual one-offs for physical devices have a safer threat model.

I view this more like a Vault being found at the home of a murderer, and the cops asking the Vault maker to help unlock the Vault without revealing the proprietary locking mechanism, or without the cops needing to blow up the vault and potentially lose whats inside.

> I think Pichai is making a distinction between handing over data they already own (eg. a Gmail account) and data stored on user-controlled devices, which must be hacked to access.

No, Pichai is making a distinction between giving the information after a correct process and developing a backdoor to slurp the data. It has nothing to do with cloud/device differences

That's a distinction without a difference, since in practice they only need a backdoor to get data from the user's devices and not from their servers.
I don't think Apple has been asked to build a tool, just to help unlock a single device

Aside from the non-sequitur, what Apple has been asked for is a custom build of iOS.

Fine, but it's custom build locked to that particular device and which Apple can install itself, without providing it to the FBI. It's certainly not "a tool for the FBI that will allow them to look at any user's data".

https://assets.documentcloud.org/documents/2714001/SB-Shoote...

Once they made it, locked for that device, the FBI knows Apple can make it again, locked for another device. The tool is for any user's data, via a court order on Apple.
But Apple would still need to have the court orders for each user.

Some people are suggesting that Apple would create this back-doored code, and hand it to the FBI, who would then use it to access any data they want without bothering with court orders. That doesn't seem to be what the FBI are asking for.

> But Apple would still need to have the court orders for each user.

Yes, and Apple doesn't want this as a precedent. It does away with one of their go-to selling points these days: security/privacy.

If device security can be surreptitiously undone by an OTA upgrade, what's really the point? I'm sure the brilliant legal minds at the DoJ can come up with creative interpretations to enable the next stage, which would be to do this in bulk as a special point-release.

Once the iSpecialPhone is unlocked, can't the FBI image it and diff the hack out of the image?
Once created, what stops the Government from obtaining a copy of the modified OS and the means to sign/encrypt it for any device? Either via some top-secret "You can't tell anyone about this or you go to jail" process, or via an agent embedded in the company?
What stops them from using those mechanisms to create it in the first place?
Knowledge and skill, evidently.
That's stretching the jargon a bit. I know that's what Cook said, but it could be a one-off process without the "custom build" leaving Apple's hands. Basically, comment out the time-delay and wipe code, build, sign, and push to the device.

Really the most important part there is the "sign" step, and the fact that the FBI isn't straight-up asking for the signing keys is telling; they didn't want this request to escalate the way it has.

They don't want the signing key because that sets the wrong precedent.

The precedent they want is that All Writs can be used to force Apple into creating a backdoor.

The next step is an online attack backdoor which slurps data over LTE from a suspect's device while it is unlocked.

Well, if they aren't being asked to build a tool, then there's nothing for them to help the FBI with because the device functions as designed.

It is precisely the design of the device that the FBI wants Apple to alter using some sort of tool that Apple will make for them.

My point was just that the FBI didn't ask Apple to "build a tool for the FBI that will allow them to look at any user's data". They asked Apple to prevent some security mechanisms of that particular device from working. Whether Apple builds a tool or uses manual labour with existing tools to do so is irrelevant for the FBI.
What IS relevant for the FBI is establishing legal precedent under the Writs act for compelling them to do so.
The point that gets lost here is that it's close to impossible for Apple to build a tool that will only allow them to look at any users data. Once the tool exists it's a simple hexedit away from working on anyones phone. While the court may be asking for something single use that same court may not understand the full implications of what they are asking. Thus the need for a public discourse on the topic.
It's not an hexedit away because Apple won't have to provide it to the Feds, hence they can still demand a court order each and every time. Except for the cost, it's no different than if they had to re-build it every time.
They haven't explicitly asked for that specifically, but that would be the consequence of fulfilling the request.
The FBI claims they're willing to accept a device-locked hack, that it's fine if it is only RAM-resident, and that Apple may keep the device on their own premises so long as FBI can attempt multiple pin entries electronically without risking a wipe.

http://www.zdnet.com/article/this-is-how-the-fbi-wants-apple...