Thank you for the detailed differential threat analysis, SGTM from the permissions side. Glad to see the ongoing work on robust and comprehensive mitigations.
On Friday, October 1, 2021 at 1:41:54 AM UTC+2 Joey Arhar wrote: > > in anticipation of a future world where the preexisting vectors of > snooping have been mitigated > > I am planning on adding a delay to find-in-page in order to mitigate > find-in-page snooping which would work with this feature, beforematch, and > the existing scroll events: > https://bugs.chromium.org/p/chromium/issues/detail?id=1250158 > I am hoping that this mitigation, when complete, will make it harder or > impossible to recreate what the user typed into the find-in-page dialog > regardless of the attack vector and I believe it will be much more robust > than the beforematch mitigations I proposed. > > > For the `beforeMatch` event we requested that if the website does not > reveal `hidden-matchable` content in response to this event, sending the > event be stopped for the reminder of the lifetime of the page. This was to > prevent adding new ways of snooping on what the user types in the > find-in-page box without any user-visible feedback > > > However, back then, we were unsure if there exists a robust solution to > verify that content actually got revealed in response to `beforeMatch`. > There was some discussion about this on the TAG review thread, but I am not > sure if we ended up finding a good approach. Do you think there is a viable > technical enforcement here, for the <details> element? > > This feature is different from beforematch in a couple ways: > 1. We aren't adding a new signal to the page like the beforematch event. > 2. The existing toggle event which would be fired upon expanding the > details element is fired asynchronously, so it wouldn't be able to close > the details element again and undo the scroll "without any user-visible > feedback" as you mentioned. > > Technically, the page could also listen to deprecated mutation events to > be notified when the open attribute is added to the details element, but > this still happens at the same time that the existing problematic scroll > events are fired: synchronously. > Since I don't see the open attribute or the toggle event as being worse > than the existing scroll event, I don't believe we need a mitigation like > we discussed for beforematch. > > On Thu, Sep 30, 2021 at 4:24 AM Balazs Engedy <eng...@chromium.org> wrote: > >> For the `beforeMatch` event we requested that if the website does not >> reveal `hidden-matchable` content in response to this event, sending the >> event be stopped for the reminder of the lifetime of the page. This was to >> prevent adding new ways of snooping on what the user types in the >> find-in-page box without any user-visible feedback; and in anticipation of >> a future world where the preexisting vectors of snooping have been >> mitigated. >> >> However, back then, we were unsure if there exists a robust solution to >> verify that content actually got revealed in response to `beforeMatch`. >> There was some discussion about this on the TAG review thread, but I am not >> sure if we ended up finding a good approach. Do you think there is a viable >> technical enforcement here, for the <details> element? >> On Thursday, September 23, 2021 at 3:37:32 PM UTC+2 Mike Taylor wrote: >> >>> On 9/23/21 8:19 AM, Yoav Weiss wrote: >>> >>> On Thu, Sep 23, 2021 at 9:25 AM Thomas Steiner <to...@google.com> wrote: >>> >>>> Not sure this was discussed before, but could a new boolean attribute >>>> that opts the element in to the new behavior be the answer? >>>> >>>> <details *searchable*><!-- … --></details> >>>> >>> At the risk of jinxing UseCounter metrics >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=690143#c21>, >>> another option would be to spec the `search` event such that >>> `preventDefault()` provides an opt-out here. >>> >> -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc3efcbb-85a8-4689-a892-100b81e4ee70n%40chromium.org.
