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>.
