#878: systemEntropy addition to PerformanceNavigationTiming

Visit on Github.

Opened Jul 25, 2023

I'm requesting a TAG review of systemEntropy addition to PerformanceNavigationTiming.

This proposal adds a new ‘systemEntropy’ field to the PerformanceNavigationTiming struct enabling developers to discern if the page load occurs during a non-optimal performance state.

  • Explainer¹ (minimally containing user needs and example code): url
  • Specification URL: N/A
  • Tests: not yet
  • User research: N/A
  • Security and Privacy self-review²: url
  • GitHub repo (if you prefer feedback filed there): N/A
  • Primary contacts (and their relationship to the specification):
    • Mike Jackson (mwjacksonmsft), Microsoft
  • Organization(s)/project(s) driving the specification: Microsoft
  • Key pieces of existing multi-stakeholder review or discussion of this specification: N/A
  • External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5186950448283648

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: [please provide]
  • The group where the work on this specification is currently being done: W3C WebPerf WG
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C WebPerf WG
  • Major unresolved issues with or opposition to this specification: N/A
  • This work is being funded by: Microsoft

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify [mwjacksonmsft]

Discussions

Discussed Sep 1, 2023 (See Github)

Peter: entropy probably the wrong name... I think this is OK but would like to get Rossen's opinion. I have a concern about how this might expose additional fingerprinting surface or allow side-channel attacks. I accept it's "past" state but it's also coming along side of some high resolution timers... which can be used for side-channel attacks.

peter to leave comment

Comment by @plinss Sep 7, 2023 (See Github)

We haven't had a chance to dive into this thoroughly yet, but first impressions:

  • The term "entropy" has a number of other connotations and may not be the best term here. Possibly something like "systemLoad" might be more obvious to users.
  • I don't have specific examples, but this leads to concern about possibly introducing additional information for side-channel attacks or user fingerprinting (see battery status API). I accept that this is past data, but it's strongly correlated with high resolution timers. Have crypto and privacy experts evaluated this aspect?
Comment by @mwjacksonmsft Sep 11, 2023 (See Github)

Thanks for the feedback.

  • I'm open to feedback on the name. I have a concern that 'load' implies some system resource usage is high, which may or may not be the case, especially during cold start where there could be lock contention, or delays while loading binaries off disk.

  • Is the concern that a third-party script is included on siteA and siteB, that the script might be able to create a short-term identifier to track the user across the two sites?

Discussed Oct 1, 2023 (See Github)

Rossen: initial lightweight feedback, well received... it's complex. If the system is already under heavy load you'll experience different performance characteristics compared to if it wasn't. This is one way of allowing you to better profile your payloads. Straightforward from addition pov.

Peter: I asked about side channels and they answered with a question. Also about whether something comes out of a cache or not.. curious if someone can use this flag if the system is lying about other metrics.. depends on how it's implemented. There are other cases where the system is going to load it from the cache but pretend it's nto loading it from teh cache so you don't get a timing attack. Is this going to report that the system is under high load or not? If the system isn't hitting the network it's hitting the cache maybe this would reveal that the other api is lying and expose information

Rossen: the cache api or the performance metrics api?

Peter: the perf metrics of loading. Faking a network request but pulling something out of the cache

Rossen: the system is under normal load, and your nativation takes a long time vs a short time?

Peter: maybe under normal circumstances if the resource wasn't in the cache your system would be under heavy load, but now it's in the cache but your system is pretending to load it, but the system isn't under load, by exposing the system load you can infer that this really was cached after all and we negated the mitigation in the other place where we were lying about the fact it was in the cache. Not perfect, but it's information. Other things like battery status where people can use very scant information to pull pretty accurate information

Rossen: I can remember the battery discussions.. the strong feedback from mozilla at the time. Not sure how this compares to it though

Peter: not convinced this is a problem. Just concerned that it might be and I'd like people who know better to look at it. I can leave the feedback.

Rossen: trying to wrap my head around how detecting of the cache usage happens with this new entropy state. Let's see what they come back with

Comment by @plinss Oct 23, 2023 (See Github)

Is the concern that a third-party script is included on siteA and siteB, that the script might be able to create a short-term identifier to track the user across the two sites?

Possibly, but also that a site may be able to fingerprint a user and tell it's the same user on multiple visits.

We also have concerns about other information leakage, for example there's work being done to hide usage of local cache. E.g. loading a resource from a cache but pretending that it's coming from the network (and adding an artificial delay), being able to measure the entropy may reveal this is happening.

Basically, we like to be sure people who understand these kinds of issues better have reviewed this.

Discussed Nov 1, 2023 (See Github)

Peter: should we defer?

Rossen: yes i think we should wait for feedback.

Discussed Nov 1, 2023 (See Github)

Peter: still waiting for feedback.

Discussed Dec 1, 2023 (See Github)

Peter: we haven't heard back from them on the last reply to their response...

Rossen: let me ping internally and see what's happening with this. They're still interested in moving forward and are going to update soon.

punted for now

Discussed Dec 1, 2023 (See Github)

Pending external feedback on how it fits with the privacy principles.

Comment by @mwjacksonmsft Dec 12, 2023 (See Github)

My apologies for the delayed reply. I'm working with the WebPerfWG to ensure that this information is exposed in a way that conforms with the privacy principles outlined here: https://docs.google.com/presentation/d/19TOz4mXRsYt8tkqzH8io_BrYiZBXhqGyD646gJy-x6I/edit#slide=id.p

Comment by @hadleybeeman Dec 18, 2023 (See Github)

Thanks, @mwjacksonmsft — we'll wait to hear back from you then.

Discussed Jan 1, 2024 (See Github)

Dan: nothing to do here - still pending - assigned Hadley to the issue

Discussed Jul 1, 2024 (See Github)

Still pending external feedback. Have been waiting for 7 months.

Comment by @mwjacksonmsft Oct 17, 2024 (See Github)

Hi Tag -

We've iterated on the design of this API in the WebPerfWG. The explainer, and Chrome status entry pages have all been updated. Updated details are captured in the explainer, but the high-level summary is that the field has been renamed to 'confidence', and noise via a randomized response algorithm has been introduced to reduce fingerprinting risks.

The explainer also gives an example of how a RUM provider might debias the aggregate data.