<trackbot> Date: 27 October 2014

Introductions

<timeless> wseltzer: Wendy Seltzer, W3 Team Contact

<timeless> renoirb: Renoir, W3C Team member, working on WebPlatform.org project

<timeless> bhill2: Brad Hill, Chair, Facebook

<wseltzer> [thanks to our awesome scribe, timeless!]

<timeless> Josh_Soref: Josh Soref, BlackBerry, Scribe, Obscerver

<timeless> ckerschb: Christoph Kerschbaumer, Mozilla

<timeless> Kevin_Hill: Kevin Hill, Microsoft

<timeless> terri: Terri Oda, Intel

<timeless> keiji_takeda: Keiji Takeda, W3C KEIO, Japan

Wei Xiaohai, Tencent, China

<timeless> colin: Colin, Whorlow, CESG (Observer)

<renoirb> I am an observer too

<timeless> jing_wang: Jing Wang, Qi, Observer

<timeless> fjh: Frederick Hirsch, Nokia

rigo: Rigo Wenning, W3C Staff, Observer

<timeless> wseltzer: thanks Josh_Soref for scribing

https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit

<timeless> mkwst___: Mike West, Google

<timeless> tanvi: I'm on my way, I'll be late

<timeless> tanvi: Tanvi Vyas, Mozilla

<timeless> dstefan: Deian Stefan, Stanford, Observer

Agenda

<timeless> bhill2: I've put up the Agenda on Google Docs

<timeless> ... we can do some agenda bashing now

<timeless> ... I've also sent out a Survey Monkey survey

<bhill2> WebAppSec 2014 Rechartering Survey

<timeless> ... there are more than 7 people in the room now

<timeless> ... so, I ask people to fill out the survey

<timeless> ... we only have so much bandwidth, so we need to pick which items to focus on

<timeless> ... after people have time to fill out the survey

<timeless> ... I'll prune things from the plan

<timeless> ... of the topics /NOT/ on the survey, we'll have introductions

<timeless> ... later this afternoon, we'll have David Ross, from Google dial in

<timeless> ... to talk about Entry-Point-Regulation

<timeless> ... at 15:30 local-time

<timeless> ... if we can get things together, hopefully he can be a full member at that point

<timeless> ... today, we'll mostly do CSP in the morning session

<timeless> ... and possibly Referer-Policy and Mixed-Content

<timeless> ... immediately after lunch, we're going to host a 1hr meeting of the Web-Security Interest Group

<timeless> ... the IG is a cross section group

<timeless> ... it should be interesting, please come and attend that

<timeless> ... we'll resume at 15:15 to start on rechartering topics

<timeless> ... to talk about David Ross's idea, and first set of pruning

<timeless> ... tomorrow morning, we'll continue with Rechartering topics

<timeless> ... Frederik Braun and Joel Weinberger to talk about Subresource Integrity (SRI)

<timeless> ... after lunch, we have open time

<timeless> ... there's also an AC meeting then, I'll have to step out

<timeless> ... dveditz can run the meeting then

<timeless> ... we'll be one of the first groups to run into conflicts involving dependencies to WHATWG specs

<timeless> ... this meeting is the third anniversary of the WebAppSec WG

<timeless> ... we've only gotten one thing to REC

<timeless> ... i'd like us to get more things to REC this year

<timeless> ... we have tests holding us up

<timeless> ... so i'd like to see work on Web CSP

<timeless> ... i'd like to see people working with these technologies

<timeless> ... 18-19% of pages based on Chrome metrics have CSP policies

<timeless> ... but based on web sites that have CSP it's only 0.1%

<timeless> ... i think we could do more to support the rest of the community getting the deployment percentage up

<timeless> ... AoB?

<timeless> ... I have a request in my inbox to have an AdHoc session at TPAC on Mandatory Secure Origins for new/powerful web platform features

<timeless> ... an ML thread started by Chris Palmer at google

