> 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/CAK6btwKN8w-Pna8v4z7wDodyKy%3DE0No%3DSM2-DXjAgCjSpdy0jg%40mail.gmail.com.
