Pausing user activation (consume-only-on-reject)

[johannhof]

In privacycg/storage-access#25 there's a discussion on whether the Storage Access API should consume user activation. The intent is to prevent opening popups or performing other user activation gated actions on rejection. But there's a very valid use case for showing popups when storage access was successfully granted. So what we want is transient-on-resolve, consume-on-reject.

What browsers are doing today is simply to add a consume step in the reject case, which is also specified in the SAA draft.

There are easy workarounds that the site can use to get around this restriction, as shown in privacycg/storage-access#25 (comment) (just open a popup before the requestStorageAccess call and close it on success). This hybrid model also isn't clearly defined in https://html.spec.whatwg.org/multipage/interaction.html#user-activation-gated-apis so SAA wouldn't clearly fit any of the descriptions.

A proposed workaround to the abuse case has been to immediately consume activation on API call, but then restore user activation on success by invoking another activation notification. @mustaqahmed brought up some concerns with that in privacycg/storage-access#25 (comment). Particularly the ability for sites to game this system to retain infinite activation is of course a non-starter.

However, we hope that we can standardize on a way to "pause" user activation, initially consuming it and saving difference = current time - last activation, then, later on success, restoring activation with a modified timestamp that is last activation = current time - difference. We could call the concept "Transient conditional activation-consuming APIs".

This way, a repeated successful call of the API would not result in an extension of user activation.

Open Questions/Concerns:

• How do we deal with multiple APIs with overlapping pause states? In the model where a single difference is stored on, say, the window, some API calls would receive their difference from other API calls. There's probably no attack vector here as each call still consumes user activation, but it might confuse developers.
• I'm not 100% clear on the exact changes we'd have to make to the processing model. Intuitively it seems like "pausing" (by resetting last activation and saving difference) would only have to apply to the list of browsingContexts that were affected by the initial activation. Then we would also restore activation only on this list. There may be issues with that, considering that regular consumption operates on all BCs.
• What to do when a new timestamp was set in between pausing and restoration. What if that was done for a different set of BCs?

cc @annevk @Trikolon @bvandersloot-mozilla @mustaqahmed