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.
