WebAppSec WG Teleconference 8-Oct-2013

<neilm> Zakim: aadd is neilm

<mkwst_> I think I was the first one in, but I wasn't in IRC yet.

<tanvi> ekr - are you in a roomin MV?

tanvi: no, I am in my office in Palo Alto

<mkwst> bhill2: already took care of it. :)

OK, then.

<bhill2> scribenick: ekr

scribe is ekr

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0046.html

Minutes from previous meeting

<bhill2> http://www.w3.org/2013/09/10-webappsec-minutes.html

unanimous consent to approve minutes

Tracker actions

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

bhill2: issues assigned to Adam

<bhill2> trackbot close ACTION-150

<trackbot> Closed ACTION-150.

https://www.w3.org/2011/webappsec/track/actions/146

dveditz: seems to be consensus on this

bhill2: also an issue for blob URIs

dveditz: cannot have a header-based policy if the info comes from non-HTTP

… we don't have a syntax for a meta policy

… workers don't have access to the DOM

… no reason we can't make the API accessible to workers global object

bhill2: this brings us to the next issue. I had proposed on the list that filesystem/blob/etc. would be matched only by self.

https://www.w3.org/2011/webappsec/track/actions/149

dveditz: feedback from Google?

mwest: I think there are reasons to make the change. put together some text

https://www.w3.org/2011/webappsec/track/actions/130

CSP and user script + extensions

glenn: review by cablelabs and a number of commercial TV operators

… cox, comcast, etc.

… web and tv interest group

… for certain services and TV we have a regulatory requirement for best effort emergency notification

… CSP could help prevent attacks that prevent delivery of messages

… there is an open-ended clause that doesn't specify how add-ons/extensions behave

… would be good if we could treat this issue more in depth

… little support for making any behavioral change in the spec at this time.

… I continue to feel that the current behavior doesn't do an adequate job of describing the overall issues around this area.

… remove that text

… perhaps in another document?

… I withdraw a request for adding new directives/extensions

… request that the specific recommendation in the text be removed

bhill2: poll doesn't show a lot of support for making any changes

… does anyone want ot weigh in now?

glenn: I don't believe I am asking for a change in behavior.

… it's implementation dependent

bhill2: all the implementations behave the way you would like them to.

… but there was consensus that it should behave the way the spec says, but implementors have been having trouble followin the spec recommendation

… asks dveditz what mozilla's plans were

dveditz: looking at an API for add-ons to alter the policy but not letting the add-ons blindly changing pages regardless of policy.

… add-ons should be able to modify the page if they want to, but they shouldn't do so accidentally

bhill2: chromium and firefox are rather different

… should there be a recommendation with a normative should?

mkwst: code executed from a content script, we do our best to let it do the things it wants to do.

… we have most of the problems fixed, but some we don't know how, e.g., bookmarklets

dveditz: same for firefox

mkwst: all extensions in chrome are subject to relatively strict CSP policy

… evaluating the next version of manifest.

<mkwst> http://crbug.com/181602

dveditz: does the extension CSP apply to the document or to the extension context

mkwst: applies to the all extension pages

glenn: one of the objections to the line of thinking I was propposing was priority of constituencies

… having the user install an add-on is an explicit permission to execute it

… the policy we would like to see is that the user might have more than one intent

… e.g., user may feel it is appropriate to use those extensions but may have given permission to a content service provider to disable those extensions

… having a static policy that doesn't enable this is clearly damaging

…maybe having error reporting disabled would be more appropriate

mkwst: I don't have an objection to removing the line in the spec that says do your best to avoid messing with extensions and since browser vendors have decided that extensions can do what they want

ekr: maybe replace with a sentence that's descriptive rather than normative

"Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets." is the relevant text?

Proposed text: "Generally, CSP policies will not not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets, though the precise details by which such scripts are allowed to override CSP policies may vary between browsers."

mkwst: if we don't let extensions override policies, then they will just remove them

garrett: I think we should make this clear

dveditz: that's why we have the text we have

glenn: is there any thought of restricting the extension's ability to modify headers so that, for instance, they can't modify CSP headers.

mkwst ??? : anything is possible

glenn: maybe we should have more restrictions

bhill2: one thing people do is use extensions to *add* CSP headers

mkwst and glenn to own providing some text to the list

<scribe> ACTION: mkwst to provide text to list about interaction btwn extensions and CSP is [recorded in http://www.w3.org/2013/10/08-webappsec-minutes.html#action01]

<trackbot> Error finding 'mkwst'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

<mkwst> mwest2 <--

<scribe> ACTION: mwest2 to provide text to list about interaction btwn extensions and CSP is [recorded in http://www.w3.org/2013/10/08-webappsec-minutes.html#action02]

<trackbot> Created ACTION-151 - to provide text to list about interaction btwn extensions and csp is [on Mike West - due 2013-10-15].

DOM API for CSP 1.1

mkwst: DOM API is currently read-only

… topic is whether we should make it read/write

… alex's proposal involves taking the internal API, cleaning it up, and letting the web page construct policies and apply them to the page

bhill2: what are your feelings in terms of timelines

mkwst: would like to see it included. not sure it's realistic. give me until the next call to see if I can deliver something

Poll on closing CSP 1.1 feature set

bhill2: sticking to our charter to deliver finished products on a reasonable time frame

… like CSP to be a living standard

… have received poll requests from a bunch of people

glenn: thanks for the correction

bhill2: universal assent to close the feature set

… only question with a real lack of consensus was the second question.

… this poll was only about 1.1 not about forever

… declaring feature set closed

… please think about question 2. Would like to come to consensus on the next call

glenn: are you suggesting that the CSS object model be a normative dependency of CSP

bhill2: ian's proposal was to restrict inline script

… ande eval

dveditz: we do block inline style

… for consistency unsafe-eval should apply to attempts to modify the style

glenn: my question was about normative references

bhill2: something to think about

… the question is if this is ready for csp 1.1