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

Proposals

isInputPending Update part 3 - Andrew Comminos

• Presentation (followup from last time)
• 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

• 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

• 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!

Issues

Securer Contexts and performance APIs

• 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
• Consider removing wildcard option of the `Timing-Allow-Origin` header to prevent browser history leakage
• Consider removing wildcard option of the `Timing-Allow-Origin` header to prevent accidental application state leakage

• …: 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.