<craigspi> thank you

meeting starts: Web Perf group is on the call

<inserted> scribenick: pes

<tara> scribe:pes

scribe: web perf is joining the call to discuss perf and security issues

(web perf folks, can you add your full names to the IRC?)

<craigspi> To clarify Craigspi is Craig Spiezle

<christine> https://w3c.github.io/hr-time/

first order of buisness: discuss nav time and hr time 2

<christine> https://www.w3.org/TR/navigation-timing-2/

(can link to slides be shared in IRC?)

yoav: HR and Nav timing slides (link tbd)
... HR time aims to privde higher fidelity timers on the web (higher than 1ms)
... HR increase time to 1ns
... bc of spectre/meltdown, reduced to 1ms + jitter

<npdoty> resolution reduced to 5 microseconds-resolution, or reduced further than that?

yoav: CORS might marshal for higher resolution going forard
... privacy considerations in the doc: 1) vendors are asked to be inaccurate enough to prevent timing attacks
... 2) vendors should be mindful of clock drift as a FP vector

<craigspi> can you expand on clock drift?

<npdoty> “inaccurate enough” or better “imprecise enough”?

yoav: (clarification by yoav) suggested FP mitigation is to not be “too” precise / accurate, to avoiding timing attacks

<npdoty> does “inaccurate enough” imply jitter/fuzz or just rounding off to lower resolution?

<christine> nitin

nitin: should FP mitigations be per user, per browser, or otherwise

todd: may differ depending on browser arch

<tara> Yes.

pranjal: is there jitter related to timers?

<christine> (waiting to get a word in)

yoav: yes, some implementations add, but its not in spec (“innacurate” language is intended to capture)

<npdoty> I’m not sure the current language is capturing those things, fwiw

christine: please use the queue system ya'll

<tara> (If you are on IRC, please add yourself to queue. If on the phone only, we'll do our best!)

weiler: it would be good to document the non-consensus about timer resolution / clamps / etc

llya: this is documented in GH

weiler: kinda sorta, but doc is better

mikeoneill: wonders if embedded 3p could use the API to escape cookie restrictions imposed by vendors. Have spec authors looked into this?

yoav: yes this is a JS api, there is a privacy consideration section, yoav doesn’t see how the API could be used for cookie issues
... the spec authors / groups doesn’t think this is any further identifying than existing FP surface

llya: there are no persistant values

<npdoty> ilya: each browsing context has its own origin time, not shared

llya: we didnt’ see cause for concern regarding this

<npdoty> “exposes a global monotonic clock to the application, and that must be shared across all the browser contexts”

npdoty: spec says there is a global monotonic clock, which seems to contradcit previous statement about having unique clocks in each context

todd: the clock is shared in some ways, and are related across contexts
... but i dont see how that opens attack surface

npdoty: the concern though is about iframes across contexts are conspiring to identify a user

todd: how would that fingerprinting be done in practice though/

npdoty: is the “shared global monotonic clock” shared state, or is it a diff number in diff origins

yoav: it would be different in each window

ilya: if you wanted to do this (FP) today, you would use explict (call cuts out…)

todd: there is a global time origin, and you would compare offsets from the global time, and compare offsets in different origins. So there is global state
... but whether that is useful as a FP mechanism is unclear
... (clarification) I dont know of how that could be a fingerprint

jnovak: nothing in the spec about UAs treating 1 and 3p differently
... this is increasingly important to reduce FP-ability of browsers

<npdoty> or clamp the resolution lower for embedded content, rather than 1p site?

jnovak: there are lots of FP risks, some browsers increasingly want to restrict functionality 3ps have access to, to prevent 3p fp
... ex: could the spec be modified to allow 3p to gie no response

ilya: no, since its a JS api, code runs in the first party context; its uncommon to distingusih in that way

yoav: for 3p iframe, that could be diff

<npdoty> limitations on functionality in iframes is pretty common

ilya: 3p iframe is 1p in its own iframe…

jnovak: yes, but vendors / people think about that as 3p
... thats where restrictions might be useful

mikeoneill: ex cookies

<npdoty> payment access (maybe camera access), lots of things have to be passed on as policy to embedded iframes

ilya: this might not work, and there are use cases that require HR time (e.g. animation)
... so that’d cause web break in some cases

<npdoty> that’s useful to know, regarding which use cases are likely to be common in embedded iframes

<npdoty> first parties could also pass on policies — indicate that this iframe needs to have high-resolution time

jnovak: point taken, but suggestion is to make explicit suggestion in standard that vendors might want to treat 3p diff for fp protection
... might be better to rasie on GH

(yes :P)

<npdoty> (allowfullscreen is another example)

yoav: moving to GH sounds good

christine: lets move to Nav timing

yaov: Nav timing is intened to allow sites to measure how long it takes users to nav to their pages
... (shows slide that shows a large number of possible timers, not all of which are exposed in all cases)
... these are intended to be shown in same origin, or when origin has opted in with header

<igrigorik> (waves) just in case, slides @ https://docs.google.com/presentation/d/1XILXSYFnr4avfFpza8_EqNvRDjtBDPQ569-wWc52PFM/edit

yaov: (walks through usec case on page 9 and 10 of above slides)

<npdoty> it’s not just information contained in the resource that might be exposed, right? my DNS cache, etc. is also revealed if that Time-Allow-Origin is *

yaov: why a new header instead of existing options (i.e. ACAO)? A: TAO (the new header) exposes less information, doesn’t require CORS, etc

<jnovak> @weiler, I will later today and send to the group

yaov: TAO has less-than-desired adoption, so might become a suggested CORS subset (eg if it passes CORS, then it becomes timing enabled)

+q

scribe: possible problem, CORS does not give cache state information, TAO does

<inserted> scribenick: tara

<npdoty> whoa, those are very distinct meaning, aren’t they?

<pes> …however, its easily deduced anyway

pes: surprised by idea of making TAO automatically enabled

How do you know if people are enabling it?

Seems like an explicit choice server owners have made...this is bold choice

Reply: what we have found is "lack of choice" to add TAO header

People who put these files on servers, don't think to add TAO header until some perf-minded site asks them

It's an assumption -- but: people forget to add opt-in header [in our experience]

pes: can you share any research on this?
... the basis for people neglecting to add header

reply: we don't have research, but anecdotal evidence of this

if we have switched semantics -- what are we exposing that sysadmins don't want exposed?

pes: seems if not dangerous, then maybe "rude"? :-)

