- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 17 Feb 2020 16:22:13 +0100
- To: public-web-perf <public-web-perf@w3.org>
- Cc: Ilya Grigorik <igrigorik@google.com>, Philippe Le Hegaret <plh@w3.org>
- Message-ID: <CACj=BEjB0F2QrJ0M97+-mBoeduGdtgqMebwC0jz20ZNAgUAqvw@mail.gmail.com>
The minutes
<https://docs.google.com/document/d/e/2PACX-1vRxTEe9UMR8b-g0bRW2M628KWrxXi-7dqe9T9iy-UdHpQIqj-5wKu3GZSqemFem1NPGb-GCExhYDcfv/pub>
as well as a recording <https://www.youtube.com/watch?v=y5MGi7RHcO4> from
last week's call are now available. Copying minutes here for safe keeping:
WebPerfWG call 13 Feb 2020
Participants
Andrew Comminos - Facebook
Alex Christensen - Apple
Chris Harrelson - Google,
Philippe Le Hegaret - W3C
Nic Jansma - Akamai
Annie Sullivan - Google
Nate Schloss - Facebook
Ryosuke Niwa - Apple
Steven Bougon - SalesForce
Benjamin De Kosnik - Mozilla
Yoav Weiss - Google
Next Call
Feb 27 at 10am PST / 1pm EST
ProposalsisInputPending Update part 3 - Andrew Comminos
- Presentation
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1TICcb6PssfrUOKPuBaAhjmDzL7FN7FQBfZf9bdSsYGU/edit?usp%3Dsharing&sa=D&ust=1581956406060000>
(followup
from last time
<https://www.google.com/url?q=https://docs.google.com/presentation/d/1qgmuSnDIyCbGueW71aGP4NHVpPbcH-_-AAZ_DS-Nbkk/edit%23slide%3Did.g7d00738d02_1_8&sa=D&ust=1581956406060000>
)
- Andrew: Last time we chatted about an issue around child
(cross-origin) IFRAMEs and the parent frame and how isInputPending
hit-testing works if the child frame is possibly moving around
- ...: The current Chromium implementation does not allow sniffing DOM
events dispatched to cross-origin iframes, but could reveal a “proto
intent” to dispatch an event, when the event is not dispatched later.
- Chris: What do you mean by “proto intent”?
- Andrew: the ability to know when an event was going to be dispatched
but then doesn’t get dispatched.
- Ryosuke: That contradicts your statement that the implementation
doesn’t allow sniffing.
- Andrew: You can’t sniff an event, just know that input was thrown away.
- Ryosuke: Doesn’t matter if the event was dispatched.
- Andrew: This is in the context of the locking solution that we talked
about last time, where we can throw away the event if we see it will be
dispatched to the wrong origin.
- Ryosuke: Why do we change our mind?
- Andrew: That assumes the frame moves between those two checks
- Chris: We have a first fast hit test that assigns to origin, but when
we actually do the dispatch when the event task is on the event loop, we do
a more accurate hit test that can show that the DOM was mutated in the
meantime, which can show that the event is dispatched against a different
origin.
- Ryosuke: But the event is dispatched on a frame, how can the second
test conclude that it should go on a different frame.
- Chris: Hit test is on an element and the element that was hit needs to
be determined as part of the hit test algorithm. The frame is determines in
an initial fast hit test, but the exact element determined afterwards.
- Ryosuke: But if the entire frame is moving, how is hit testing finding
that the hit element is outside of the frame?
- Chris: We could dispatch the event using an offset into that frame
from the original hit testing. Is that what you’re suggesting?
- Andrew: That would leak more information
- Ryosuke: In your description, user clicks on the screen and we
determine that it should go to frame A, and isPendingInput is true for
frame A. Then the frame moves. That’s irrelevant, if we initially
determined that the event goes to frame A, it should remain on that frame.
- Andrew: In your example, A can observe that input is queued. During
the time between event detection and dispatch, the parent frame moves the
frame. So it’s possible that the frame will no longer receive the event.
- Ryosuke: Why wouldn’t the frame receive the event?
- Andrew: A task queued to move the frame down or a scroll. So the event
would be dispatched to the main frame instead.
- Ryosuke: Why?
- Chris: I think the semantics Ryosuke is suggesting could be
implemented. When isInputPending causes the event queueing to be observed,
we could implement it so that they would be dispatched to the frame in
which they were observed. So there are cases where Chrome’s implementation
would need to be adjusted, but it would work, and won’t expose any security
issues
- Andrew: Sounds good. Nothing fundemental that prevents us from doing
that. A frame may not detect an event dispatched by a different origin.
- Chris: Right, and whether the event ends up locked to the frame or
discarded…
- Ryosuke: Why would the event be discarded?
- Chris: In scenarios where we notice something is dirty between the
event queueing and dispatch, throwing away the event would avoid a security
issue
- Ryosuke: Is that a thing that browsers do?
- Chris: Not today, but today this is not script observable, where
isInputPending would enable it.
- Ryosuke: if the user clicked and the frame moved, would the click be
ignored?
- Chris: As of Chrome 80 we have an intervention where if an iframe was
moved in the last 100ms, we don’t dispatch to it, to avoid fraudulent
scenarios.
- Post call correction from Chris: it’s actually 500ms
<https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://bugs.chromium.org/p/chromium/issues/detail?id%253D603193%26sa%3DD%26ust%3D1581756612494000%26usg%3DAFQjCNFb6dEqh03Ub8zpNw0Si035-xNayw&sa=D&ust=1581956406065000>
- Yoav: This is tackling a different scenario
- Chris: Sure, but Ryosuke was asking for examples
- Benjamin: And then the event will get discarded.
- Andrew: One of the consequences is that isInputPending requires
another source of time to yield, to avoid scenarios where we’re starving
everything other than input.
-
- Yoav: 100ms seems like a lot, but otherwise makes sense.
- Ryosuke: One question - have we talked to library authors? Interest
from them?
- Andrew: React folks are onboard. Chris - any other frameworks?
- Chris: No other frameworks, but Google properties want it for the
exact same reasons. Ads had good performance at the OT, as well as GSuite
which improved load times by yielding less when there’s no input. They saw
very large numbers.
- Benjamin: Feedback from GSuite folks about multi-user on a GDoc?
- Yoav: I think we’re missing “isInputPending”, is what Benjamin is
suggesting. Could be delays for input from other folks on other machines.
- Andrew: Could incorporate it to your scheduler, and read interrupts.
- Chris: isNetworkPending would help for that use-case. Good point.
- Yoav: Would be interesting to ask them that.
Cross-origin IFRAME opting-in to sharing ResourceTiming data
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/210&sa=D&ust=1581956406067000>
- Nic: Presented at TPAC last year, but still interested in pursuing.
Resource timing data today is helpful but not giving the full picture, due
to cross-origin iframes. Can’t get performance entries from cross-origin
iframes. Over 30% of resource fetches are invisible to RT data, accounting
for 50% of bytes. So when an analytics provider is trying to report
resource sizes to developers, we’re not getting the full picture.
- …: Proposal is to let ad providers and social widgets to opt-in to
sharing their data, to offer transparency and show that they are performing
well.
- …: Takeaway from TPAC was to find concrete examples of people that
would use this. Talked to mPulse customers. Other folks interested was the
Google Ads team that chimed in on the thread. Talked to other folks that
resulted to synthetic testing for that purpose. But synthetic is not the
real world. So would be great to get it in RUM.
- …: Latest proposal is an opt-in. Can reuse TAO or add a similar header
that would be that explicit opt-in mechanism. Based on the feedback the
latter would be a better way.
- …: There are also ergonomics questions on how developers could access
that data. I like it to be an extension to PerfObserver that bubbles
entries from same-origin and opted-in cross-origin ones to their parent. So
that way, you don’t need to access the frame at all, just some of its data.
- …: Also need to see what data can be bubbled up. Can we expose full
URLs or just domains? For mPulse, the more accuracy the better. Certainly
want a number of bytes.
- …: So, next steps?
- Yoav: First step is to figure out if this increases the attack surface
that resource timing opens up. We currently have a few issues open related
to RT and detailed reporting for credential resources. Assuming a
double-keyed cache world, this doesn’t necessarily increase the risk. Maybe
we need to also assume a no-third-party cookie world for that, which would
mean it would be further out. But this seems like the the main risk for
this feature.
- Alex: If we restricted this to not cover credentialed requests, would
that still cover Nic’s use case?
- Yoav: Most of these third party iframes are not currently requested
credential-less, so they have to change the way in which they operate in
order to actually opt-in. Agree that it would make the security story
significantly simpler.
- Nic: So `crossorigin=anonymous` attribute on the iframe?
- Yoav: Yeah, but I don’t think it cascades, so we’d need to make sure
that all subresources are also credential-less, which seems like a lot of
change. Maybe CO{R,E,O}P would have some “fetch everything credential-less”
mode, not sure.
- …: Maybe would be good to start looking at this for credentialed
requests and see if we can get away with that. Makes sense?
- Alex: Yeah.
- Nic: Other concerns?
- Ben: No concern, but this seems to answer a pressing concern. Taking a
step back, the proposal seem framed for CDN providers to exert influence on
ad providers, but would rather see something like this that site providers
can add to demand that ad providers be more transparent. Was that
considered?
- Yoav: This will significantly increase the security risk, as the site
owner can be evil.com and can use that to extract credentialed resource
sizes
- …: Alternatively, you could say “my third parties don’t load unless
they are transparent”, which would be safer
- Benjamin: We don’t want to provide that power
- Yoav: Can you clarify?
- Benjamin: Site providers have no control over which ads are shown on
their pages. Would be good if they could audit that. Not possible right now.
- Nic: Synthetic can give you a sample, but not a real-life sample
- Benjamin: I guess I’m disturbed by the limited reach of this proposal.
Site providers don’t have control over what’s loading on their site. Would
be good to aggregate some information on what’s happening at particular
points in time. Disturbed by the reach of this proposal. Want to give more
power to site owners
- Nic: This would also enable a blog to get visibility of their 3Ps, if
large pubishers cause 3Ps to be more transparent. Not pitching just for
large companies.
- …: Had a few customers with multiple domains and we have custom
solutions to pass this information from one domain to the other. This would
enable a general solution for that.
- …: Also talked to MSN where they have a huge synthetic lab, but why
can’t we do this in RUM
- Benjamin: small first step, but disappointed by the limited scope
- Yoav: Maybe you could join forces on the proposal and see if we can
increase its scope
- Benjamin: Lack of real page weight analytics is a real problem.
Adoption for isInputPending
- Yoav: Going back to isInputPending. Can we get a sense for willingness
to adopt this work?
- Ryosuke: Idea seems OK. Not a lawyer though.
- Yoav: We’ll send a relevant CfC, but wanted your opinion
- Ryosuke: seems useful, no privacy and security concern, as we review
more we may find hidden issues, but so far seems OK.
- Benjamin: Not gonna object
Layout Instability
- Annie: Want to add some debugging information to the Layout
Instability API
- Add a list of the top N nodes that contribute to the changes
- Feedback?
- Nic: Just starting to add Layout Instability, looking at CLS.
Everytime we add a metric, we need to explain it and what’s impacting it.
Debugging information always helps.
- …: Having a list of nodes - we’ll probably collect the data and beacon
it as supporting information. Need to figure out what information we can
capture and transmit. A list of nodes seems straightforward and useful
- Benjamin: Thumbs up. Need to make the web more transparent
- Yoav: Thanks for the feedback!
IssuesSecurer Contexts and performance APIs
<https://www.google.com/url?q=https://github.com/mikewest/securer-contexts/issues/4&sa=D&ust=1581956406073000>
- Yoav: Proposal from Mike West on taking the definition of secure
context to the next level
- …: "securer contexts" - we’re mostly interested in isolation
- …: Concerns around exposing performance.* information (now(), resource
timing data, memory API) and side-channel leaks in non-isolated contexts
- …: High(er) precision timers and memory information could be allowed
behind isolated contexts that guarantee they're not leaking to any other
origins (COOP/COEP/CORP)
- …: Due to attacks like Spectre, performance.now()'s precision was
reduced
- …: Could allow high(er)-precision timers (and more details like memory
info) in those isolated contexts than what performance.now() gives as of
today
- ...: Pushing back that resource timing information is exposing
anything beyond what load events/SW can see today, and already has a
mechanism to opt-in to exposing detailed timing information via TAO header
- …: Plan to discuss this more to see if there are threats I’m missing,
but interested in the group’s opinion. If we assumed that we defined a new
type of isolated contexts, does it make sense to expose the memory APIs and
higher precision timers in those contexts?
- Ryosuke: Timing attacks are a threat for cross-origin leaks, which
isolation helps. There’s also the security aspects, where isolation won’t
help. There are known techniques to defeat ASLR with high precision timing.
Would be fine with it as long as it doesn’t pose a new threat beyond
SharedArrayBuffers.
- Yoav: Makes sense.
- Ben: Would like to see finer-grained control in secure contexts over
the information that could be exposed. Want to give people control over
what they are allowing.
ResourceTiming issues
- Yoav: A few issues filed by PING
- Consider removing nextHopProtocol as it may expose whether visitor is
using VPN / proxy
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/221&sa=D&ust=1581956406075000>
- Consider removing wildcard option of the `Timing-Allow-Origin` header
to prevent browser history leakage
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/222&sa=D&ust=1581956406075000>
- Consider removing wildcard option of the `Timing-Allow-Origin` header
to prevent accidental application state leakage
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/223&sa=D&ust=1581956406076000>
- …: nextHopProtocol enables to see if the user is behind a proxy is
some scenarios
- …: Other 2 issues are the same one: Some scenarios where sites provide
TAO opt-in over credentialed resources, the transfer size can leak cookie
sizes and therefore leak user history.
- …: A real issue raised by the PING. We’ll need to talk about
mitigations.
- …: e.g. eliminating cookie headers from transfer sizes, fuzzing for
credentialed resource fetches, etc. We’ll talk more in a future call.
On Mon, Feb 10, 2020 at 11:35 AM Yoav Weiss <yoav@yoav.ws> wrote:
> Hey all,
>
> Join us <https://meet.google.com/agz-fbji-spp> this Thursday to discuss a
> bunch of proposals as well as issues. On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.568sew3c4803>
> we have:
>
> -
>
> Proposal discussion
> -
>
> Cross-origin IFRAME opting-in to sharing ResourceTiming data
> <https://github.com/w3c/resource-timing/issues/210>
> -
>
> Issues
> -
>
> Long Tasks
> -
>
> Event loop timing reporting seems to ignore reentrancy
> <https://github.com/w3c/longtasks/issues/76>
> -
>
> Resource Timing
> -
>
> Consider removing nextHopProtocol as it may expose whether
> visitor is using VPN / proxy
> <https://github.com/w3c/resource-timing/issues/221>
> -
>
> Consider removing wildcard option of the `Timing-Allow-Origin`
> header to prevent browser history leakage
> <https://github.com/w3c/resource-timing/issues/222>
> -
>
> Consider removing wildcard option of the `Timing-Allow-Origin`
> header to prevent accidental application state leakage
> <https://github.com/w3c/resource-timing/issues/223>
>
>
> Feel free to add more proposals or issues to discuss, if you have any. See
> y'all Thursday!
>
> Cheers :)
> Yoav
>
>
>
Received on Monday, 17 February 2020 15:22:49 UTC