Hacker News new | past | comments | ask | show | jobs | submit login

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 things then the system will return to the default state.

I would turn it upside down, and let the logged out state be the default one. The logged-in state is then a lockscreen that is hidden behind a session. If the session dies you are back at the lock screen. The lock screen can't be dismissed because it's always there. If the lockscreen crashes the phone locks up completely because there is nothing else there to show.

It's acceptable for failures and exceptions to decrease privilege (boot you out), but they must never increase it.

Edit: Ideally the lockscreen should also run with reduced privileges so that it literally can't start a session even if it wants to, except indirectly by supplying a password to some other system.




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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: