Open jumde opened 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
Details here: https://github.com/w3c/hr-time/issues/20