<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
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
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
https://github.com/mikewest/sec-metadata
<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?
https://github.com/WICG/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
https://www.w3.org/2018/10/TPAC/
<jeffh> wrt feature-policy: https://github.com/WICG/feature-policy/issues/166
[adjourned]
<ArturJanc> thanks for chairing & scribing, wseltzer@!
<deian> thanks!
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]