Web Application Security Working Group Teleconference

15 Aug 2018



wseltzer, pranjal, gmaone, weiler, ArturJanc, tanvi, bhill2, jeffh, deian, Yoav


<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


<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


wseltzer: any specs we should look more closely at?

ArturJanc: please look at sec-metadata
... now shipping in chrome behind flag
... does give apps a way to isolate themselves


<deian> oh yay! i've wanted this for a while

<ArturJanc> yes, thank you Wendy!

<ArturJanc> also https://mikewest.github.io/sec-metadata/

<ArturJanc> might be a little more up to date

wseltzer: are people looking at feature policy?


jeffh: I've asked some questions over in WICG

<deian> we're relying on it quite a bit for cowl

<deian> +1 for webappsec as home



<jeffh> wrt feature-policy: https://github.com/WICG/feature-policy/issues/166


<ArturJanc> thanks for chairing & scribing, wseltzer@!

<deian> thanks!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/15 16:58:02 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/40-50/under 40/
Succeeded: s/@@/Artur/
Succeeded: s/chrom/chrome/
Succeeded: s/hm, i tried to join and was told call was cancelled//
Succeeded: i/any specs we/Topic: AOB
Succeeded: i/San Diego/https://www.w3.org/Privacy/permissions-ws-2018/cfp.html
Present: wseltzer pranjal gmaone weiler ArturJanc tanvi bhill2 jeffh deian Yoav
No ScribeNick specified.  Guessing ScribeNick: wseltzer
Inferring Scribes: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2018Aug/0013.html

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

Found Date: 15 Aug 2018
People with action items: 

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.)

[End of scribe.perl diagnostic output]