Rossen: implementability... my top level understanding is - the authors want to introduce a way for developers to get better details of the user experience... through a set of events they can get back .. in order to help with long running animations. the way they are proposing - having a set of events that are annotating each part of the render pipeline... when you start layout; end the layout; start rendering; end rendering; style, etc... at a high level you can say every browser has these stages - but if you expose this level ... how do you correlate the actual triggers for that long running animation? Maybe there was a user action that invalidated a layout rule? If I go back to the motivation ... to better explain "why" the "sluggishness" is happening. Not able to connect the dots... Maybe need to [read it deeper]. It also overlaps with event timing .. and pre-existing tech.

Dan: is there a cross-browser issue here? Would this only apply to chromium and not gekko, for example?

Rossen: possibly - i know that there are differences... i don't know if by exposing this people will only optimise for chromium ... this isn't clear to me.

Peter: i don't see anything in LoAF that would be problematic for gekko....

Rossen: might see more cross-origin information caused by user inetraction... hover an ad, ad calls "bounding client rect" - now the user can be targetted more..

Dan: that triggers a privacy alarm

Rossen: they do delve into this in the privacy & security consideration section... available to all of the same agent windows -- global state exposure, which is peculiar.

rossen to formulate further response

Rossen: we had a response. There are standards positions.. Good that it's a really early review

Yves: they did request a position from Moz. [and webkit]

Rossen: Still concerned - we are exposing delays and overall sluggishness caused through long running scripts or animation. One of the arguments is that you can observe today cross-origin cross-frame sluggishness by composing fairly well organised rafs on the page and observing them and concluding that the delays may or may not be caused by long running animation or script.. what they're doing here is exposing them and making them even easier to observe and gather and aggregate. So the fact we have this observability cross origin for the same agent doesn't mean we should make it easier. Making it easier cross origin is taking an unwanted pattern and making it easier. Imaginging worse case scenarios, eg. trackers trying to gather information in any possible way, especially cross origin.

Amy: can we ask for threat modeling for worst-case scenarios?

Rossen: yes.

Lea: for early reviews we should focus om more on use cases - how common are they, what's the design space, have they explored other design options, things like that... is this a problem worth solving and is this the right direction?

Amy: if they can articulate the use cases we can encourage them to look for a solution that doesn't increase the attack vectors.

Peter: are we ready to close with additional feedbadck? or do we need some more back and forth?

Rossen: i woulnd't say this is satisfied ... not ready to say unsatisfied but closer to unsatisfied.. Need concrete evidence of why the approach needs more work.. The main points are: (a) interop - how well would this work across engines (good to see they've asked moz and webkit) and (b) the overall extensibility model - for me the major benefit from this is the ability to create causality - "what is causing a chain of events that is resulting in a long running animation?" ... Final bit is : seems we're taking an unwanted pattern and making it much easier to observe...

Peter: so what's the path forward? We could say "we're to see this move forward but want to see work on these 3 areas" -

Amy: based on interacitons from privacy task force with web perf feels like we should push back a little more strongly...

Amy: seems like the argument is based on "if you can get this [data] in other complicated ways then it's better to provide an easier way" which ...

Rossen: I can provide more feedback...

Dan: the text in the ancillary data section of privacy principles is pretty stable and can be referenced in the feecback.

they have replied to rossen's comment - currently waiting for our followup.

triage breakout 2

Hadley, Peter

Tess to ping Dan about this async.

We observe that the spec claims that thresholding durations is an effective mitigation strategy for timing attacks. This is not correct. Thresholding only limits the rate at which information can be extracted. The specification rightly points out that these measurements are already possible, but claims this does not make things worse. This is also incorrect. Being able to measure multiple timing sources at the same time makes the rate of information extraction much higher. This is still probably a worthwhile trade-off overall, but please do not pretend like the risk has been eliminated.

We also noted the monekypatch of WebIDL, hopefully you're talking to the WebIDL folks to get those changes folded in and will be removing the monkeypatch. See our guidance in this area.