systemEntropy addition to PerformanceNavigationTiming

[mwjacksonmsft]

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:

• [x] 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]

[plinss]

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?

[mwjacksonmsft]

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?

[plinss]

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.

[mwjacksonmsft]

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

[hadleybeeman]

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

[mwjacksonmsft]

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.