Re: [w3ctag/design-reviews] User Activation v2 (#295)

While we agree that a time-based activation expiry is not ideal, it seems unavoidable in practice:

- Most major browsers (Chrome, Firefox, Safari [as of 2017](https://docs.google.com/document/d/1hYRTEkfWDl-KO4Y6cG469FBC3nyBy9_SYItZ1EEsXUA/edit#heading=h.veo2srmup0zr
)) have been allowing popups for a `window.setTimeout()` delay of at most one second---even though there was no spec requirement for this.

- If we don't have an expiry time for user activation, a malicious app could open a popup or go fullscreen minutes or hours after a user interaction (say by deliberately slowing down an event handlers, or through a "slow" `Promise` chain).  We don't find this acceptable in Chrome from security perspective, and we believe this is why most major browsers independently can up with an expiry time (see above).

- In Chrome we had [quite a few](https://bugs.chromium.org/p/chromium/issues/list?q=blockedon%3A696617%20status%3Afixed%2Cverified&can=1) popular bugs (with upto 20 stars) that remained open for many years (upto 7 years) with the hope of finding an ideal user activation model.  We were able to close them this year through the simple expiry-based model of User Activation v2.

One way to _mitigate_ the race is to make the expiry time dependent on device/network speed.  For now, User Activation v2 leaves the expiry time as an implementation defined value, and we hope to come back to it if needed.  We briefly discussed this idea during [our TPAC session](https://drive.google.com/file/d/12-Rk_ycPoTe79BGKgosoPTJpuFWqUSrh/view) too (with, among others, engineers from Mozilla and Safari).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/295#issuecomment-564282548