Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental Google Pixel Lock Screen Bypass

bugs.xdavidhu.me

Post reply on HN
Print view View original

471–475 of 475 posts

Re: Accidental Google Pixel Lock Screen Bypass

#471

Post by jwr »

gwillen wrote: post #433
jwr wrote: post #381

I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire classes of bugs altogether. I've been doing that for more than 20 years now. This bug, if you look into the fix, falls into my "state transition" category. You can (and should) model large parts of your software as a state machine, with explicit transitions and in…

Do you have any writing I can read about your classification? This sounds extremely interesting and useful. (I have some related thoughts, but not 20 years' worth and largely not recorded.)

Hmm. Perhaps I should get my notes into shape and publish them… I'll think about it. I would need to force myself to post them to HN without looking at the discussion, though.

Re: Accidental Google Pixel Lock Screen Bypass

#472

Post by jwr »

underwater wrote: post #423
im3w1l wrote: post #411

Earlier quoted context omitted.

I think the root issue is one of which state is the default one. In Android the logged-in state is the default one, and the logged-out state is constructed by taking the logged-in state and essentially hiding it behind a modal. The issue with this is that systems have a tendency to return to their default state. If the modal is dismissed or has a bug that makes it crash or has a memory corruption, or any number of th…

Anything related to security should fail safe. Failure is not lack of rigour, it's from fundamentally flawed architecture.

This begs for the famous quote:

"When a fail-safe system fails, it fails by failing to fail-safe." (from the wonderful "Systemantics").

Yes, one should definitely try to fail safe. But managing your states and state transitions explicitly and carefully is a good way to avoid these kinds of bugs.

Re: Accidental Google Pixel Lock Screen Bypass

#473

Post by gcr »

klausa wrote: post #75
gcr wrote: post #64

Earlier quoted context omitted.

On iPhone, keys are evicted from memory when the device is locked. Apps running behind the Lock Screen can only write files to special file inboxes (this is why the camera lets you take pictures while locked but doesn’t display earlier pictures, for example) You’re telling me that android keeps keys in memory for its entire uptime?

That's not exactly true. There is a data protection class that is like what you're describing, but it is not used super-widely, the one most commonly used is exactly what is being described and makes data available after first unlock. https://developer.apple.com/documentation/security/ksecattra...

oh huh! thanks for the correction!

Re: Accidental Google Pixel Lock Screen Bypass

#474

Post by appleflaxen »

jwr wrote: post #381

I have an obsession with classifying software bugs into general categories, looking for the "root cause", or more constructively, for a way to avoid entire classes of bugs altogether. I've been doing that for more than 20 years now. This bug, if you look into the fix, falls into my "state transition" category. You can (and should) model large parts of your software as a state machine, with explicit transitions and in…

I would like to subscribe to your newsletter.

Re: Accidental Google Pixel Lock Screen Bypass

#475

Post by hackmiester »

ccouzens wrote: post #120
gcr wrote: post #64

Earlier quoted context omitted.

On iPhone, keys are evicted from memory when the device is locked. Apps running behind the Lock Screen can only write files to special file inboxes (this is why the camera lets you take pictures while locked but doesn’t display earlier pictures, for example) You’re telling me that android keeps keys in memory for its entire uptime?

Presumably not all keys? If you receive a phone call while locked presumably the phone can still access the address book to display the contact name and photo? And music playing apps can presumably access their database of music to play songs whilst the phone is locked?

> If you receive a phone call while locked presumably the phone can still access the address book to display the contact name and photo?

Just so you know, this is true on an iPhone, but NOT if the phone has NEVER been unlocked since reboot. If you get an SMS/call in this state, it will just show the number. It can't read the address book.

Post reply on HN