<mkwst___> Prefer Secure Origins For Powerful New Features

<timeless> ... it's a question about whether W3C should lead the charge to an ALL https:// web

<timeless> ... depending on how we progress through the agenda, maybe we can do that tomorrow as well

<timeless> fjh: you might want to include Usability and

<timeless> ... re: TBL's message (to TAG?)

<timeless> ... it would be good to balance security with usability

<mkwst___> http://lists.w3.org/Archives/Public/www-tag/2014Sep/0040.html "XMLHTTPRequest restrictions by origin" is probably Tim's post that's being referred to.

Usability and Consent

<timeless> fjh: there's a workshop in Berlin

<timeless> ... on Security/Usability

<timeless> ... this has also come up in DAP and everywhere

<timeless> ... we're looking to get papers+thoughts on how to improve the interaction with the user

<rigo> W3C Workshop on Privacy and User–Centric Controls

CSP issues

<timeless> i/Tanvi Vias, Mozilla/dveditz: Dan Veditz, Co-Chair, Mozilla/

<timeless> bhill2: last week on Monday, I issued a call on the ML to move from LC to CR

<timeless> ... as part of that transition, this is more formal

<timeless> ... not just inside the WG

<timeless> ... we have to document that we've addressed all issues

<timeless> ... in scrubbing the ML, we need to be sure that we've formally addressed things

<timeless> ... a couple of things in the agenda

<timeless> ... a couple in the Tracker, and on Github

<timeless> ... thanks to mkwst___ for starting a thorough scrub of the ML

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0178.html

CSP Issue: Referrer Policy belonged in CSP

<timeless> ... Brian Smith wasn't sure if Referrer Policy belonged in CSP

<timeless> ... whether Referrer Policy reflected XSS

<timeless> ... should CSP strictly reduce privileges of a page

<timeless> ... or if they should be their own directive

<timeless> ... i believe the discussion in the group was

<timeless> ... as part of our charter, we're trying to reduce cognitive load

<timeless> ... and reduce header bloat

<timeless> ... I want to see if we can reach a consensus

<timeless> ... can we get a show of hands (anonymous for minutes)

<timeless> ... should we remove things which lessen restrictions

<timeless> mkwst___: He was more suggesting that they be in their own header

<timeless> dveditz: there would be a different spec for it

<timeless> mkwst___: the CSP2 delegates to Refer

<timeless> ... RRR defers to SSS

<timeless> bhill2: why not use ...

<timeless> dveditz: because it's there

<timeless> ... I understand Brian Smith's objections

<timeless> ... if he's afraid of the feature in general

<timeless> ... but not if it's just where

<timeless> tanvi: what if we .change the default

<timeless> mkwst___: I believe that is what it does

<timeless> tanvi: ok

<timeless> dveditz: we need backwards compat with previous CSP

<timeless> mkwst___: we currently block a couple of CSP directives

<timeless> ... from being set in the Meta Header

<timeless> ... one is Sandbox

<timeless> ... another is Reflected XSS

<timeless> dveditz: another is Frame-Ancestor

<timeless> ... i think there were 4

<timeless> ... there's a slight discrepancy in the spec

<timeless> ... it lists 3 things

<timeless> ... but if you read frame-ancestors, it says...

<timeless> ... we should add frame-ancestors to the list

<timeless> ... for completeness

<timeless> mkwst___: we should do that

<timeless> bhill2: i'll file an issue

<timeless> mkwst___: the other is Report-URI

<timeless> mkwst___: whether the commonality of these three

<timeless> ... justifies splitting out to a separate header

<timeless> ... i fall to the "one-header" side

<timeless> ... developers say "i'm settings these policies"

<timeless> ... i'm sympathetic to the idea of cohesiveness "all positive, or all negative, all loosen, or all tighten"

<timeless> ... a CSP header that tightens, or loosens,

<timeless> ... I haven't seen any proposals for names that make sense

