brook Turn logic on
brook Do not hurry, think a bit.
I'm going to have to ask you to please stop being rude to other community members. It should be clear by now that not everyone here agrees with you, but that's no excuse to be rude.
brook Except entering the password every day. that I mentioned in previous message and before, because it was already discussed and considered not good.
You decided it's "not good" for yourself. Other people have mentioned unlocking with the primary unlock method once daily, which leads me to believe they're: not bothered by it, unaffected because they end up using their primary unlock method once daily for some reason, or are affected but are fine with working around the timeout.
You have been consistently using inaccurate words to describe the timeout and other things in this thread. You have described the timeout as a "bug" when it isn't. You've described the timing of the timeout as "random" when it isn't even after you were told how it works. Here you are very vaguely saying that the "workaround" people are talking about is "considered not good." It's considered "not good" by whom? The way you wrote this can be interpreted different ways, but someone who hasn't been following this thread may interpret it as there's a general consensus that there's a flaw in the timeout or the advice you've been given. There isn't.
You have spoken of logic many times throughout this thread. I'd expect that someone who's claiming to be looking at the issue logically would at least do all of us the courtesy of using accurate words when describing the situation. Over one hundred posts into this thread, I'm almost certain you're doing this on purpose in an attempt to "win" this argument. Not to mention you lord the word "logic" over other people and have started to demean others by suggesting they aren't as good at following "logic" as you are, which seems that you are framing yourself and anyone who agrees with you as intelligent and others who don't as unintelligent.
brook logic
This is where I think you're running into issues here with your argument:
- you set a long and secure passphrase
- you don't want to use it seemingly ever
- you're unwilling to take a small and simple step to unlock your device with the secure and complex passphrase at least once every 48 hours (you even complained about the suggestion to enter it only once "everyday" as you complained as recently as in this post brook)
- you claim that using this long and secure password is so difficult that you and others may decide to make their long and secure passphrase shorter to to make it easier to enter
I see all this and can only conclude that you just don't like using a long and secure passphrase. You like the convenient fingerprint unlock and are tempted to use a weaker/shorter unlock method for, as far as I can tell, convenience. It seems safe to assume you don't want to use the primary unlock method at least once a day because you don't want to be inconvenienced.
You want the security of secure passphrase, but you actively complain about having to use the passphrase. They are annoying, sure, but they're still the best way to secure our devices, especially if you are worried an attacker can get around the secure element's throttling.
brook fight this timer that adds NOTHING good to the user's security
I took the time to poke around the related code, just to see what comments I could find, etc. Even if the fingerprint scanner is classified as Class 3 (which is referred to as a "strong biometric" in the code), there's still a constraint for when the OS will fall back to "primary authentication". The wording "non strong", "strong biometric", "strong" are all used in ways that have convinced me that security was on AOSP developers' minds when they added the timeouts. For example, here is where the default is set in DevicePolicyManager (since the official project account has said it's 48 hours, I'm assuming the hardcoded default is overridden. Maybe it's a per-device thing, or maybe there's some other reason. I'm not sure why, but it's not important). You can see the comment above that says (edited so it looks better on the forum):
Default and maximum timeout in milliseconds after which unlocking with weak auth times out, i.e. the user has to use a strong authentication method like password, PIN or pattern.
Ignoring the irony that they said that pattern unlock is a "strong authentication method," you can see that biometrics are being called "weak". Until now I have not felt confident enough to claim it's a security feature, but it sure looks like it's there for security reasons after poking around the code.
Again, to be extra clear, I am not someone who is involved in making these decisions or calls, but I very seriously doubt the project will flat out remove the timeout, I doubt they'll change the default behavior to disable the timeout, and I doubt they'll add a toggle to optionally turn off the timeout because it may be considered a security feature, but also because there are other way higher priority things to work on. If the behavior is changed in AOSP, it'll likely change in GrapheneOS. As far as I can tell, GrapheneOS has made no downstream changes to this particular functionality.
And one last thing: throughout all of the time that I've spent being active on this forum and within the community, you are the only person who has complained this much about the timeout. I'm not saying you're the only person who doesn't like it, but you are definitely the only one who has been so vocal about it. Even the others who've spoken against the timeout in this thread have just popped in to say they were affected by it and have left it at that. I'd suggest you look inward and really think about your complaints here and what you're trying to accomplish and how likely you're going to get changes landed in GrapheneOS by acting this way.