Re: PING call - 10 January 2019 - notes and action items

Please note the error - the next meeting will be on Thursday 7 February 2019 at UTC 17

> On 10Jan2019, at 3:06 PM, Christine Runnegar <runnegar@isoc.org> wrote:
> 
> Thank you everyone for joining the PING teleconference today, and in particular, thank you to our guests Yoav, Ilya and Todd from the Web Performance Working Group. Thank you to our scribe, Pete.
> 
> We had a very fruitful discussion concerning the privacy considerations of High Resolution Time 2 and Navigation Timing Level 2.
> 
> You can find the draft minutes here: https://www.w3.org/2019/01/10-privacy-minutes.html

> 
> ——
> 
> Some notes from the call– please note the action items
> 
> Yoav’s slides: https://docs.google.com/presentation/d/1XILXSYFnr4avfFpza8_EqNvRDjtBDPQ569-wWc52PFM/edit#slide=id.p

> 
> => 1. High Resolution Time 2
> 
> Link to draft: https://w3c.github.io/hr-time/

> 
> The specification defines an API that provides the time origin, and current time in sub-millisecond resolution, such that it is not subject to system clock skew or adjustments (i.e. a high-resolution timer on the Web).
> 
> Background:
> 
> (Timing attacks) Initially the specification increased granularity to 1 nanosecond, but that led to abuse, so the granularity was clamped down to 5 microseconds, which seemed to block timing attacks. But, then there was Spectre and Meltdown, so the group decided to take a different approach, and instead to warn implementers of the risk of timing attacks and leave the “clamp down” value to the implementers. It’s possible that in the future, CORS-only mode may be able to bring the resolution back down (i.e. increase granularity) if everything is legitimately readable. The privacy considerations leave the exact value to the user agents and says “the recommended minimum resolution of the DOMHighResTimeStamp type should be inaccurate enough to prevent attacks”.
> 
> Note: There is a big red banner in the draft which says: “Reducing the precision of the DOMHighResTimeStamp resolution. Due to recent developments this may need to increase significantly, but the working group has not yet reached consensus on what the new recommend minimum value should be.”
> 
> (Fingerprinting) There was concern around clock drift being used for fingerprinting purposes, so it is recommended that the global monotonic clock be set with respect to Unix time to avoid exposing new fingerprint entropy. But, generally the WG reached the conclusion that the API does not expose more than what is available at the time.
> 
> Points from the discussion:
> 
> - a recommendation that the group confirm that the reasoning is fully documented in the specification itself
> - question about whether the API could be used for fingerprinting by embedded 3rd parties to escape restrictions on cookies by new privacy innovations in browsers – response: each browsing context has its own zero time, not a known issue
> - question about “exposes a global monotonic clock to the application, and that must be shared across all the browser context” – response: possible to share and to reason about time about some shared origin, but both origins must share with each other to be related => potential privacy concern raised: what if, for example, iframes across contexts are conspiring to identify a user?
> - question about whether the spec allows browsers to treat 1st party and 3rd parties differently, e.g. to decrease fingerprinting – in terms of fingerprinting, 3rd parties tend to be the most concerning, so if a new API is exposing existing entropy, would it be possible to add that user agents may choose to offer different values, including no value to 3rd parties? response: that use case has not been considered, but not aware of other JS APIs where it would return different values depending on whether 1st or 3rd parties, concern about crippling use cases
> 
> Actions:
> 
> - Jason will work with Mike and Pete offline to agree on proposed text to raise an issue in Github (https://github.com/w3c/hr-time/issues) regarding the 1st and 3rd party question
> 
> => 2. Navigation Timing Level 2
> 
> Link to draft: https://www.w3.org/TR/navigation-timing-2/ 
> 
> Navigation timing
> 
> This specification defines an interface for web applications to access the complete timing information for navigation of a document. The goal is to allow developers to measure the time it takes to load their pages.
> 
> Background: Why a new header rather than using access control origin? time-access-origin exposes less information (it does not provide full access to body content and resource headers) and content does not need to be CORS-enabled. Time-access-origin adoption on the Web is not as high as they wanted, so the group is considering modifying it to be some sort of CORS-subset. It’s estimated that 45% more information will become visible. CORS does not explicitly provide the cache state of a resource, but time-access-origin does that in easily obtainable, in non-destructive ways.
> 
> Points from the discussion:
> 
> - query about the decision to make time-access-origin automatically available if there is CORS – response: time-access-origin does not expose more info, if CORS, can already read the content, and anecdotally (from sysadmins) people that put files on servers don’t think to add time-access-origin unless they are asked to do so – two different view expressed, one that it goes against the explicit choice of the developer, and the other that if the developer already trusts the origin via CORS, no issue with exposing time-access-origin, but perhaps an issue of transparency, also a question about whether it would reveal information about user’s DNS/network state that is unexpected and different from revealing information about the content of the resource?
> - question floated about whether a bad 3rd party actor could insert delays in various stages that could be used in nested browsing context to fingerprint (a unique way to create an identifier)
> 
> Actions:
> 
> - Please articulate any privacy concerns about making time-access-origin a subset of CORS under issue 178 at ttps://github.com/w3c/resource-timing/issues/178
> 
> => 3. Mitigating Browser Fingerprinting in Web Specifications
> 
> Link to Editor’s Draft: https://w3c.github.io/fingerprinting-guidance/

> 
> There were a number of outstanding issues, which Nick has addressed – see the issues marked “pending review”
> 
> Link: https://github.com/w3c/fingerprinting-guidance/issues

> 
> Nick also made some changes to the best practices. The 10 best practices are:
> 
> •      Best Practice 1: Avoid unnecessary or severe increases to fingerprinting surface, especially for passive fingerprinting.
> •      Best Practice 2: Narrow the scope and availability of a feature with fingerprinting surface to what is functionally necessary.
> •      Best Practice 3: Mark features that contribute to fingerprintability.
> •      Best Practice 4: Specify orderings and non-functional differences.
> •      Best Practice 5: Design APIs to access only the entropy necessary.
> •      Best Practice 6: Require servers to advertise or opt in to access data.
> •      Best Practice 7: Enable graceful degradation for privacy-conscious users or implementers.
> •      Best Practice 8: Avoid unnecessary new local state mechanisms.
> •      Best Practice 9: Highlight any local state mechanisms to enable simultaneous clearing.
> •      Best Practice 10: Limit permanent or persistent state.
> 
> For further details of the changes that have been made to the draft, see https://lists.w3.org/Archives/Public/public-privacy/2019JanMar/0005.html

> 
> Actions:
> 
> - By Wednesday 16 January 2019, please provide your comments (if any) on the 10 best practices and the issues marked “pending review”.
> - Christine, Nick and Jason (and anyone else who is interested) late next week to review the “pending review” issues, and do a last check of the draft before moving forward to publish as an Interest Group note.
> - Move to adoption as an Interest Group Note.
> 
> => Private browsing mode
> 
> As a follow-up to the discussion in December, Pete shared an initial draft of possible private browsing mode group note in advance of the call. The proposed aims of the document are to give standards authors a commonly understood signal to key off, and to form the basis for an eventual common set of functionality that web authors can target without breaking their applications in “private browsing” mode. 
> 
> Link: https://lists.w3.org/Archives/Public/public-privacy/2019JanMar/0006.html

> 
> Actions:
> 
> - There will be an ad hoc PING call on private browsing mode next week at a time that is more convenient for interested contributors from the APAC region based on the doodle poll results. Christine will email the details.
> - Craig will follow up after the call with Pete regarding his interest in addressing the problem that consumers do not understand what privacy protections they have or do not have in private browsing mode.
> 
> => 5. Next PING teleconference - 10 January 2019 - UTC 17
> 
> Christine (co-chair)
> 
> p.s. If there are any errors in the notes, please let me know.
>

Received on Thursday, 10 January 2019 23:59:08 UTC