> Though I notice that there were some good comments about documentation in the TAG thread and that documentation should be added before this reaches stable (the sooner the better).
As per the TAG thread, I have opened a PR to add a non-normative note about this to the HTML spec: https://github.com/whatwg/html/pull/7229 On Thu, Oct 14, 2021 at 12:05 PM Daniel Bratell <bratel...@gmail.com> wrote: > Though I notice that there were some good comments about documentation in > the TAG thread and that documentation should be added before this reaches > stable (the sooner the better). > > /Daniel > On 2021-10-14 21:02, Daniel Bratell wrote: > > LGTM3 > > /Daniel > On 2021-10-07 21:07, Mike West wrote: > > LGTM2. > > Please do follow up on any feedback you obtain from the TAG, since I > believe the review request there is still outstanding. It doesn't appear to > me that there are substantial design questions that are still open, but if > something interesting is raised, we should respond to it expediently. > > In particular, if we do end up deciding that we need an opt-out, it should > be straightforward to ship on top of this feature. > > -mike > > > On Fri, Oct 1, 2021 at 11:42 AM Balazs Engedy <eng...@chromium.org> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc3efcbb-85a8-4689-a892-100b81e4ee70n%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Ddta1BOirR73vuy61808GHRYUXT4n95CFA6j9jdg0WBSw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Ddta1BOirR73vuy61808GHRYUXT4n95CFA6j9jdg0WBSw%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c66847c5-80bd-1ebb-7e86-b1f61467507c%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c66847c5-80bd-1ebb-7e86-b1f61467507c%40gmail.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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BswJ9oydgEPy7Uy0cjVtoOEebtX%3Df7aLMxezaWpkV6Pg%40mail.gmail.com.
