5 ms·

Google “wontfix” a “panic pin code to wipe device” issue in Android

24 points by develop7 6y ago

deadmutex 6y ago
Misleading title? This was a feature request which the team feels like is obsolete. The title makes it seem like it was some buggy piece of code they decided to leave as-is. Disclosure: I work at Google, but my views are my own.
- strbean 6y ago
  Any notion why this would be obsolete?
  - thewisenerd 6y ago
    I think the "obselete" part is the issue being open from 2018. @ parent, it doesn't really seem like the title is "misleading" given we know the feature does not exist. although some might wonder if it did, so /shrug.
    - strbean 6y ago
      I suppose I understand, but don't they have a more descriptive tag, like "stale"?
WillDaSilva 6y ago
Seems like an extremely easy feature to add. A question I'm left with is what possible reasons could they have for not wanting to implement this?
- brianwawok 6y ago
  There are literally MILLIONS of easy features you can think up for an android phone. How deep do you want menus to go? Do menus 10-15 levels deep really help the end user?
- trav4225 6y ago
  Hmm, my guess is because they don't see it as a sexy feature that would appeal to mainstream users.
- shawnz 6y ago
  No other major vendor has this feature. It could create a bad experience if a customer triggers it by accident. The same thing could be accomplished by an application that guards secret data rather than putting this in the OS. There are plenty of reasons not to implement this.
- SSchick 6y ago
  My top 3 suspicions why this won't be added: - The use case is consider too 'niche'. - There is some concern that users will wipe their phones by accident and raise support tickets and/or engage in any other activity that causes additional work/cost for google. - 1st party support might step on various governments toes by shipping this by default.
- geofft 6y ago
  Working software isn't developed by the "implement all the features that you can't think of a reason not to implement" model. The old MS blog post about "minus 100 points" is a good analysis of this: https://docs.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points https://docs.microsoft.com/en-us/archive/blogs/ericgu/minus-...
- RulerOf 6y ago
  Nearly all of the major tech companies are walking a fine line with respect to "warrant-proof" tech products in the eyes of the current administration of the US government. Building a feature like this would be tempting fate given the current climate at the AG's office IMO.
brianwawok 6y ago
How come this is worth talking about? I am a real small dude that runs a real small SaaS app for a living, but I won't fix 1-2 customer requests a week. I don't do it for fun, and I know they are really important to the user that asked for them. But at some point you have to have vision for the direction of a product, and build features for that product that get you in that direction. Some PM at Google decided that a panic PIN was not worth coding. I am guessing they say all the bad cases of it (my toddler typed 1234 and my phone bricked), and decided they would outweigh the good features. It seems a reasonable decision? Does apple have a panic PIN? If so, I am not aware of it...
- thanksforfish 6y ago
  Note that wipe and brick mean different things.
  - mattmanser 6y ago
    You get what he means though? Chances of people getting their phone wiped by accident is far higher than the extremely niche case of building some complex UI for an emergency wipe.
- m463 6y ago
  If you hold power + volume up on an iPhone for a couple seconds it disables biometric unlock. It flushes the unlock keys and only your pin will unlock the phone. In other words power + volume up means the key to unlock your phone is in your head, not at the end of your finger or your face. Apple does not have a panic wipe pin. Personally I think a wipe pin is reasonable, just be VERY sure you don't type the wrong pin in by mistake. Also, I wonder... would it even work? How long would it take to wipe 64gb or 128gb of flash? securely?
  - tialaramex 6y ago
    Don't wipe 128GB of flash. If you care about this data then you would encrypt it at rest. Having encrypted it at rest there's a key, let's say it's a 256-bit AES key. So now when you throw away the 256-bit AES key the rest of the data is garbage, exactly as worthwhile as if you'd wiped it, but instantly. A factory restore might take quite a lot longer, but as soon as that key is forgotten the data is gone.
