15:57:03 <RRSAgent> RRSAgent has joined #webappsec
15:57:03 <RRSAgent> logging to http://www.w3.org/2016/10/19-webappsec-irc
15:57:22 <bhill2> bhill2 has changed the topic to: https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0023.html
15:57:36 <bhill2> Meeting: WebAppSec Teleconference, 19-Oct-2016
15:57:41 <bhill2> Chairs: bhill2, dveditz
15:57:43 <bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0023.html
15:57:47 <bhill2> present+ bhill2
15:59:12 <estark> estark has joined #webappsec
15:59:57 <francois> francois has joined #webappsec
15:59:57 <freddyb> freddyb has joined #webappsec
16:01:38 <estark> I'm having trouble joining the meeting ("your meeting number is not valid"). has the meeting not started yet?
16:01:50 <bhill2> Yeah, I just sent a request to the systems team @ W3C
16:01:58 <bhill2> looks like our webex reservation got cancelled.  :(
16:02:01 <freddyb> I think someone (wseltzer?) has to start it.
16:02:06 <bhill2> will see if it can be reinstated
16:02:10 <ckerschb__> present+ ckerschb__
16:02:13 <freddyb> (Glad I'm not the only one)
16:02:17 <bhill2> hopefully with alacrity
16:02:23 <mkwst> present+ mkwst
16:02:26 <bhill2> sorry for technical difficulties
16:03:30 <teddink> present+ teddink
16:03:52 <freddyb> present+ freddyb
16:03:58 <bhill2> bhill2 has changed the topic to: We are experiencing technical difficulties with the conference bridge...
16:04:03 <estark> present+ estark
16:04:10 <test> test has joined #webappsec
16:04:39 <timbl_> timbl_ has joined #webappsec
16:05:16 <francois> present+ francois
16:07:51 <freddyb> ah, new link
16:07:55 <bhill2> Thanks!  Is there a dial-in # for that, Wendy!
16:07:57 <bhill2> ?
16:08:05 <wseltzer> wseltzer has changed the topic to: webex 643 678 745 +1 617-324-0000
16:08:10 <bhill2> great!
16:08:35 <bhill2> (OT: I love that the screenshot encouraging you to add the chrome webex extension shows the 2 star rating right there)
16:08:41 <wseltzer> regrets+ wseltzer
16:08:41 <freddyb> wseltzer: can/should I share that link and password on the list?
16:08:45 <mkwst> Thanks, Wendy! I was briefly afraid that I was going to have to install Java. :)
16:08:47 <tanvi> tanvi has joined #webappsec
16:09:06 <tanvi> anyone having trouble with we webex?
16:09:14 <tanvi> the one in the email isn't working
16:09:24 <bhill2> see topic of this irc channel
16:09:28 <wseltzer> wseltzer has changed the topic to: WebAppSec: New webex 643 678 745 +1 617-324-0000
16:09:43 <dveditz> present+ dveditz
16:10:06 <tanvi> thanks
16:10:15 <tanvi> present+ tanvi
16:11:37 <bhill2> TOPIC: agenda bashing
16:11:37 <mkwst> TOPIC: Agenda Bashing.
16:11:44 <freddyb> This link doesnt seem to work for me with the WebEx android app ("Problem processing your request")
16:11:55 <bhill2> agenda at: https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0023.html
16:12:02 <mkwst> bhill2: Any additional items?
16:12:33 <mkwst> [crickets]
16:12:39 <mkwst> TOPIC: Minutes approval.
16:12:46 <mkwst> bhill2: TPAC minutes were posted.
16:12:51 <mkwst> ... Objections to approval?
16:12:54 <mkwst> ... [crickets]
16:13:00 <mkwst> ... No objections, approved.
16:13:16 <bhill2> TOPIC: Referrer Policy to CR
16:13:17 <mkwst> TOPIC: Referrer Policy to CR.
16:13:21 <freddyb> regrets+ freddyb
16:13:27 <mkwst> bhill2: I am excited!
16:13:34 <mkwst> ... I am also putting in changes at the last minute.
16:13:36 <dveditz> freddyb: install java and use the webex link :-)
16:13:46 <mkwst> ... Emily, are there other issues that might block transition to CR besides mine?
16:14:04 <mkwst> estark: No. There's some discussion on the list, but mostly clarification questions.
16:14:14 <mkwst> ... I don't think any text changes will come out of that discussion.
16:14:20 <mkwst> bhill2: Any other comments?
16:14:25 <mkwst> estark: No.
16:14:35 <bhill2> TOPIC: Algorithm to censor origin reported by location.ancestorOrigins
16:14:35 <bhill2> according to referrer policy
16:14:47 <bhill2> https://github.com/w3c/webappsec-referrer-policy/pull/77#discussion
16:14:49 <mkwst> bhill2: Then let's come to consensus on the issue I raised.
16:14:56 <mkwst> ... https://github.com/w3c/webappsec-referrer-policy/pull/77#discussion
16:15:20 <mkwst> ... `ancestorOrigins`. Useful feature for a lot of sites that wish to do anti-fraud while being embedded.
16:15:24 <mkwst> ... Mozilla hasn't implemented.
16:15:33 <mkwst> ... bz notes that this is a cross-origin information leak.
16:15:39 <mkwst> ... Discussion at TPAC
16:16:07 <mkwst> ... Agreement that it might be reasonable to gate the reporting of an ancestor's origin based on the asserted referrer policy.
16:16:33 <mkwst> ... If a resource is interested in preventing referrer leakage, we can apply that same intent to reporting as an ancestor frame.
16:16:44 <mkwst> ... Not entirely uncontroversial.
16:17:06 <mkwst> ... Before we dive into the details, what's the consensus of editors and group about whether it's reasonable?
16:17:16 <mkwst> estark: I've flip-flopped on this a few times.
16:17:42 <mkwst> ... There are lots of things we might reasonably apply referrer policy to. `Origin` header. Violation reports. Etc.
16:18:00 <mkwst> ... Practically, those seem reasonable. I don't think introducing a new mechanism would be a good idea, lots of overhead.
16:18:16 <mkwst> ...However, I'm worried about an ever-growing list of things that referrer policy controls.
16:18:26 <mkwst> ... As we use RP to control more things, it becomes less usable in a sense.
16:18:32 <mkwst> ... `Origin` header in particular.
16:18:45 <mkwst> ... Might want to make CORS requests, but not leak data via navigations.
16:18:51 <mkwst> ... Is Jochen around?
16:18:54 <mkwst> ... [Crickets]
16:19:02 <bhill2> jochen__
16:19:10 <mkwst> ... We had decided at some point to not control the `Origin` header.
16:19:21 <mkwst> ... I don't know if that means that we have to apply that decision to `ancestorOrigins` as well.
16:19:27 <mkwst> dveditz: I tend to agree with bz.
16:19:45 <mkwst> ... It's not like we're adding ever-increasing things just to RP, we're adding ever-increasing things to the web.
16:20:04 <mkwst> ... Leakage increases over time as we add new features and apply old features to new circumstances.
16:20:24 <mkwst> ... I agree that RP gets complex and hard(er) to use, and maybe we shouldn't do that.
16:20:44 <mkwst> ... But things get more complex, and the feature might need to get more complex to follow along with the way the world is going.
16:20:45 <freddyb> freddyb has left #webappsec
16:21:10 <mkwst> bhill2: I'm sympathetic to the question of `Origin` for things like form posts, as I don't want to lose that data.
16:21:31 <mkwst> ... Direct indication of intent from site to post data, etc.
16:21:34 <mkwst> ... HKPK and CSP are also set explicitly by the site.
16:21:41 <yuki> yuki has joined #webappsec
16:21:46 <mkwst> ... Seems like the intent to send the information to a reporting endpoint exists.
16:22:44 <mkwst> mkwst: HTTPS -> HTTP. Might not matter here, since we can't embed HTTP in HTTPS due to MIX.
16:22:51 <mkwst> ... Might be other RP directives that do weird things.
16:23:02 <mkwst> dveditz: Right. Don't want to send referrer information from HTTPS over plaintext.
16:23:48 <mkwst> bhill2: According to current PR: blocked via `no-referrer`, HTTPS ->HTTP, `same-origin`, opaque origin (same as status quo).
16:24:08 <mkwst> ... `blob:`, `filesystem:` might now report an origin where they previously didn't.
16:24:14 <mkwst> ... `same-origin` is the interesting case.
16:24:47 <mkwst> ... also discussion in HTML over pairwise comparison between item and every ancestor, or a complete barrier if any ancestor blocks.
16:24:57 <mkwst> ... bz in favor of the latter, bhill2 in favor of the former.
16:25:10 <mkwst> .. Is this the right place?
16:25:22 <bhill2> a) belongs in referrer policy
16:25:28 <bhill2> b) not in referrer policy
16:25:34 <bhill2> c) do it, but elsewhere
16:25:43 <freddyb> freddyb has joined #webappsec
16:26:27 <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
16:26:43 <mkwst> ... [Discussion of the PR, and where things are currently defined for `ancestorOrigins` (HTML)]
16:26:44 <freddyb> present+ freddyb
16:26:48 <estark> (that is, A.)
16:27:05 <bhill2> hat=individual (a)
16:27:12 <francois> Also A for me.
16:27:24 <dveditz> c) (part of ancestorOrigins
16:28:01 <mkwst> bhill2: estark, do you care if this is all in RP, an algorithm in RP, or all in HTML?
16:28:06 <dveditz> though a) is fine too
16:28:13 <mkwst> estark: I think we should say what it's intended for in RP.
16:28:33 <mkwst> bhill2: I hear "Keep the algorithm as simple as possible, but let developers know where/why it's used."
16:28:36 <mkwst> estark: SGTM.
16:29:05 <bhill2> (a) pairwise comparison of context and location to get policy
16:29:19 <bhill2> (b) ratchet behavior, once you get a null, all ancestors are null
16:29:19 <mkwst> bhill2: I see votes for the current split, and a vote for "do it in HTML", which can also live with the current split.
16:29:28 <bhill2> (b) stop evaluation once null encountered
16:29:37 <mkwst> ... What about the ratchet/pairwise comparison?
16:31:26 <mkwst> ... [Discussion of use-cases for ratcheting that I didn't really catch.]
16:33:11 <bhill2> mkwst: would want to talk to people at Google using this for anti-fraud before making a change like this
16:33:23 <bhill2> ... pairwise is closet to status quo and so easiest change to make
16:33:25 <bhill2> +1
16:33:36 <estark> +1
16:33:57 <mkwst> bhill2: Right. That's the smallest change, and gives an individual resource control over its privacy, but doesn't impose its decision on others.
16:34:14 <mkwst> ... Ok. I'll talk with bz some more, and pull more folks in if necessary/helpful.
16:34:15 <dveditz> don't feel strongly either way. Don't see a particular privacy problem with (a)
16:34:19 <bhill2> TOPIC: CSP Reports: Script-Sample
16:34:25 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0016.html
16:34:55 <bhill2> mkwst: Firefox has script-sample property send back with violation reports
16:35:09 <bhill2> ... not clear if it takes subsection or just beginning of script, dumps 40 chars into violation report
16:35:26 <bhill2> ... this has lots of value for developers figuring out what caused violations
16:35:45 <bhill2> ... especially extensions, lets you tell if it is really your script or someone else's script
16:36:13 <bhill2> ... reluctant to do this in Chrome because we intentionally censor cross origin script errors unless they opt in in CORS to prevent info leakage
16:36:32 <bhill2> ... contents of inline scripts is another: have vague intuition that they will contain more personalized information than externalized scripts
16:36:43 <bhill2> ... a little bit worried about putting that kind of information into violation reports
16:37:02 <bhill2> ... will have very different data lifetimes and retention policies than application data
16:37:12 <bhill2> ... artur has done a very good job arguing the contra-position
16:37:31 <bhill2> ... which is: you have to trust your reporting input, may contain tokens, etc.
16:38:45 <bhill2> dveditz: don't we strip URL params?
16:39:02 <bhill2> mkwst: cross origin and on redirects
16:39:37 <bhill2> mkwst: second point of artur is that scripts don't empirically contain sensitive data in first 40 chars
16:39:55 <bhill2> ... does mozilla have data about what is being sent in script samples, and what 40 char decision was based on?
16:40:17 <bhill2> dveditz: I don't think any of us on call has looked at that data, but we have it for some of our sites
16:40:32 <bhill2> ... probably not sites that use inline scripts, think 40 was a guess by someone not here anymore
16:41:35 <bhill2> mkwst: for artur's use case, figuring out whether violations are noise or not is valuable
16:41:53 <bhill2> q+
16:42:07 <bhill2> q-
16:42:13 <bhill2> q+ is this only for inline scripts?
16:42:28 <mkwst> ack bhill2
16:43:03 <bhill2> mkwst: ff dumps external, blocks internal, reports on inline handlers but not content
16:43:13 <bhill2> ... artur thinks inline is most useful
16:43:18 <bhill2> ... but current moz impl is not useful
16:44:19 <bhill2> I am sympathetic to "you trust your report endpoint" argument for inline + event handlers, scared by it for external scripts
16:44:34 <bhill2> e.g. stuff like guarded JSONP,   for(;;);{secret=1}
16:45:08 <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?
16:45:29 <bhill2> mkwst: I have not looked at FF impl in a few months, may have changed
16:45:46 <bhill2> freddyb: we still are (sending)
16:46:04 <bhill2> dveditz: it surprises me we even have the sample if we block the load
16:46:14 <bhill2> mkwst: script can load but does something it is not supposed to do
16:46:25 <ckerschb__> ckerschb__: was me :-)
16:46:39 <bhill2> s/freddyb/ckerschb__/
16:47:35 <bhill2> dveditz: sounds like everyone's behavior needs to change but it is useful for cases artur describes
16:47:43 <bhill2> ... maybe think about 30 characters...
16:47:54 <bhill2> +1 but only for inline / event handlers, not for external scripts
16:49:14 <bhill2> jwilander: don't understand the privacy implication
16:49:23 <bhill2> dveditz: you might be using a 3rd party reporting service
16:49:37 <bhill2> jwilander: OK, but artur's argument is that you have to already trust them
16:49:56 <bhill2> dveditz: I agree with mike, I'm surprised that there isn't PII in first 40 character
16:50:10 <bhill2> jwilander: we could restrict to same origin endpoints
16:50:28 <bhill2> dveditz: we could, but I suspect people would find that less useful
16:50:37 <bhill2> ... different kind of load than website, frequently offloaded
16:50:57 <bhill2> ... and mike is adding a different common reporting mechanism that will encourage a common place separate from website
16:51:14 <bhill2> mkwst: same eTLD+1 would be more workable than same-origin, Google has central reporting point
16:52:45 <bhill2> ... concerned that retention policies are different, e.g. if you promise to delete data after a user deletes their account
16:52:55 <bhill2> ... what if user data has leaked into a CSP report somewhere else?
16:53:02 <bhill2> +1 to that concern
16:53:41 <bhill2> mkwst: one idea is to make it opt-in
16:54:20 <dveditz> report-uri https://reporting.com 'script-sample'; ?
16:54:23 <bhill2> ... an interesting direction to explore
16:55:03 <bhill2> TOPIC: XSS-Protection
16:55:18 <bhill2> mkwst: consensus on list and googlers not me is to remove binding between strict-dynamic and existing xss auditor
16:55:24 <bhill2> ... means we need a new name for header
16:55:39 <bhill2> ... who has good idea for this in a new namespace?
16:56:13 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Oct/0002.html
16:56:18 <bhill2> TOPIC: Localhost as a Secure Context
16:56:24 <bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Sep/0120.html
16:56:32 <bhill2> idea is to make localhost localhost again
16:57:06 <bhill2> mkwst: lots of helpful people are making helpful comments in IETF land
16:57:25 <bhill2> ... could add to Secure Contexts that user agents MAY consider localhost secure contexts if they also implement restrictions in draft XYZ
16:57:31 <bhill2> ... I'll add that if people are happy with it
16:58:00 <bhill2> 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
16:58:51 <bhill2> mkwst: need more telemetry, but would fit in well with other restrictions
16:58:54 <dveditz> q+
16:59:25 <bhill2> mkwst: danger is in encouraging people to install sketchy certificates on localhost just to avoid this restriction
16:59:40 <bhill2> ...  current metrics might tell us how much risk this is
16:59:49 <bhill2> ack dveditz
17:00:00 <bhill2> dveditz: what is status of proposal to CORS check localhost?
17:00:19 <bhill2> mkwst: moved to WICG
17:01:07 <bhill2> ... it is a complicated problem, shipping a simple prototype is basically worthless, needs more work
17:01:22 <bhill2> ... but still want to do it, feedback helpful
17:01:31 <bhill2> TOPIC: SRI Addressable Caching Doc
17:01:31 <bhill2> https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html
17:01:53 <dveditz> thanks to wendy for getting us an emergency call code
17:02:29 <bhill2> zakim, list attendees
17:02:29 <Zakim> As of this point the attendees have been bhill2, ckerschb__, mkwst, teddink, freddyb, estark, francois, dveditz, tanvi
17:02:39 <bhill2> rrsagent, make minutes
17:02:39 <RRSAgent> I have made the request to generate http://www.w3.org/2016/10/19-webappsec-minutes.html bhill2
17:02:43 <bhill2> rrsagent, set logs world
17:05:39 <bhill2> bhill2 has joined #webappsec
18:57:28 <tanvi> tanvi has joined #webappsec
19:36:35 <Zakim> Zakim has left #webappsec
20:40:56 <tanvi> tanvi has left #webappsec
21:17:48 <timbl> timbl has joined #webappsec
21:38:42 <wseltzer> i/Then let's come to consensus/scribenick: mkwst
21:39:04 <wseltzer> i/Firefox has script-sample/scribenick: bhill2
21:39:09 <wseltzer> rrsagent, make minutes
21:39:09 <RRSAgent> I have made the request to generate http://www.w3.org/2016/10/19-webappsec-minutes.html wseltzer
21:40:15 <wseltzer> i/bhill2: Any additional items?/scribenick: mkwst
21:40:30 <wseltzer> rrsagent, make minutes
21:40:30 <RRSAgent> I have made the request to generate http://www.w3.org/2016/10/19-webappsec-minutes.html wseltzer
22:08:33 <timbl> timbl has joined #webappsec
22:38:43 <timbl> timbl has joined #webappsec
23:48:14 <bhill2> bhill2 has joined #webappsec
23:48:51 <bhill2> bhill2 has joined #webappsec