See also: IRC log
<trackbot> Date: 27 October 2014
<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
<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
<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.
<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
<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
<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
<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
<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
<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
<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>
<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 ]
<timeless> may we have script-ancestors to protect JSONP call
<timeless> bhill2: we'll respond that this is under consideration for v.Next
<bhill2> https://www.w3.org/2011/webappsec/track/issues/open
<timeless> s|i/http/Topic: CSP Issues: Tracker||
<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
<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...
<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.
<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
<timeless> mkwst___: the spec covers this
<timeless> bhill2: can you update the tracker and close it?
<timeless> mkwst___: yes
<timeless> bhill2: we just talked about that
<timeless> ... i'll change the status to open
<timeless> mkwst___: we change ch-csp to csp to respond to mnot's ...
<bhill2> https://www.w3.org/2011/webappsec/track/issues/pendingreview
<bhill2> https://www.w3.org/2011/webappsec/track/issues/56
<timeless> bhill2: v.Next
<timeless> bhill2: csp-client-hint and unsafe-client-redirect-tokens address this issue
<timeless> ... -> closed
<timeless> bhill2: we have text for this
<timeless> ... -> closed
<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
<bhill2> https://www.w3.org/2011/webappsec/track/actions/open
<bhill2> https://www.w3.org/2011/webappsec/track/actions/174/edit
<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
<timeless> bhill2: is this a typo?
<timeless> mkwst___: i haven't looked
<inserted> [ Coffee Break until 10:30 ]
<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
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
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:[End of scribe.perl diagnostic output]