thewisenerd 6y ago
note: I don't even dabble, and getting my info from [1] so salt with Qualcomm, if I'm not wrong, it should suffice to, with FDE, (transparently, on entry of pin), nuke the DEK (random key generated by Keymaster), and force a device reset; this does seem like an interesting usecase for custom firmware and/or magisk [1] http://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html http://bits-please.blogspot.com/2016/06/extracting-qualcomms... albeit, if this does end up being implemented in some manner, wouldn't the fallback be a "confiscate electronic devices first for forensic" approach?
geofft 6y ago
This is a surprising threat model: > It would be great to have the possibility to set second pin code which wipe your device without confirmations. [...] In my country (Russia, if you interested) policy try to force political activist unlock their smartphones for collect more evidence. They use tortures and threats of tortures for this. If you you can't unlock because it wiped they don't have motivation to use tortures. My mental model of law enforcement in the US is that they don't become less inclined towards illegal violence if you anger them. If anything, I'd expect a "clear this subset of data, but go ahead and unlock the phone anyway so it looks normal" feature to be more useful. (So I guess I think that this feature request needs more detail/discussion in order to be useful.)
ceautery 6y ago
I can't imagine Google ever implementing that feature request. Apple had a PR nightmare after not unlocking a phone. Imagine the fallout if Google made it easy to quickly hide evidence from the authorities. It would be a legal and PR disaster, with the risk of having oppressive governments ban all Android devices.
deleted 6y ago
[deleted]
rubber_duck 6y ago
This sounds like a decent project for a student that could be contributed to something like Lineage OS.
mcstafford 6y ago
It's misleading to suggest they won't fix an identified bug, as opposed to declining a feature request.
deleted 6y ago
[deleted]
tialaramex 6y ago
A Microsoft employee (Eric Gunnerson?) wrote that every feature starts with minus 100 points. I can't link that claim because Microsoft periodically decides it's now a hip exciting new company and throws away things that made it relevant. In 1995 it didn't surprise me that Microsoft didn't "get" the Web, but in 2020 it does seem kinda crazy that they still don't get it. What Eric meant is, implementing features isn't a coin toss decision. The effort of adding even the very simplest feature, and then testing it, and documenting it, and supporting it, is enormous, so all of that weighs against any potential feature from the outset. If your feature should go on the list that's because it scores "plus 100 points" against those considerations.

24 points by develop7 6y ago

Misleading title? This was a feature request which the team feels like is obsolete. The title makes it seem like it was some buggy piece of code they decided to leave as-is. Disclosure: I work at Google, but my views are my own.

strbean 6y ago
Any notion why this would be obsolete?
- thewisenerd 6y ago
  I think the "obselete" part is the issue being open from 2018. @ parent, it doesn't really seem like the title is "misleading" given we know the feature does not exist. although some might wonder if it did, so /shrug.
  - strbean 6y ago
    I suppose I understand, but don't they have a more descriptive tag, like "stale"?

WillDaSilva 6y ago

Seems like an extremely easy feature to add. A question I'm left with is what possible reasons could they have for not wanting to implement this?

brianwawok 6y ago
There are literally MILLIONS of easy features you can think up for an android phone. How deep do you want menus to go? Do menus 10-15 levels deep really help the end user?
trav4225 6y ago
Hmm, my guess is because they don't see it as a sexy feature that would appeal to mainstream users.
shawnz 6y ago
No other major vendor has this feature. It could create a bad experience if a customer triggers it by accident. The same thing could be accomplished by an application that guards secret data rather than putting this in the OS. There are plenty of reasons not to implement this.
SSchick 6y ago
My top 3 suspicions why this won't be added: - The use case is consider too 'niche'. - There is some concern that users will wipe their phones by accident and raise support tickets and/or engage in any other activity that causes additional work/cost for google. - 1st party support might step on various governments toes by shipping this by default.
geofft 6y ago
Working software isn't developed by the "implement all the features that you can't think of a reason not to implement" model. The old MS blog post about "minus 100 points" is a good analysis of this: https://docs.microsoft.com/en-us/archive/blogs/ericgu/minus-100-points https://docs.microsoft.com/en-us/archive/blogs/ericgu/minus-...
RulerOf 6y ago
Nearly all of the major tech companies are walking a fine line with respect to "warrant-proof" tech products in the eyes of the current administration of the US government. Building a feature like this would be tempting fate given the current climate at the AG's office IMO.

