fix: restore transient activation requirement in show()#1066
fix: restore transient activation requirement in show()#1066marcoscaceres wants to merge 1 commit intogh-pagesfrom
Conversation
|
Please don't merge until we've had an opportunity to discuss this. |
|
haha, totally not. Don't worry... this is going to be a long discussion :) We have the PR template for good reason too. |
|
Hey Marcos; thanks for filing this and #1064 . Totally agree that what's in the spec right now is a hack; we had redirect flows that we needed to have working, and our initial attempt to work with the user activation flows folks ran out of steam, so we did the hacky thing. Time to pay down the debt (and thank you for taking on debt you didn't cause!). I think I would mostly be ok with this revert, though it would be nice to not land it until we see progress in the general solution. Given Chromium would become (and would remain) non-compliant, however, what do you think about the spec noting that some user agents are known to have non-compliant behaviour here? Too much of a violation of spec purity? :) |
|
We could definitely add a big red note to the spec here, as I think this is a really important issue and highlighting what’s been tried in practice is important. Again, the problem identified is very real and critical we find a solution for it. Should we draft something up? |
Reverts the relaxation introduced in #1009 and removes the non-normative "User activation requirement" section.
What changed
[=transient activation=]as a hard requirement inshow()(removes the MAY)Why
The MAY introduced in #1009 means a conformant browser can skip the activation check entirely with no normative constraints. The security mitigations in the removed section were all non-normative suggestions. That is not a spec constraint.
This is also part of a pattern: Digital Credentials and WebAuthn have the same problem and are reaching for the same local workarounds. The right fix is a sanctioned-continuation primitive at the HTML level (see WICG Capability Delegation), tracked in #1064.
Keeping the activation requirement strict here maintains pressure to find the general solution rather than normalizing per-spec workarounds.
closes #1064
The following tasks have been completed:
Implementation commitment:
Optional, impact on Payment Handler spec?
Preview | Diff