See also: IRC log
<trackbot> Date: 12 February 2014
<mkwst> huzzah.
<mkwst> yeah, i can scribe. i think it's my turn anyway.
<gmaone> Is anybody trying to call Zakim's VOIP and failing like me?
<hillbrad> Meeting: WebAppSec WG Teleconference 12-Feb-2014
<hillbrad> Chairs; bhill2, ekr
<mkwst> wseltzer: the bot wasn't up when i dialed in; can i somehow ensure that i'm associated with whatever number i'm dialed in on?
<mkwst> ah, sweet. :)
<terri> sorry, apparently I had the call muted. fixed
scribenick, ekr
<scribe> scribenick: ekr
No objections, minutes approved
bhill2: going to start a CfC for the FPWD of subresource integrity.
mkwst: I will have a bunch of feedback on subresource integrity
bhill2: New CSP 1.1. WD published yesterday morning
http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0165.html
bhill2: as chair, I think we have rough consensus. don't need need to reopen the issue.
??? : as I understand it there are two objections
<mkwst> ekr: s/???/dveditz/
bhill2: 1. Language -- we left it to implementors. 2. Objection to removal of language, but from Bjoern who is not a wg member.
… can 't have two people have a tug of war preventing it from going forward
dveditz: objections are opposite, right?
bhill2: concerned here with issue glenn raised and that bjoern has responded to re: user-supplied modifications to page via extensions, bookmarks, etc.
<glenn> in this case, it is better to not say anything in spec
dveditz: we have seen objections that are useful to users that may unwisely make changes to every page. might be reasonable to require an extension to explicitly override CSP.
… don't know how we would do that technically
… seems like a UA decision
mkwst: agreed. putting limitations on extensions/add-ons might be reasonable but it's not a spec issue
bhill2: a spec must have two interoperating implementations of each feature
… a normative requirement to turn reporting off would need to have implementations in both specs
… nothing stopping browsers from doing that, but it need not be in the spec
dveditz: what if firefox or torbrowser decides to have opt-in reporting, is it still conformant.
bhill2: yes
... has not seen a coherent threat model for why reporting
makes things worse
<wseltzer> ->
<wseltzer> http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html
<hillbrad> noted for minutes: no objections to consensus on current language in the tip of the editor's draft, that is, no normative recommendations to user agent implelmenters regarding interaction of CSP and extensions or user-script
<hillbrad> consensus previously established still stands
<wseltzer> RESOLVED: previously-established consensus stands
<hillbrad> mkwst: child-src and popups are 1.2 features
I am back
<hillbrad> … referrer expressiveness is in current editor's draft
mkwst: processing of meta elements still needs discussion
<hillbrad> … meta element needs discussing, are use cases current spec would disallow and questions about reasonableness
<hillbrad> … beacon is not 1.1
hillbrad: I can take over
mkwst: two things I think are interesting, meta element and redirect
wseltzer(?): meta element… was that based on a request.
mkwst: some cases where you can't control HTTP headers
<fjh> ec
terri: maybe we should consider other options. probably wouldn't be too hard for github or such to allow people to to provide the content that would be in meta
mkwst: I don't see a threat here.
… I don't understand what the problem is
dveditz: what are you not concerned about? header? script element after the page is loaded
<fjh> s/^ec$//
mkwst: given that we restrict reporting, etc. by policy, so how is this different than if I could inject a non-CSP meta tag
terri: I'm not convinced. let me see if we can figure out how to attack this here.
dveditz: can't I also use this to block other things on the page
mkwst: wouldn't this already be worse with non-CSP mechanisms if you could already inject meta
dveditz: having scripts mess with meta tags is not good. an API would be better
… implementation concerns here as well
mkwst: let's take this to the list
bhill2: last major 1.1. Mike, you mentioned referer?
mkwst: my impression is that it is fine
bhiill2: can you get dan and other mozillans to express any concerns with meta asap.
… start CfC for last call on next telecon
information in URLs,
Editors draft: https://dvcs.w3.org/hg/dap/raw-file/default/discovery-api/Overview.html
Issues: http://www.w3.org/2009/dap/track/products/31
… services currently advertising in network via bonjour, etc.
… browser gets handle to devices in network
<richt> NSD discussions on implementer lists: http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0029.html
… some reviews have already happend
… have added CORS support to API.
… also get user opt-in
… user opt-in is extremely important
… don't want to expose routers, etc.
… but we want to expose TVs, etc.
… this why CORS is relevant here.
… here to talk about some of the security concerns
… wanted to get this group's feedback
mkwst: CORS opt-in is a quite reasonable response. why is it should but not must.
sorry, I assumed it was cause you were in queue. Who was that?
<hillbrad> fjh: this is mike west speaking
sorry, I am terrible at voices.
richt: we have implementations outside the browser.
mkwst: these should be a requirement
<dom> [the editors draft has " A user agent SHOULD only allow web pages to connect with Local-networked Services that have passed a preliminary CORS check indicating they support Cross-Origin Resource Sharing [CORS]"]
<fjh> https://dvcs.w3.org/hg/dap/raw-file/default/discovery-api/Overview.html
<fjh> https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html
richt: browser can blacklist device types
… and users could whitelist devices
mkwst: might be good to put that in this section
richt: you request a service type, you then broadcast a request and the device responds with a CORS header
[…] long colloquy about the strength of the mechanism for verifying CORS consent
to summarize, this is just a mechanism for discovery.
but any actual requests go through their own CORS checks
richt: you get a list of endpoint URLs. These will be local IP addresses.
… you don't want to expose local IPs to the Web.
<dom> [more importantly, we want to filter what requests can be made on these end points]
ekr: webrtc already exposes the local IP address ranges
mkwst: chrome already obfuscates this
… you could have a different scheme
… the communication can contain the local IP addresses
<dom> [one of the issue is that you want to follow links exposed by the local network services, e.g. link to an image or a video]
btw, you don't need a different scheme
just a different domain
richt: I am worried about whether this stuff is going to leak anyway
mkwst: this is intermediated by the user
richt: user has to consent to discover and then the user can filter the list back
… at the end the web page gets the filtered list
… main concerns are local IP and CORS
fjh: I might raise an issue about
whitelisting along with cors.
... what actions do you have in mind
mkwst: I think this is OK now that we have discussed
dom: what are the next steps? how can the webappsec guys help?
<hillbrad> sorry folks, I gotta go - wseltzer can you close the channel, prep logs, etc, please?
mkwst: I think you have been working with security team too
<wseltzer> hillbrad, sure
sorry, me too...
<hillbrad> thanks all
bye
<fjh> much thanks!
<fjh> feedback on the mail list would be very welcome or additional ideas
<wseltzer> wseltzer: Thanks to Rich and Frederick from DAP; we'll figure out where to continue the discussion.
<wseltzer> [adjourned]
<wseltzer> trackbot, end teleconf