Someone creates an account to complain for 10 straight days about an upstream timer, doesn't engage with other threads, and has been constantly using misleading wording, accusing GrapheneOS for "forcing" users to do this or that, or having a "security" issue is all completely false.
The timer was added upstream. It's not a GrapheneOS feature.
Reboots aren't necessary to reset the timer. All you need to do is enter the primary unlock method once and the timer resets. 48 hours isn't that unreasonable.
As recently as April, it was decided that the timeout won't be removed.
Also, here are some quotes from matchbox's posts earlier:
matchboxbananasynergy We do not plan to change how this works at this time.
matchboxbananasynergy What needs to be understood for anybody who is claiming that this feature is useless, is actually an anti-feature etc. is that GrapheneOS has to be very careful with what we add, remove, or change for multiple reasons.
matchboxbananasynergy The other is that this forum does NOT represent anything remotely close to the majority of GrapheneOS users, and we cannot be persuaded by a loud minority to make changes before considering them.
matchboxbananasynergy A setting for this where the default behavior is the upstream one where users could adjust the timer or disable it if they choose is something that I could envision shipping at some point, but like I said, we have to prioritize. We cannot prioritize based on who causes the biggest fuss on the forum, but what will benefit all of our users the most.
There's also my massive post here other8026 where I make the argument that the timer can be considered to be an upstream security feature and link to the place where the maximum of 72 hours is set and the comment says:
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.
I'm not a developer for the project or a security expert, but I think given how AOSP developers talk about biometrics, it can be considered a security feature. It may seem redundant since GrapheneOS has auto reboot, which is 72 hours by default. But since the auto reboot timer resets for all unlocks, I would argue that the two timers complement each other, improving security.
It's understandable that the timer may be annoying to some people, but adding a toggle to optionally disable the timeout isn't likely to be a priority for the project. If the developers agree that it can be considered a security feature, they may further deprioritize or it would be even less likely to add a toggle at all.
I've locked the thread because I think everything that can be said has been said and OP has continued to use inaccurate wording making GrapheneOS look insecure because they simply don't like the timeout despite people calling them out for it, including myself. I or another moderator may choose to unlock it later.