<bhill2> created new GitHub Issue: https://github.com/w3c/webappsec/issues/67

<timeless> ... in the absence of such proposals, putting everything into a Policy bucket makes sense to me

<timeless> bhill2: +1

<timeless> ... as Chair, we have this specified, we're ready to go to CR

<timeless> ... there's something to be said for being done rather than starting over

<timeless> ... the potential harm in terms of ideological consistency in the spec is small

<timeless> ... I suppose we could just define a header name in the existing Referrer spec

<timeless> ... I think short of that, we should default to leaving it where it is

<timeless> ... i don't see strong objections,

<timeless> ... It sounds like Brian Smith could live with it

<timeless> ... in the absence of strong objections

<timeless> ... I'll take an action to respond to him

<timeless> ... on the list, and close that as an open issue

<bhill2> http://www.w3.org/2011/webappsec/track/issues/62

CSP Issue: is reflected-xss at risk

<timeless> bhill2: I don't think Mozilla has an implementation

<timeless> ... Chromium has

<timeless> ... if Microsoft doesn't intend, then I think we need to take it out

<timeless> Kevin_Hill: We intend to implement

<timeless> ... i'll verify

<timeless> ... there's an actions assigned to David Walp on this

<timeless> mkwst___: WebKit also implements this

<timeless> ... but it isn't really a separate implementation

CSP Issue: report-only: "true|false"

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0218.html

<timeless> bhill2: our conclusion was that if you're interested in this

<timeless> ... you could smuggle it in as part of a GET URI

<timeless> ... I want to see if we're happy with that

<timeless> dveditz: I'm really happy with that

<timeless> bhill2: no objections, we'll consider this resolved

CSP Issue: concept-url-origin

<bhill2> https://url.spec.whatwg.org/#concept-url-origin

<timeless> bhill2: we touched on things like data, uri, source-doc

<timeless> ... after we talked about this

<timeless> ... the folks writing the URL spec decided

<timeless> ... Blob has an origin

<timeless> mkwst___: in chrome, I believe that a Blob will return the origin

<timeless> ... it's potentially problematic

<timeless> ... since it allows sites to bypass

<timeless> dveditz: our position would be

<timeless> ... if we don't require Blobs to be explicitly listed

<timeless> ... then we'd require unsafe-inline

<timeless> ... Blob is potentially the same as script-injected stuff

<timeless> mkwst___: i'd strongly suggest we make developers list Blobs explicitly as a frame source

<timeless> bhill2: if we're happy with the existing spec text

<timeless> ... and we aren't concerned that the new url-origin spec breaks things

<timeless> ... and we'll have to discuss it in context of WebRTC later ...

<timeless> ... then I think we're ok

<bhill2> we have work items queued up for CSP v.next to deal with WebRTC, which will also re-raise how to deal with blobs of various origins and security properties

<bhill2> so we can leave Level 2 as-is for now, and revisit in more depth in the future when this behavior is more defined

CSP Issue: img-src and inline <svg>

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0123.html

<timeless> bhill2: should unsafe-inline be directed for img-src

<timeless> ... annevk discussed on the list that

<timeless> ... * CSP is about Fetching Resources

<timeless> ... * CSP is about Meeting Developer expectations protecting against attacks

<timeless> dveditz: CSP has grown into more than just a set of fetching rules

<timeless> ... which is why we argued for a fairly generic name

<timeless> ... but i don't think we want to change it to a feature-switch list

<timeless> ... to enable/disable html5 features because you happen not to like them

<timeless> ... from Mozilla's perspective, I think, inline-svg is just Page Content

<timeless> ... it shouldn't need to be covered by an on-off

<timeless> bhill2: i'm happy with that

<timeless> ... you could draw a picture using a Table

<timeless> dveditz: the scripts in svg would be controlled by the page's policy on controlling scripts

<timeless> bhill2: i'm sympathetic, and i'm happy to consider the issue closed

<timeless> ... that svg is page content

