It's not idiotic. It's to prevent automatic sign-ins, sign-in requests etc. especially from hidden iframes.
"User must interact with page for features to become active" is a very common way to deal with quite a few things in various browsers, not just Safari.
1. It's nonstandard, we need no more of that on the web. Also poorly documented. Also buggy.
2. There are way better methods, it could've been something akin to Media Engagement Index.
3. There's no "allow bypass" option. Wasting people's time unconditionally is idiotic.
4. This check applies to both Webauthn password-ed and passwordless with or without user presence. It makes no sense that the user must click a button to consent to being able to verify presence and then enter a PIN.
5. User gesture does not carry over to contexts where it's often needed. It breaks subpages like most login flows have, it does not carry properly between various JS callbacks, it does not carry over between multiple sites (for example to an SSO solution), it does not allow an easy way to reattempt authentication when something errors. It's so cumbersome and breaks so much without proper alternatives!
> It's nonstandard, we need no more of that on the web
Because sometimes it's not for standards to define how an app behaves in certain situations.
> There are way better methods, it could've been something akin to Media Engagement Index.
Do read about Media Engagement Index: https://developer.chrome.com/blog/autoplay/ Even MEI is basically "if user engaged with content on the site, then we allow certain things". And yes, it's also non-standard, and buggy, and poorly documented
The rest of complaints are about the complexities of figuring out user intent in the context of the browser. Yes, yes, it's extremely hard, and lies at the intersection of malicious actors, clueless users, and browsers trying to figure out what to do in the whole spectre in between them.
It could also be that the standard itself is badly designed (I don't know, I never read it), and didn't account for the complexities of modern web.
> Large websites got an exception
The comment above you stated "There's no whitelist AFAIK". you ignored that part, so I'm not sure where the "exceptions/whitelist" info comes from. If there's a whitelist, then yeah, it's a bad solution and shouldn't be there.
> The comment above you stated "There's no whitelist AFAIK".
FYI I was talking about WebAuthn user verification there; not Safari's requirement for a DOM user gesture. I have no idea how Safari implements their user gesture requirement or if there's a whitelist involved anywhere in that process.
Yes, I was referring to WebAuthn user verification. @Avamander claims there's a whitelist, but I couldn't find any proof of that through quick googling
I'm not talking about Webauthn's standardized user presence checking, certainly not.
The whitelist can be seen in Webkit's source when searching for "shouldBypassUserGestureRequirementForWebAuthn" or any of the whitelisted domains: dropbox.com, microsoft.com, google.com, twitter.com or facebook.com
I am saying from very practical experience this is not well made and shouldn't have been shipped to users in its current form.
There are better examples how to avoid users getting spammed with any requests, browsers have a long history of dealing with that kind of abuse much better.
This patch loosens the user gesture requirement around using WebAuthn with respect to user gestures by removing the Quirks.h allowlist of sites that get a freebie.
Instead the new behavior is all sites get one freebie, then on subsequent attempts they show a non-modal consent dialog.
--- end quote ---
> There are better examples how to avoid users getting spammed with any requests, browsers have a long history of dealing with that kind of abuse much better.
They really don't have much better solutions than requiring user interaction. Even Media Engagement Index that you mentioned is used by Chrome only on desktop and by calculating user interaction.
[1]: https://support.yubico.com/hc/en-us/articles/360022004600-No...