WebAppSec Teleconference, 19-Oct-2016 -- 19 Oct 2016

<estark> I'm having trouble joining the meeting ("your meeting number is not valid"). has the meeting not started yet?

<bhill2> Yeah, I just sent a request to the systems team @ W3C

<bhill2> looks like our webex reservation got cancelled. :(

<freddyb> I think someone (wseltzer?) has to start it.

<bhill2> will see if it can be reinstated

<freddyb> (Glad I'm not the only one)

<bhill2> hopefully with alacrity

<bhill2> sorry for technical difficulties

<freddyb> ah, new link

<bhill2> Thanks! Is there a dial-in # for that, Wendy!

<bhill2> ?

<bhill2> great!

<bhill2> (OT: I love that the screenshot encouraging you to add the chrome webex extension shows the 2 star rating right there)

<freddyb> wseltzer: can/should I share that link and password on the list?

<mkwst> Thanks, Wendy! I was briefly afraid that I was going to have to install Java. :)

<tanvi> anyone having trouble with we webex?

<tanvi> the one in the email isn't working

<bhill2> see topic of this irc channel

<tanvi> thanks

agenda bashing

Agenda Bashing.

<freddyb> This link doesnt seem to work for me with the WebEx android app ("Problem processing your request")

<bhill2> agenda at: https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0023.html

<inserted> scribenick: mkwst

bhill2: Any additional items?

[crickets]

Minutes approval.

bhill2: TPAC minutes were posted.
... Objections to approval?
... [crickets]
... No objections, approved.

Referrer Policy to CR

Referrer Policy to CR.

bhill2: I am excited!
... I am also putting in changes at the last minute.

<dveditz> freddyb: install java and use the webex link :-)

bhill2: Emily, are there other issues that might block transition to CR besides mine?

estark: No. There's some discussion on the list, but mostly clarification questions.
... I don't think any text changes will come out of that discussion.

bhill2: Any other comments?

estark: No.

Algorithm to censor origin reported by location.ancestorOrigins

<bhill2> according to referrer policy

<bhill2> https://github.com/w3c/webappsec-referrer-policy/pull/77#discussion

<inserted> scribenick: mkwst

bhill2: Then let's come to consensus on the issue I raised.
... https://github.com/w3c/webappsec-referrer-policy/pull/77#discussion
... `ancestorOrigins`. Useful feature for a lot of sites that wish to do anti-fraud while being embedded.
... Mozilla hasn't implemented.
... bz notes that this is a cross-origin information leak.
... Discussion at TPAC
... Agreement that it might be reasonable to gate the reporting of an ancestor's origin based on the asserted referrer policy.
... If a resource is interested in preventing referrer leakage, we can apply that same intent to reporting as an ancestor frame.
... Not entirely uncontroversial.
... Before we dive into the details, what's the consensus of editors and group about whether it's reasonable?

estark: I've flip-flopped on this a few times.
... There are lots of things we might reasonably apply referrer policy to. `Origin` header. Violation reports. Etc.
... Practically, those seem reasonable. I don't think introducing a new mechanism would be a good idea, lots of overhead.
... However, I'm worried about an ever-growing list of things that referrer policy controls.
... As we use RP to control more things, it becomes less usable in a sense.
... `Origin` header in particular.
... Might want to make CORS requests, but not leak data via navigations.
... Is Jochen around?
... [Crickets]

<bhill2> jochen__

estark: We had decided at some point to not control the `Origin` header.
... I don't know if that means that we have to apply that decision to `ancestorOrigins` as well.

dveditz: I tend to agree with bz.
... It's not like we're adding ever-increasing things just to RP, we're adding ever-increasing things to the web.
... Leakage increases over time as we add new features and apply old features to new circumstances.
... I agree that RP gets complex and hard(er) to use, and maybe we shouldn't do that.
... But things get more complex, and the feature might need to get more complex to follow along with the way the world is going.

bhill2: I'm sympathetic to the question of `Origin` for things like form posts, as I don't want to lose that data.
... Direct indication of intent from site to post data, etc.
... HKPK and CSP are also set explicitly by the site.
... Seems like the intent to send the information to a reporting endpoint exists.

mkwst: HTTPS -> HTTP. Might not matter here, since we can't embed HTTP in HTTPS due to MIX.
... Might be other RP directives that do weird things.

dveditz: Right. Don't want to send referrer information from HTTPS over plaintext.

bhill2: According to current PR: blocked via `no-referrer`, HTTPS ->HTTP, `same-origin`, opaque origin (same as status quo).
... `blob:`, `filesystem:` might now report an origin where they previously didn't.
... `same-origin` is the interesting case.
... also discussion in HTML over pairwise comparison between item and every ancestor, or a complete barrier if any ancestor blocks.
... bz in favor of the latter, bhill2 in favor of the former.
... Is this the right place?

<bhill2> a) belongs in referrer policy

<bhill2> b) not in referrer policy

<bhill2> c) do it, but elsewhere

<estark> I'm reasonably convinced by the argument that many other types of referrer-like leakage are things that the site has to opt in to in some sense

bhill2: [Discussion of the PR, and where things are currently defined for `ancestorOrigins` (HTML)]

<estark> (that is, A.)

<bhill2> hat=individual (a)

<francois> Also A for me.