<timeless> dveditz: if it's loaded as an image, CSP is applied to the fetch before we discover it's an image

<timeless> bhill2: it's a slippery slope, there's no logical place to stop

<timeless> ... anything other than <script>

CSP Issue: prevent 401 attach

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0015.html

<timeless> bhill2: I think we want to explicitly punt for CSP2

<timeless> ... there's some history here

<timeless> ... i think PayPal found this issue and reported it

<timeless> ... browsers fixed it

<timeless> ... and it turned out to be a security-nightmare

<timeless> ... and it was ripped out

<timeless> ... if I include a third party image

<timeless> ... if that image returns 401

<timeless> ... you'll get a browser-security-prompt for the dialog

<timeless> ... and users will think it was coming from the top-level-page

<timeless> ... Chrome blocked the load silently

<timeless> ... but without rate-limiting

<timeless> ... which allowed for attacks on home routers etc.

<timeless> ... because http-basic implementations rarely have rate-limiting

<timeless> ... the question is should we put this on CSP3 and ask resource owners define policies

<timeless> mkwst___: i think i'd agree that we should come up with a policy

<timeless> ... and not require web sites define a policy

<timeless> ... it isn't clear to me if it should be part of mixed-content

<timeless> ... where is Digest/Mixed auth defined?

<timeless> dveditz: HTTP, and handling of prompts is left as an exercise to the UA

<timeless> mkwst___: i'd suggest auto-fail any non-top-level-origin request

<timeless> ... i doubt it's web-safe

<timeless> ... but it's something i'd like to try

<timeless> dveditz: without the page author having to say how to handle it

<timeless> ... --- i think it's appropriate for our WG to discuss

<timeless> ... I don't know if you could have a policy

<timeless> ... is CSP the place to put it

<timeless> ... we should discuss it in our group

<timeless> ... or perhaps w/ the WS IG

<timeless> ... as a security thing, it's well w/in our scope

<timeless> ... but I don't know what

<timeless> ... i'd rather something that just-works

<timeless> ... without authors having to say something

<timeless> ... in which case it probably goes into HTML

<timeless> ... i don't think it goes into Mixed

<timeless> ... because the issue is wether or not it's Mixed

<timeless> mkwst___: +1

<timeless> ... it doesn't feel like it's a decision website authors should make

<timeless> ... and I don't think they'd make it well

<timeless> tanvi: I think Chrome's implementation only doesn't do it for Images

<timeless> ... they tried XHR and others

<timeless> ... I don't know we can do this w/o breaking compat

<timeless> bhill2: I think there were cases of Enterprise Single Signon using tracking pixels

<timeless> ... for this part of the agenda, that it's clear it isn't CSP2, and probably not CSP.next

<timeless> ... but it's clear it should have a home

<timeless> ... I'll create an issue, and respond to Hatter Jiang

<timeless> ... objections?

<timeless> [ None ]

CSP Issue: may we have script-ancestors to protect JSONP call

<timeless> may we have script-ancestors to protect JSONP call

<timeless> bhill2: we'll respond that this is under consideration for v.Next

CSP Issues: Tracker

<bhill2> https://www.w3.org/2011/webappsec/track/issues/open

<timeless> s|i/http/Topic: CSP Issues: Tracker||

CSP Issues: ISSUE-30 How to address dynamic application of CSP post page load ...

<bhill2> https://www.w3.org/2011/webappsec/track/issues/30

<timeless> bhill2: I think this is already addressed in the spec

<timeless> dveditz: is that for static or dynamic?

<timeless> ... we've resolved the meta

<timeless> ... but for scriptable, we've punted to a future version

<timeless> mkwst___: scriptable is covered by ISSUE-34

<timeless> dveditz: ok, ISSUE-30 is done

CSP Issues: ISSUE-31

<timeless> bhill2: are we ok on this?

<wseltzer> issue-31?

<trackbot> issue-31 -- What specification's definition of URL/URI are we using for path parsing in CSP 1.1? -- open

