Web Application Security Working Group Teleconference -- 15 Aug 2018

<bhill2> hi.

<bhill2> are we waiting for folks to join?

ArturJanc: HTML sanitiazation proposal
... I'll give a link in IRC

<ArturJanc> https://docs.google.com/document/d/1CHiEKgLWizb9RbJolIstJa-htvby7t8-KaGgQ4xa-9s/edit

weiler: Permissions and User Consent workshop
... under 40 people to discuss saner permissions management for APIs

<inserted> https://www.w3.org/Privacy/permissions-ws-2018/cfp.html

weiler: San Diego September 26-27
... deadline this Friday
... PC includes a number of browsers, academics

Charter

<weiler> https://www.w3.org/2011/webappsec/webex.html

Current charter

wseltzer: please take a look at the charter to see if your topics of interest are in-scope

bhill2: UI Security should probably be removed from scope and deliverable
... no UA interest

<bhill2> superseded by: https://szager-chromium.github.io/io-v2/#calculate-visibility-algo

bhill2: intersection observer v2 supersedes

@@: some aspect seem more privacy than security

scribe: and webappsec has been a good place for that
... should we include that in charter?

wseltzer: since PING is not a spec-producing group
... this group could be a relevant place

Artur: consider examples such as Storage Access API
... so add privacy to the scope
... to acknowledge explicitly

Yoav: question
... we've been running into issue related to cookies
... CSP cookie-controls would have helped agaainst, but obsoleted
... why was it obsoleted, were alternative mechanisms proposed?
... problems we're encountering: shared TLD on which customers can set subdomains
... and we want to prevent them from setting cookies on the TLD

ArturJanc: speculating, I think Mike is trying to replace cookies with browser-controlled tokens
... rather than server-sent
... and didn't see a lot of interest in cookie-controls
... an option is to add the domain to the public suffix list (PSL)

yoav: re proposal to replace cookies, in whose lifetime can it happen?
... in the meantime, it would be great to have some better controls

weiler: other than PSL, what other mechanisms have been proposed?

tanvi: there was also the suborigins proposal
... that might help in segregating sub-domains
... hasn't gotten full browser support

weiler: does that work if they haven't yet visited the TLD?

tanvi: the subdomain would have a sub-origin specified

yoav: would that prohibit setting cookies on the +1 even with JS?

tanvi: not with that proposal

yoav: we can have controls on the headers for Akamai's use-case
... but then the content can still do things

tanvi: if you set sub-origin, anything you do is set in that sub-origin
... chrome may have implemented behind flag
... so you might look at that option

ArturJanc: also cookie prefix proposals, but not a clean mapping to what Yoav is looking for

jeffh: is the use case written down? that would be very helpful

yoav: I'll send to the list

HSTS super-cookies

weiler: is there anything we can do to mitigate HSTS super-cookies?

jeffh: it was known issue at time of RFC 6797
... but I don't think so
... any time server side can set state on client side, you'll have this kind of issue

weiler: usual client mitigations of deleting history and cookies don't get this

jeffh: server can just be cleverer

<jeffh> wrt HSTS "super cookies" -- https://tools.ietf.org/html/rfc6797#section-14.9

ArturJanc: what's the specific issue?

jeffh: depends on how browser implements HSTS policy store

<ArturJanc> tanvi: what does Firefox do?

jeffh: we know it can be abused, and is implementation-dependent
... maybe we'll come up with better ideas over time

<pranjal> wrt webkit: https://webkit.org/blog/8146/protecting-against-hsts-abuse/

<weiler> https://www.usenix.org/conference/foci18/presentation/syverson

jeffh: I haven't worked on it in a while
... explore how policy stores are implemented in browsers

weiler: Syverson paper at FOCI ^

jeffh: it's a general class of issue, anything that can set client state
... arbitrarily from the server side
... so it would be good to think more generally

<ArturJanc> FWIW we wrote up a list of storage mechanisms some time ago: https://www.chromium.org/Home/chromium-security/client-identification-mechanisms#TOC-Explicitly-assigned-client-side-identifiers

wseltzer: Possibly a useful discussion in PING, to gather experience and ideas

weiler: Paul's best suggestion was move more quickly to complete deprecation of HTTP

jeffh: when you can test for state change / state retention from server side, then you'll have information conveyed from client to server

weiler: both general problem, and it's still useful to play whac a mole
... inspired by ESNI discussions

deian: Two dimensions of privacy problem
... supercookies
... and cross-origin access to information
... even if it's impossible to stop supercookies, can restrict the cross-origin leakage

weiler: part of the HSTS issue is that it's not info transported in an HTTP stream, but side-effect of other look-ups
... Safari has looked at mitigations involving domain name filters

deian: more general privacy issue
... parts of browsers leak information cross-origin
... short paper on visited links and buffer cache
... any place in the browser that's storing
... it's a matter more of changing implementations than spec
... I'll post a link

<deian> https://cseweb.ucsd.edu/~dstefan/pubs/smith:2018:browser.pdf

<deian> michael's talk will be up soon too

<deian> :)

deian: COWL implementation is pretty much ready for chrome
... eager to talk to more people about implementation
... chrome, firefox