Remove pattern as an unlock method choice in UI

[Wonderfall]

Humans are way too predictable when they choose their own pattern locks (especially), thus drastically reducing the entropy and reducing the security of their device. A secure element can't really compensate for a very poorly chosen pattern. Most common patterns can be guessed in a few attempts following a simple logic. Of course a PIN or a password can be poorly chosen too, but patterns are directly prone to "human" suggestion.

According to this study, a significant amount of Android users are using patterns to protect their devices instead of a PIN. It also experimentally shows that this unlock method is inherently very vulnerable to shoulder surfing. Plenty of other studies have shown this in general.

The option to choose pattern as an unlock method should just be removed from the UI to discourage users from using it, as they should use PIN or password instead (they could ideally be provided with randomly generated ones and pick the one they want).

[Wonderfall]

Trying out a simple attempt at Wonderfall/platform_packages_apps_Settings@ed5d3ce
Will run some more tests and then I'll open a PR if I'm sure it doesn't break anything.

I'll open a new issue later regarding the random generation of PIN/passwords.

[thestinger]

Probably also needs removal from SetupWizard. That could happen before removing it in the Settings app too.

[Wonderfall]

To me, SetupWizard seems to use the com.android.settings.SETUP_LOCK_SCREEN intent (here and there) which brings us to this code in Settings. The pattern lock should have the HIDE_DISABLED flag since it's not considered as visible thanks to the previous commit (isScreenLockVisible). Hope I didn't miss anything.

Need some more testing though.

[zeugmatis]

New user coming from Lineage I do wish you guys hadn't removed this. On some devices, do not care all that much about whether someone unlocks it, but still want a custom ROM to slow down the data collection happening over the network. The swipe to unlock (zero security) option is still there, so all this accomplished was to use that instead of pattern (which at least had some mild security). So the overall effect is a regression - there is now no unlock screen security in place at all, because using a PIN is indeed that much more cumbersome.

Google could say the same thing about unlocking bootloaders - "Users shouldn't be allowed to do that, it's too dangerous."
Giving a warning / confirmation on selecting pattern unlock method, but still allowing it, would have been much nicer.

Anyway thanks for subscribing to my blog :-D ...otherwise GrapheneOS has been really great thus far! Thank you!

[ghost]

We're a production security and privacy focused OS. Read the paper posted that shows the major insecurities about pattern locks. We're not a random custom OS you find off of XDA. There is no regression.

We're not adding it back.

[Wonderfall]

So the overall effect is a regression - there is now no unlock screen security in place at all, because using a PIN is indeed that much more cumbersome.

As you guessed it, the swipe to unlock isn't meant for security. It wasn't hidden (it can be done easily) because it's a sensible choice for not having a secure primary unlock method, which is quite explicit. I agree this isn't a common use case but making this setting hidden could have implications, meanwhile pattern is easily replaced by something better.

The pattern option, on the other hand, is indeed quite misleading because it aims to be a "secure" primary unlock method, but fails terribly at doing so. And I personally don't see how a 4-6 digits PIN (backed by Titan M) is that much cumbersome, and as long as they're randomly generated (which is almost never the case for patterns), they're that much stronger over 99% patterns.

Respectfully, I still don't see the change as a regression. In my experience seeing people reacting to the change, they are now using a far more efficient unlock method.

Giving a warning / confirmation on selecting pattern unlock method, but still allowing it, would have been much nicer.

It would involve more code to maintain for something we would recommend users not to use anyway. In the long term it would be nice to have an informative UI to help users to choose a secure unlock method.

Bear in mind I'm not a project member so I'm not speaking on behalf of the project, but this is my opinion since I suggested the change. I didn't want this change to bother people, but to help them in the long run. I think it fits well a security-focused project like GrapheneOS, and to be honest AOSP should also part ways with the pattern unlock method.

[ghost]

Auditor tells you if you're using a proper lock method (User profile secure yes/no).

[thestinger]

That just tells you if you're using a lock method at all (not swipe or none).