<trackbot> http://www.w3.org/2011/webappsec/track/issues/31

<timeless> mkwst___: we're as ok as HTML is

<timeless> bhill2: closed...

CSP Issues: ISSUE-37

<timeless> issue-33?

<trackbot> issue-33 -- Need to address blob, data, filesystem URL types with greater specificity in CSP 1.1 spec -- closed

<trackbot> http://www.w3.org/2011/webappsec/track/issues/33

<bhill2> https://www.w3.org/2011/webappsec/track/issues/37

<timeless> mkwst___: I think we addressed this

<bhill2> Move past this one for now, need more context.

CSP Issues: ISSUE-54 policy-uri vs. policy-url

<timeless> dveditz: we dropped policy-...

<timeless> bhill2: annevk was bothered by uri v. url

<timeless> dveditz: we have it in report-

<timeless> bhill2: this was raised after CSP 1.0

CSP Issues: ISSUE-37 How to apply plugin-types in CSP 1.1 to iframes

<timeless> mkwst___: the spec covers this

<timeless> bhill2: can you update the tracker and close it?

<timeless> mkwst___: yes

CSP Issues: ISSUE-68 How to manage 401 phishing prompts by subresources

<timeless> bhill2: we just talked about that

<timeless> ... i'll change the status to open

CSP Issues: ISSUE-63: Disposition of ch-csp client hint

<timeless> mkwst___: we change ch-csp to csp to respond to mnot's ...

<bhill2> https://www.w3.org/2011/webappsec/track/issues/pendingreview

CSP Issues: ISSUE-66 No-external-navigation as potential csp3 feature

<bhill2> https://www.w3.org/2011/webappsec/track/issues/56

<timeless> bhill2: v.Next

CSP Issues: ISSUE-56 Should we restrict subsequent navigation within child-src?

<timeless> bhill2: csp-client-hint and unsafe-client-redirect-tokens address this issue

<timeless> ... -> closed

CSP Issues: ISSUE-58: Late binding of CSP policies

<timeless> bhill2: we have text for this

<timeless> ... -> closed

CSP Issues: ISSUE-59: Figure out how to use CSP appropriately with SVG modes

<bhill2> https://www.w3.org/2011/webappsec/track/issues/59

<timeless> issue-59?

<trackbot> issue-59 -- Figure out how to use CSP appropriately with SVG modes -- pending review

<trackbot> http://www.w3.org/2011/webappsec/track/issues/59

<timeless> bhill2: ... -> closed

CSP Open Actions

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open

<bhill2> https://www.w3.org/2011/webappsec/track/actions/174/edit

CSP ACTION-174: Raise frame-ancestors/fetch/neterror on list

<timeless> bhill2: how do we deal with things in CSP that aren't perfect matches

<timeless> ... returning a network error a failure to load because of a frame-ancestors policy

<timeless> ... everywhere else in CSP, it's treated as a parameter to the fetch algorithm

<timeless> ... if my page tries to load an image, and it's blocked by CSP

<timeless> ... it looks like a network error

<timeless> ... for a frame, you load the page first

<timeless> ... do you fire the onerror handler in the parent page

<timeless> bhill2: if it fails, it's because you shouldn't have access to what's inside

<timeless> ... terri wrote some tests at the hackathon

<timeless> ... @ Test The Web Forward in Portland

<timeless> ... Firefox fires and Chrome does not

<timeless> ... mkwst___ are you ok w/ this language?

<timeless> ... difficulties for Blink?

<timeless> mkwst___: as long as a failed load because of CSP is indistinguishable from

<timeless> ... we had problems w/ the XSS auditor in Chrome

<timeless> ... you could use the XSS auditor to block the page based on text in the page

<timeless> ... we did work to make XSS loads (success/failure) transparent to the openers

<timeless> ... I don't know the text in the spec

<timeless> ... i'll take a quick look at it

