Web Application Security Working Group Teleconference

12 Feb 2014


See also: IRC log


mkwst, Wendy, BHill, richt, dveditz, terri, +1.781.369.aaaa, gopal, ekr, glenn, fjh, dom, Rich_Tibbett
bhill2, ekr


<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

Minutes approval: http://www.w3.org/2014/01/14-webappsec-minutes.html

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

CSP Formal Objection


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

DAP WG, re: CORS and whitelisting, exposure of local network IP address

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


<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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-02-12 17:05:16 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/nit/not/
Succeeded: s/wseltzer:/terri:/
Succeeded: s/provide meta/to provide the content that would be in meta/
FAILED: s/^ec$//
Succeeded: s/f CORS/DAP WG, re: CORS/
Succeeded: s/fjh: CORS/mkwst: CORS/
Succeeded: s/mkwst:/fjh:/
Succeeded: s/unmute me//
Found ScribeNick: ekr
Inferring Scribes: ekr
Default Present: mkwst, Wendy, BHill, richt, dveditz, terri, +1.781.369.aaaa, gopal, ekr, glenn, fjh, dom
Present: mkwst Wendy BHill richt dveditz terri +1.781.369.aaaa gopal ekr glenn fjh dom Rich_Tibbett
Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0029.html
Found Date: 12 Feb 2014
Guessing minutes URL: http://www.w3.org/2014/02/12-webappsec-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]