brianwawok 6y ago

How come this is worth talking about? I am a real small dude that runs a real small SaaS app for a living, but I won't fix 1-2 customer requests a week. I don't do it for fun, and I know they are really important to the user that asked for them. But at some point you have to have vision for the direction of a product, and build features for that product that get you in that direction. Some PM at Google decided that a panic PIN was not worth coding. I am guessing they say all the bad cases of it (my toddler typed 1234 and my phone bricked), and decided they would outweigh the good features. It seems a reasonable decision? Does apple have a panic PIN? If so, I am not aware of it...

thanksforfish 6y ago
Note that wipe and brick mean different things.
- mattmanser 6y ago
  You get what he means though? Chances of people getting their phone wiped by accident is far higher than the extremely niche case of building some complex UI for an emergency wipe.
m463 6y ago
If you hold power + volume up on an iPhone for a couple seconds it disables biometric unlock. It flushes the unlock keys and only your pin will unlock the phone. In other words power + volume up means the key to unlock your phone is in your head, not at the end of your finger or your face. Apple does not have a panic wipe pin. Personally I think a wipe pin is reasonable, just be VERY sure you don't type the wrong pin in by mistake. Also, I wonder... would it even work? How long would it take to wipe 64gb or 128gb of flash? securely?
- tialaramex 6y ago
  Don't wipe 128GB of flash. If you care about this data then you would encrypt it at rest. Having encrypted it at rest there's a key, let's say it's a 256-bit AES key. So now when you throw away the 256-bit AES key the rest of the data is garbage, exactly as worthwhile as if you'd wiped it, but instantly. A factory restore might take quite a lot longer, but as soon as that key is forgotten the data is gone.

thewisenerd 6y ago

note: I don't even dabble, and getting my info from [1] so salt with Qualcomm, if I'm not wrong, it should suffice to, with FDE, (transparently, on entry of pin), nuke the DEK (random key generated by Keymaster), and force a device reset; this does seem like an interesting usecase for custom firmware and/or magisk [1] http://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html http://bits-please.blogspot.com/2016/06/extracting-qualcomms... albeit, if this does end up being implemented in some manner, wouldn't the fallback be a "confiscate electronic devices first for forensic" approach?

geofft 6y ago

This is a surprising threat model: > It would be great to have the possibility to set second pin code which wipe your device without confirmations. [...] In my country (Russia, if you interested) policy try to force political activist unlock their smartphones for collect more evidence. They use tortures and threats of tortures for this. If you you can't unlock because it wiped they don't have motivation to use tortures. My mental model of law enforcement in the US is that they don't become less inclined towards illegal violence if you anger them. If anything, I'd expect a "clear this subset of data, but go ahead and unlock the phone anyway so it looks normal" feature to be more useful. (So I guess I think that this feature request needs more detail/discussion in order to be useful.)

ceautery 6y ago

I can't imagine Google ever implementing that feature request. Apple had a PR nightmare after not unlocking a phone. Imagine the fallout if Google made it easy to quickly hide evidence from the authorities. It would be a legal and PR disaster, with the risk of having oppressive governments ban all Android devices.

deleted 6y ago

[deleted]

rubber_duck 6y ago

This sounds like a decent project for a student that could be contributed to something like Lineage OS.

mcstafford 6y ago

It's misleading to suggest they won't fix an identified bug, as opposed to declining a feature request.

deleted 6y ago

[deleted]

tialaramex 6y ago

A Microsoft employee (Eric Gunnerson?) wrote that every feature starts with minus 100 points. I can't link that claim because Microsoft periodically decides it's now a hip exciting new company and throws away things that made it relevant. In 1995 it didn't surprise me that Microsoft didn't "get" the Web, but in 2020 it does seem kinda crazy that they still don't get it. What Eric meant is, implementing features isn't a coin toss decision. The effort of adding even the very simplest feature, and then testing it, and documenting it, and supporting it, is enormous, so all of that weighs against any potential feature from the outset. If your feature should go on the list that's because it scores "plus 100 points" against those considerations.