<timeless> bhill2: i'll reassign the action to mkwst___

<timeless> mkwst___: doesn't load ...

<timeless> ... we sandbox to a unique origin

<mkwst___> step 3.2 of https://w3c.github.io/webappsec/specs/content-security-policy/#frame-ancestors

<timeless> bhill2: you want to make it indistinguisable

<timeless> mkwst___: that was the justification

<timeless> bhill2: the spec says to act as if you have an empty 200 response

<timeless> mkwst___: if you don't sandbox into a unique origin, then it's possible to determine if it loaded successfully or not

<timeless> ... a same-origin page can be introspected

<timeless> dveditz: if it's same-origin and it was successful

<timeless> ... then you can reach in

<timeless> ... you could test by whether it's sandboxed or not

<timeless> mkwst___: if it's cross-origin, you can't reach in

<timeless> ... if it's an empty response for 200,

<timeless> ... within chrome,

<timeless> ... i had to specifically set the origin of the page to make sure it was explicitly inaccessible

<timeless> bhill2: so an about:blank equivalent

<timeless> ... instead of empty content from that origin

<timeless> mkwst___: that was the context that i ended up w/

<timeless> dveditz: if the intent is to prevent the parent page from knowing if it's blocked on not

<timeless> ... then they can know if they can't reach into the page

<timeless> bhill2: this is for cross-origin pages

<timeless> mkwst___: there's not much we can do about same-origin pages

<timeless> mkwst___: this was the easiest way for me to write "the page should be cross origin"

<timeless> ... i don't care if the implementation actually sandboxes, or not

<timeless> ... what's important is that the page be distinct origin to the parent on failure

<timeless> bhill2: sounds ok to me

<timeless> ... how does it sound to other implementers in the room?

<timeless> terri: hard to test for me

<timeless> bhill2: test that onerror doesn't fire

<timeless> mkwst___: use report-uri

<timeless> terri: makes sense

<timeless> bhill2: i don't here proposals for changing that part of the spec

<timeless> ... can we mark this as closed?

<timeless> ... punt to make sure our tests ensure implementations are applying the existing spec test?

<timeless> ... -> closed

<timeless> ckerschb: i guess we can do that

<timeless> dveditz: XFrameOptions...

<timeless> ... but presumably that [IETF] should also not

<timeless> ... their spec isn't that detailed

<timeless> bhill2: yeah...

<timeless> ... probably makes sense to do consistently

<timeless> ... the ietf spec doesn't delve into details

<timeless> dveditz: it might

<bhill2> http://tools.ietf.org/html/rfc7034#section-2.3.2.1

<timeless> ... it was designed to describe what was done, not to be prescriptive

<timeless> Implementations of this vary: some browsers will show a message that

<timeless> allows the user to safely open the target page in a new window,

<timeless> whereas other implementations will simply render an empty frame.

<timeless> dveditz: it describes content

<timeless> ... the window would be not-same-origin

<timeless> bhill2: the new window / empty frame will need to be not-same-origin

<bhill2> https://www.w3.org/2011/webappsec/track/actions/191

CSP ACTION-191: Inconsistency in source hash description

<timeless> bhill2: is this a typo?

<timeless> mkwst___: i haven't looked

<inserted> [ Coffee Break until 10:30 ]

CSP GitHub issues

<scribe> scribenick: npdoty

bhill2: adding an acknowledgements section. doesn't seem too controversial

mkwst___: if you have any suggestions of people to ack, that would be great

bhill2: Neil, on the script/hash

mkwst___: if we add a section, don't want to miss people

issue a call for acknowledgements, something for the chair to do

<bhill2> https://github.com/w3c/webappsec/issues/63

many thanks to our previous scribe, who all agree is great

bhill2: for the current milestone?

mkwst___: sure. non-normative, so can add without a problem

<bhill2> https://github.com/w3c/webappsec/issues/49

