Privacy issues in differences between API and Polyfilled Implementation

[dvorak42]

From a privacy/fingerprinting point, what are the differences between the current polyfilled implementation and what this API provides access to?

One issue is how the sample interval is measured for taking samples, its not clear from the API whether the timer used to determine when the sampling interval has elapsed is the same as the one exposed in HR-Time, or if its some internal timer that the UA implements. In the latter case, it seems like the frame the sample is taken on could expose a finer grained timestamp or fingerprint (a function containing a million additions to determine how many additions it has performed in the sampling interval)?

How does the transition between paused/started states work? Is there a potential issue where two different sites will see identical timestamps for when one browsing context leaves the foreground and another enters? (this is already an issue with some APIs to a limited extent, but depending on how the API is implemented you might get identical pause/resumptions of tracing rather than approximately correlated events).

[acomminos]

Thanks for the great questions!

From a privacy/fingerprinting point, what are the differences between the current polyfilled implementation and what this API provides access to?

The goal is certainly to provide strictly lower signal than the polyfill. The spec encourages UAs to require a large minimum sampling interval (>10ms) for that reason.

One issue is how the sample interval is measured for taking samples, its not clear from the API whether the timer used to determine when the sampling interval has elapsed is the same as the one exposed in HR-Time, or if its some internal timer that the UA implements. In the latter case, it seems like the frame the sample is taken on could expose a finer grained timestamp or fingerprint (a function containing a million additions to determine how many additions it has performed in the sampling interval)?

The sampling interval is indeed intended to be driven by the same timer as HR-Time, as per the reference to the "current high resolution time" in the take a sample algorithm. I can clarify this.

Can you elaborate a bit more on how you may get unique signal from profiling a function performing a parametric amount of work (e.g. a million additions)? You won't be able to inspect the trace until the profiler is stopped, and stopping is an asynchronous operation that doesn't wait for the next sampling interval to elapse -- I'm not sure how you'd measure the addition count when the sample occurs given that constraint.

How does the transition between paused/started states work? Is there a potential issue where two different sites will see identical timestamps for when one browsing context leaves the foreground and another enters?

This is a good question, and also relevant to #53. My intuition is that we ought to provide guidance such that different documents do not have their timers align on the same sampling interval.

FWIW the Blink implementation does not implement pausing.

[dvorak42]

The sampling interval is indeed intended to be driven by the same timer as HR-Time, as per the reference to the "current high resolution time" in the take a sample algorithm. I can clarify this.

Yeah I think a clarification along this lines would be good. I thought I had seen the blink implementation was using something else for running the sample algorithm, but I might have parsed it incorrectly. I'll take another look.

Can you elaborate a bit more on how you may get unique signal from profiling a function performing a parametric amount of work (e.g. a million additions)? You won't be able to inspect the trace until the profiler is stopped, and stopping is an asynchronous operation that doesn't wait for the next sampling interval to elapse -- I'm not sure how you'd measure the addition count when the sample occurs given that constraint.

I was imagining you'd get a profile of a function and once it completes stop the profiling, then check two frames in the sample to see how far apart they are (revealing the number of additions that the device was able to perform in a period of time). Profiling a few different primitives, you might be able to get some sort of signal. But if the sampling interval is driven by the HR-Time, then I don't think that necessarily exposes any additional information that you would otherwise have access to without this API.

This is a good question, and also relevant to #53. My intuition is that we ought to provide guidance such that different documents do not have their timers align on the same sampling interval.

FWIW the Blink implementation does not implement pausing.

I'd guess that adding some noise/offsets per document might mitigate this somewhere.