<dveditz> c) (part of ancestorOrigins

bhill2: estark, do you care if this is all in RP, an algorithm in RP, or all in HTML?

<dveditz> though a) is fine too

estark: I think we should say what it's intended for in RP.

bhill2: I hear "Keep the algorithm as simple as possible, but let developers know where/why it's used."

estark: SGTM.

<bhill2> (a) pairwise comparison of context and location to get policy

<bhill2> (b) ratchet behavior, once you get a null, all ancestors are null

bhill2: I see votes for the current split, and a vote for "do it in HTML", which can also live with the current split.

<bhill2> (b) stop evaluation once null encountered

bhill2: What about the ratchet/pairwise comparison?
... [Discussion of use-cases for ratcheting that I didn't really catch.]

<bhill2> mkwst: would want to talk to people at Google using this for anti-fraud before making a change like this

<bhill2> ... pairwise is closet to status quo and so easiest change to make

<bhill2> +1

<estark> +1

bhill2: Right. That's the smallest change, and gives an individual resource control over its privacy, but doesn't impose its decision on others.
... Ok. I'll talk with bz some more, and pull more folks in if necessary/helpful.

<dveditz> don't feel strongly either way. Don't see a particular privacy problem with (a)

CSP Reports: Script-Sample

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0016.html

<inserted> scribenick: bhill2

mkwst: Firefox has script-sample property send back with violation reports
... not clear if it takes subsection or just beginning of script, dumps 40 chars into violation report
... this has lots of value for developers figuring out what caused violations
... especially extensions, lets you tell if it is really your script or someone else's script
... reluctant to do this in Chrome because we intentionally censor cross origin script errors unless they opt in in CORS to prevent info leakage
... contents of inline scripts is another: have vague intuition that they will contain more personalized information than externalized scripts
... a little bit worried about putting that kind of information into violation reports
... will have very different data lifetimes and retention policies than application data
... artur has done a very good job arguing the contra-position
... which is: you have to trust your reporting input, may contain tokens, etc.

dveditz: don't we strip URL params?

mkwst: cross origin and on redirects
... second point of artur is that scripts don't empirically contain sensitive data in first 40 chars
... does mozilla have data about what is being sent in script samples, and what 40 char decision was based on?

dveditz: I don't think any of us on call has looked at that data, but we have it for some of our sites
... probably not sites that use inline scripts, think 40 was a guess by someone not here anymore

mkwst: for artur's use case, figuring out whether violations are noise or not is valuable
... ff dumps external, blocks internal, reports on inline handlers but not content
... artur thinks inline is most useful
... but current moz impl is not useful

I am sympathetic to "you trust your report endpoint" argument for inline + event handlers, scared by it for external scripts

e.g. stuff like guarded JSONP, for(;;);{secret=1}

<dveditz> I would be surprised if we're sending samples of external scripts, because if we have a script-src violation we don't even load the script. how are we getting a sample out of it?

mkwst: I have not looked at FF impl in a few months, may have changed

ckerschb__: we still are (sending)

dveditz: it surprises me we even have the sample if we block the load

mkwst: script can load but does something it is not supposed to do

<ckerschb__> ckerschb__: was me :-)

dveditz: sounds like everyone's behavior needs to change but it is useful for cases artur describes
... maybe think about 30 characters...

+1 but only for inline / event handlers, not for external scripts

jwilander: don't understand the privacy implication

dveditz: you might be using a 3rd party reporting service

jwilander: OK, but artur's argument is that you have to already trust them

dveditz: I agree with mike, I'm surprised that there isn't PII in first 40 character

jwilander: we could restrict to same origin endpoints

dveditz: we could, but I suspect people would find that less useful
... different kind of load than website, frequently offloaded
... and mike is adding a different common reporting mechanism that will encourage a common place separate from website

mkwst: same eTLD+1 would be more workable than same-origin, Google has central reporting point
... concerned that retention policies are different, e.g. if you promise to delete data after a user deletes their account
... what if user data has leaked into a CSP report somewhere else?

+1 to that concern

mkwst: one idea is to make it opt-in

<dveditz> report-uri https://reporting.com 'script-sample'; ?

mkwst: an interesting direction to explore

XSS-Protection

mkwst: consensus on list and googlers not me is to remove binding between strict-dynamic and existing xss auditor
... means we need a new name for header
... who has good idea for this in a new namespace?

https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0002.html

Localhost as a Secure Context

https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0120.html

idea is to make localhost localhost again

mkwst: lots of helpful people are making helpful comments in IETF land
... could add to Secure Contexts that user agents MAY consider localhost secure contexts if they also implement restrictions in draft XYZ
... I'll add that if people are happy with it

jwilander: we would like to take one step further and say that localhost / loopback should only be allowed from a secure context or same-origin context

mkwst: need more telemetry, but would fit in well with other restrictions
... danger is in encouraging people to install sketchy certificates on localhost just to avoid this restriction
... current metrics might tell us how much risk this is

dveditz: what is status of proposal to CORS check localhost?

mkwst: moved to WICG
... it is a complicated problem, shipping a simple prototype is basically worthless, needs more work
... but still want to do it, feedback helpful

SRI Addressable Caching Doc

https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html

<dveditz> thanks to wendy for getting us an emergency call code

- DRAFT -

WebAppSec Teleconference, 19-Oct-2016

19 Oct 2016

Attendees

Contents