bhill2: comment was that ABNF for host-part doesn't allow for ipv6 address
... my response was that this was by design. the origin-based model of security doesn't work very well for ip addresses
... not the intent. CORS doesn't work for ipv6 addresses as well

rigo: looking forward a number of years, expect a switch to IPv6
... should at least say if we don't know what to do, so that researchers can look into it
... note it as a long-term issue

bhill2: an issue for IPv4 as well, even though ABNF can handle it, not a good part of the web security model and origins
... origins typically more associated with names than with IP addresses
... should we change the spec to allow specifying IPv6 addresses in the host portion?

rigo: why prohibit it? might want a high-security application to specify a very specific IP address

The Web Origin Concept, https://www.ietf.org/rfc/rfc6454.txt

<bhill2> https://www.ietf.org/rfc/rfc6454.txt

bhill2: Section 7.1 of rfc6454, not sure if it allows an IP address or not

debate over whether 6454 allows for IP address origins (seems like yes)

mkwst___: if we allow ipv4, we should allow ipv6
... but IP addresses are origins that are difficult to reason about
... don't feel strongly
... in Chrome, consider an IP address to be an origin, supports localStorage, etc.

bhill2: no ABNF for host in 6454
... could reference URI, rather than defining it in CSP

@@: but we specify an algorithm for how to parse it

scribe: actually, just refers to parts based on URI

<bhill2> http://www.w3.org/TR/CSP2/#host-part

mkwst___: we'd have to change host-part to include both colons and brackets (only at beginning and end)
... making sure it's well-formed would be a little more complicated
... but not a lot of work
... currently we allow IPv4 addresses, but don't verify their validity

bhill2: sense I'm getting is that we should probably do this

dveditz: split into origin name / IP address

mkwst___: not a very significant change

bhill2: github issue assigned

dveditz: can you note the security implications of using IP addresses?

mkwst___: result of a bad input here is that something doesn't load, a safe result

bhill2: end of our issues across mailing list, tracker and github for CSP2
... any objections to considering this a satisfactory disposition of Last Call comments by the Working Group?

<scribe> ... pending action items today

UNKNOWN_SPEAKER: any objections to requesting transition of CSP2 to CR?

dveditz: clarification about srcdoc and iframe
... if framesrc is none, should src doc be loadable or not? could see different outcomes

bhill2: good question.

mkwst___: good question.
... not sure we have a test for it.

[scribe not quite capturing these details]

dveditz: might surprise someone who thinks they're turning off all iframes. but if it's an iframe from the same origin, then there's no change in privileges anyway

bhill2: give a name to the iframe?
... can you open an issue with the necessary clarifications?

dveditz: yes.

bhill2: that's it for CSP level 2
... once we wrap up these issues, hear no objections to advance to CR

Content Security Policy v 1.0 to Note

bhill2: take CSP 1.0 to WG Note status, once CSP 2 is at CR
... currently we have two CSP documents on Recommendation-track
... main issue for advancement will be development of a test suite
... very limited overlap. several implementations will be working on CSP 2 compatibility
... don't see a strong case for continuing effort on CSP 1
... call for retiring CSP 1, moving it to Note status
... received assent on the mailing list. want to confirm here

dveditz: concern is what people use specs for.
... would take longer to get CSP 2 fully implemented/tested
... authors unlikely to care about the difference between Note and Rec

@@@: working on WebPlatform docs. would be glad to help document the differences

scribe: as a developer recommendation

bhill2: which do we want to encourage developers to use?

@@@: as a developer, I'm not sure which one I should be using, especially regarding frame- options

mkwst___: CSP2 options are behind a compatibility flag for Chrome beta/stable

bhill2: a few things are different, like handling of blobs. breaking changes for things that were underspecified and so implemented in non-interoperable ways
... clearly want people to abandon the old use cases in those
... any objections to this call for consensus?

resolved: as of advancement of CSP2 to CR, WG will request that CSP1 move to WG Note

next topics