<pes> yes :)

christine: if people have made an explicit choice, you are interfering with decision they have stated

<npdoty> doesn’t it reveal information about user’s DNS/network state that is unexpected and different from revealing information about the content of the resource?

mikoneill: sample attack: somebody sets up handler / URL -- service-side - to introduce delays at various stages

Delays can be analysed, fingerprinted

Threat is same as previous timing threat

reply: how would server know it was same user in both cases? Without cookie (for example), doesn't seem a risk

christine: PING thinks a lot about potential fingerprinting risk

<npdoty> I think if the server-side is introducing that kind of information, it would only apply where it already has the user identified

ArturJanc: response to "rudeness" comment - more about not knowing the header exists

we can argue that if developer made explicit choice, we may as well expose the timings, since this is the source the resource trusts

<npdoty> I think there might be confusion about what timing reveals, distinct from the content of the loaded resource

christine: many thanks to Web Performance WG for joining us!

<jnovak> To clarify, the issue on HRT and 1st vs. 3rd parties

Slides link will be shared

Two items to cover: npdoty's work on fingerprinting mitigations, pes on private browsing

fingerprinting mitigations draft

npdoty summary

<yoav> Thanks all! Slides to my presentation are at https://docs.google.com/presentation/d/1XILXSYFnr4avfFpza8_EqNvRDjtBDPQ569-wWc52PFM/edit?usp=sharing

Nick sent message to list, summarizing open issues

Think they are addressed, so time to do wrapup and issue the note

<yoav> resource-timing issue related to TAO is https://github.com/w3c/resource-timing/issues/178

What to do now? Look at the "10 best practices" - see if anything missing/major objections

Look at remaining issues, see if we can just close those

Tried to look at severity of issues this time, more examples.

Will make more versions in future but should finish this one

christine: please folks take a look and give feedback on list. I propose we publish as IG note.

Will set up time to go through issues next week once people have had chance to give feedback

Then move to getting it published.

private browsing mode (PBM)

christine - sent out Doodle poll for time to accommodate APAC folks; will schedule based on responses

over to pes

pes: tried to clarify goals; not to say what vendors should do/functionality

but 1. to give authors in-spec way to refer to issues of user privacy expectations

2. establish understanding that users might want extra protections - what a common set of functionality might entail

<craigspi> craig ?

craig: appreciate the work. I have worked on PBM at Microsoft. There is lot of user confusion/misunderstanding

PBM is more about what is stored on computer, not about further tracking (ISPs) etc

pes: is futile to tell vendors what to do in PBM, frankly
... also - Firefox, Brave, others - have more than just device-based data storage in their model of PBM
... goal is just to allow spec authors to cue off user signal of wanting more privacy + respond in-spec

craig: this is a range of services + they are different - suggest up-front to clarify this

<npdoty> I understand the “supporting privacy in standards”, but I’m less clear on what the web-compatibility piece will be — is the idea that sites should know when a user is in private browsing mode and the common set of reduced-functionality in that case?

<craigspi> Pete happy to work with you on this offline

<bennett> sorry, having mic trouble I guess

Need to schedule time for people wanted to work on PBM, also can chat on mailing list

<jnovak> Apologies, I need to drop and join another call. Will follow up on email re: PBM

<bennett> apparently it's not working

<bennett> was going to ask about specific standards that would be different in PBM

Next call?

Feb 14?

Feb 7?

<pes> (thumbs up from both brave folks on the 7th or the 14th)

<craigspi> 7th sounds good to me

Pencil in - Feb 7

Thanks all!

<bennett> 7th works for me

Thanks pes for scribing!

<bennett> I can follow up on listg

<bennett> thanks

<pranjal> jnovak: Is it possible to add the Fingerprinting and PBM (once completed) to the privacy questionnaire?

<npdoty> pes, I’ll follow up on list regarding this private browsing text, and thanks for getting it started!

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/ential/entail/
Succeeded: i/whoa, those/scribenick: tara
Succeeded: i/scribe:pes/scribenick: pes
Present: npdoty pranjal tara pes christine mikeoneill bennett craigsi DavidDabbs HannahQuay-delaValle Ilya jnovak NitinSarangdhar shivan yoav ToddReifsteck ArturJanc
Found ScribeNick: pes
Found Scribe: pes
Inferring ScribeNick: pes
Found ScribeNick: tara
ScribeNicks: pes, tara

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 10 Jan 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)