brave-experiments / standards-positions

Experiment for discussing web standards in GitHub issues
Mozilla Public License 2.0
1 stars 1 forks source link

HR Timer #2

Open jumde opened 5 years ago

jumde commented 5 years ago

Details here: https://github.com/w3c/hr-time/issues/20

pes10k commented 5 years ago

Summary of the above:

Reasons to oppose the standard as is:

1) clearly documented privacy concerns with HR timers 2) a longer list of related reasons to be concerned with timers in general 3) very few user-serving use cases 4) a wide range of non-normative text all over the standard 5) and major implementors are already refusing to not implement the core of the standard

Mitigations suggested and rejected so far 1) Gate timers behind existing permissions related to their stated use cases (e.g. if one reason timers are needed is to enable WebVR, fold the timer into the WebVR permission) 2) Disallow in 3p contexts and or script from 3ps (or require user gesture, etc) 3) Add normative mitigations to the standard 4) Standardize the performance.now() end point as an alias to Date.now(), and revisit high-res timestamps when mitigations are ready

In general, I think Brave should oppose the standard (since there is known privacy risk, and implausible use cases), and at the very least follow FF and Safari and alias performance.now()to Date.now() level timestamps