bhill2: lunch break. didn't get to the other documents topics

can talk about MIX etc. from 13:00 to 14:00

updating agenda

reconvene at 13:00, for an hour, before Web Security Interest Group

after that, 15:15, rechartering discussions

i/Topic: Introductions/scribenick: timeless/

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/W3 Web Platform Docs/W3C Team member, working on WebPlatform.org project/
Succeeded: s/Kerschbom/Kerschbaumer/
Succeeded: s/wei_james/scribe/
Succeeded: s/wei xiaohai/Wei Xiaohai, Tencent, China/
Succeeded: s/rigo/scribe/
Succeeded: s/rigo/scribe/
Succeeded: s/scribe: //
Succeeded: s/ Rigo Wenning/rigo: Rigo Wenning/
Succeeded: s/Teleconference/F2F/
WARNING: Bad s/// command: s/Wast/West/ :)
Succeeded: s|s/Wast/West/ :)||
Succeeded: s/Wast/West/
Succeeded: s/Vias/Vyas/
Succeeded: s|https://www.surveymonkey.com/s/8VPQT7J|-> https://www.surveymonkey.com/s/8VPQT7J WebAppSec 2014 Rechartering Survey|
Succeeded: s/Frederick XXX/Frederik Braun/
Succeeded: s/Joel Brown/Joel Weinberger/
Succeeded: s/YYY/Subresource Integrity (SRI)/
Succeeded: s|http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features <-- "Prefer Secure Origins For Powerful New Features"|-> http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features "Prefer Secure Origins For Powerful New Features"|
Succeeded: s|http://www.w3.org/2014/privacyws/|-> http://www.w3.org/2014/privacyws/ W3C Workshop on Privacy and User–Centric Controls|
FAILED: i/Tanvi Vias, Mozilla/dveditz: Dan Veditz, Co-Chair, Mozilla
Succeeded: s/lesson/lessen/
Succeeded: s/QQQ/Refer/
Succeeded: s/.../change the default/
Succeeded: i/Referrer Policy belonged in CSP/Topic: CSP Issue: Referrer Policy belonged in CSP
Succeeded: s/Topic: CSP Issue: EEE//
Succeeded: i/http/Topic: CSP Issue: report-only: "true|false"
Succeeded: s/EEE/concept-url-origin/
Succeeded: s/we're not worried about WebRTC/we'll have to discuss it in context of WebRTC later/
Succeeded: s/EEF/img-src and inline <svg>/
Succeeded: i/http/Topic: CSP Issue:  prevent 401 attach
Succeeded: s/EEG/may we have script-ancestors to protect JSONP call/
Succeeded: i/http/Topic: CSP Issues: Tracker
FAILED: s|i/http/Topic: CSP Issues: Tracker||
Succeeded: i/http/Topic: CSP Issues: Tracker
Succeeded: i/http/Topic: CSP Issues: ISSUE-30 How to address dynamic application of CSP post page load ...
Succeeded: s/ISSUE-33/ISSUE-37/
Succeeded: i|http|Topic: CSP Open Actions
Succeeded: s/XSF/XSS/
Succeeded: i/CSP/[ Coffee Break until 10:30 ]
Succeeded: s/braces/brackets/
Succeeded: s/@@/dveditz/
FAILED: i/Topic: Introductions/scribenick: timeless
Found ScribeNick: npdoty
Inferring Scribes: npdoty
Present: Brad_Hill Christoph_Kerschbaumer Kevin_Hill Terri_Oda Frederick_Hirsch Keiji_Takeda Renoir_Boulanger Wendy_Seltzer Josh_Soref JingWang_Qi Colin_Whorlow Rigo_Wenning Deian_Stefan Wei_Xiaohai Mike_West Tanvi_Vyas Dan_Veditz Christine_Runnegar Nick_Doty Peleus_Uhley
Agenda: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit
Found Date: 27 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/27-webappsec-minutes.html
People with action items: