LGTM3 and apologies for the delay. Part of the reason for the slow reply was an attempt to tackle the arguments that Tantek raised here which I suspect will be used on a loop as this conversation moves forward with respect to other APIs that have similarly narrow-but-important use-cases:
https://github.com/mozilla/standards-positions/issues/453#issuecomment-888225596 Briefly, we should note the structural protections built into the API shape: - The usual TLS and top-document restrictions are in place for powerful APIs. - Integration with the Permissions API is provided and use is gated on an async request <https://github.com/WICG/idle-detection#example> (per TAG design guidance) These might not sound like much, but together they create the substrate we need to allow UAs to fully control the UI they present to users about this capability. Scenarios that are enabled by this, based on browser policy, could include any policy regime (from most to least restrictive): - Blanket denying the capability - Only allowing the permission to be granted post some user-consent gate and with other gating factors, e.g.: - Only if installed as a PWA - Only if the site has a high-enough "reputation" - Only if the site has garnered enough engagement (e.g. chrome://site-engagement score) on the local device - Only if the user also grants other permissions more associated with classes of applicsations that have "legitimate" (however that's defined) uses in the eyes of the browser vendor - Only if developers register their use with the browser (e.g., Chromium Origin Trials) - Only allowing post user consent - Potential grants on any page that meets minimum technical criteria The key point here is that movement between these states won't require an API re-design or for developers to experience breaking changes (in the form of exceptions, although UI treatments may be in want of updating in response to policy changes). All of that argues in opposition to the claim that this is harmful on some ground that cannot be mitigated by sufficiently invested and interested browser vendors. Should harms of the sort Tantek raises arise, not only is the UA *more* in charge of usage reporting when developers adopt the Idle Detection API (as opposed to today's piles of hacks), but semantic transparency provides space for UAs to be *more aggressive *in tamping down the sorts of fingerprinting-esque behavior we see right now. For all of those reasons, in this and in other APIs that provide explicit surface for what was previously an implicit hack-based mechanism that was not similarly limited, cabined, and semantically transparent, my vote will be an LGTM. It is bad policy for UAs to be in the business of saying "something bad might happen!" rather than weighing up the real consequences and maintaining a position through APIs to most-probably mitigate harms directly. Abdication is not a path forward. Thanks for making this possible, Reilly. Regards, Alex On Tue, Aug 17, 2021 at 4:55 AM Yoav Weiss <[email protected]> wrote: > LGTM2 > > On Tue, Aug 17, 2021 at 11:19 AM 'Thomas Steiner' via blink-dev < > [email protected]> wrote: > >> For the record, the polyfillable part of the API (that is, detect if the >> user has the tab focused and is interacting with the document) was >> requested by developers as a special "mode" one could set when activating >> idle detection. See https://github.com/WICG/idle-detection/issues/36 for >> the details. The use case here was not notification deduplication, but >> collaboration on a shared document. >> >> On Tue, Aug 17, 2021 at 1:17 AM Chris Harrelson <[email protected]> >> wrote: >> >>> Thanks for all these responses! >>> >>> LGTM1 >>> >>> On Mon, Aug 16, 2021 at 4:13 PM Reilly Grant <[email protected]> >>> wrote: >>> >>>> On Mon, Aug 16, 2021, 7:11 PM Chris Harrelson <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Mon, Aug 16, 2021 at 3:25 PM Reilly Grant <[email protected]> >>>>> wrote: >>>>> >>>>>> Finally, I don't believe that the concerns of behavioral tracking are >>>>>> well-founded. This API provides a higher-resolution indication of the >>>>>> current state but in order to establish patterns the site performing the >>>>>> tracking must be continuously active. Such a site, even without this API, >>>>>> can already create such a profile by observing when the site is visible, >>>>>> when the user interacts with it as well as background events such as >>>>>> system >>>>>> suspend and network changes which can be observed by any page allowed to >>>>>> continuously execute script. The additional information provided by this >>>>>> API does not seem particularly novel to such an attack, but is critical >>>>>> for >>>>>> the real-time messaging applications the API is targetting. >>>>>> >>>>> >>>>> Another argument made by a Webkit representative was that since sites >>>>> can already do the things you specified above, they can keep doing that >>>>> and >>>>> this API is not necessary. The Webkit representative arbitrarily ended the >>>>> thread at that point without giving you an opportunity to reply, so for >>>>> the >>>>> record could you reply to that argument here? >>>>> >>>> >>>> This API is impossible to polyfill because the definition of "idle" it >>>> uses includes input to the system as a whole and not the currently focused >>>> window. This is necessary in order to achieve the goal, which is to allow a >>>> window that is currently in the background to determine whether or not the >>>> user is still actively using the system. As an example, imagine that you >>>> were editing a document in one tab while chatting with a coworker in >>>> another. Once you switch to editing the document the messaging app cannot >>>> observe whether you are still at your computer because it is no longer >>>> visible or focused and so gets no input events. You could be using another >>>> app or you could've gotten up to make coffee. The feedback from users of >>>> messaging applications is that it is annoying when their phone constantly >>>> notifies them of new messages when they are still at their desk and using >>>> their computer. This API is necessary to provide a signal that can >>>> differentiate between these two cases. >>>> >>>> >>>>>>> On Wed, Jul 28, 2021 at 8:29 AM [email protected] <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thomas Steiner schrieb am Dienstag, 27. Juli 2021 um 11:11:29 UTC+2: >>>>>>>> >>>>>>>>> On Mon, Jul 26, 2021 at 10:51 PM Reilly Grant <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Gecko: No signal ( >>>>>>>>>> https://github.com/mozilla/standards-positions/issues/453) >>>>>>>>>> >>>>>>>>>> WebKit: Negative ( >>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2020-October/031565.html >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>> >>>>>>>> Mozilla's position gets even more negative now: >>>>>>>> >>>>>>>> https://github.com/mozilla/standards-positions/issues/453#issuecomment-888225596 >>>>>>>> >>>>>>>> jj >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e36d42-9a51-45a6-92cf-0b4b543092ben%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e36d42-9a51-45a6-92cf-0b4b543092ben%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMZ7W6-pucx95eAZ8K-DBwQEZ%3DSLtewgkZVHts59xsARZw%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMZ7W6-pucx95eAZ8K-DBwQEZ%3DSLtewgkZVHts59xsARZw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >> >> -- >> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, >> https://twitter.com/tomayac) >> >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.1.23 (GNU/Linux) >> >> >> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. >> hTtPs://xKcd.cOm/1181/ >> -----END PGP SIGNATURE----- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLkFeQszAdrceNCDU4%2BrO36%3DS_deq3T4iVgDjZ1D%2BbhOmw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrLkFeQszAdrceNCDU4%2BrO36%3DS_deq3T4iVgDjZ1D%2BbhOmw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWF%3DUpG-MZkz8UsUDofF0zQ_w1_-nK6a9H00rhyNzUTcw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWF%3DUpG-MZkz8UsUDofF0zQ_w1_-nK6a9H00rhyNzUTcw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQgrNfGDLJJKDiE0rwoUmu5gVAd5%3DF5yaLqYRHbEkyp70A%40mail.gmail.com.
