Web Application Security Working Group Teleconference -- 17 Nov 2014

<trackbot> Date: 17 November 2014

<moneill2> thats me on the phone i think

<bhill2_> Meeting: WebAppSec WG Teleconference, 17 November 2014

<bhill2_> Chairs: bhill2, dveditz

<bhill2_> I may be a few minutes late joining the call - meeting room I booked is still occupied, sorry.

<bhill2_> scribenick: dveditz

<bhill2_> Scribe: Dan Veditz

Minutes Approval

bhill2_: 1st topic, minutes approval

<bhill2_> http://www.w3.org/2014/11/03-webappsec-minutes.html

bhill2_: any objections?

<bhill2_> minutes approved by unanimous consent

Agenda Bashing

bhill2_: mkwst suggested we move the bug tracking subject earlier in the mtg
... any other topics? we've had an active list and I didn't get to put everything into the agenda

deian: <wanted to bring up something that wasn't mentioned first on the list>

bhill2_: we try to make the list our first mention for people who can't make the calls

which bug tracker to use?

<bhill2_> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0097.html

bhill2_: Anne had a comment that he was losing track of issues and what's been resolved
... wanted to have a link in each spec for instant bug reporting like some whatwg specs
... we have bugzilla, w3 issue tracker, and github now

mkwst___: not interested in the w3 issue tracker. agnostic between github and bugzilla
... github is nice because the spec is there, bugzilla seems to be where other things are

bhill2_: the benefits of the w3 tracker is that it's integrated with the rest of our tooling, group members are already added, etc
... I have a negative preference for bugzilla because it's #3. we have a history of not using it so far so seems odd to suddenly start using it

freddyb: I haven't used them for this group, but I like using github

bhill2_: postive to neutral sentiment for github, some negatives for the other two

<freddyb> I used github as a co-editor of SRI - but the others not.

bhill2_: it does have a good REST api, could collaborate with other WGs to make better tooling

<bhill2_> ACTION bhill2 to investigate git issue tooling with other w3c groups

<trackbot> Created ACTION-200 - Investigate git issue tooling with other w3c groups [on Brad Hill - due 2014-11-24].

Mixed Content enters Last Call

yay

<wseltzer> thanks Mike and contributors!

scribe: mixed content entered LC on Thursday. this triggers the exclusions period. if your group has IP exclusions to raise the clock is ticking
... things are moving fast, if you have friends and colleagues that might have opinions on it please invite their review

Informally extend comment period for CSP Level 2?

scribe: we've officially completed the comment period for CSP2 and close to moving to candidate recommendation
... but we've gotten a bunch of late feedback (from Brian Smith) and Mike mentioned he'd like some time to incorporate that

<bhill2_> I'm going to have to rejoin from my desk.

mkwst___: the question is whether we want to extend the comment period so we can incorporate that feedback
... any other thoughts on that

dveditz: I agree, especially since he mentioned having more feedback to come
... is there anyone in favor of NOT extending LC?

<wseltzer> PROPOSED: Extend LC comment period

wseltzer: there are two things you could be doing -- just extend the time without doing anything, or formally reopen the comment period (and respond to comments)

mkwst___: I don't have an opinion on the formal status but I do want to take a week or two to work through brian's feedback

bhill2_: do you think you could be done before the holiday period or do you want to build in some slack and say wait until Jan 15?

mkwst___: I would very much like it to be done THIS year, and not drag out to January

bhill2_: I have no problem taking this two weeks at a time and checking status on the call

wseltzer: the obligation is to respond to comments that came in deuring the comment period. there's no prohibition on responding to comments that come in after

Proposed new Charter

<bhill2_> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html

bhill2_: ok, let's respond to brian and try to move this along as fast as we can

<scribe> ... new charter based on discussions at TPAC

UNKNOWN_SPEAKER: of the ones proposed, making the cut are continuing CSP, retire CPS1,

<wseltzer> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html#deliverables

UNKNOWN_SPEAKER: the last one proposed was the permissions API. Dan and I are OK with it as long as there's an editor associated with it

<wseltzer> +1, I've heard interest

UNKNOWN_SPEAKER: it's a relatively simple spec and shouldn't cause anyone to withdraw on IPR grounds. hearing no objetions I'll add that to the charter
... we need to have a voting period where the charter is sent to members to be reapproved.
... I'll start that on the mailing list. any objections?

<bhill2_> ACTION bhill2 to add permissions API to draft charter

<trackbot> Created ACTION-201 - Add permissions api to draft charter [on Brad Hill - due 2014-11-24].

<bhill2_> ACTION bhill2 to issue CfC on new draft charter

<trackbot> Created ACTION-202 - Issue cfc on new draft charter [on Brad Hill - due 2014-11-24].

CSP] PING-- CSP vs. Fetch

<bhill2_> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0259.html

<wseltzer> action; wseltzer to work with bhill2 on w3c-side activities for rechartering

mkwst___: we've gone back and forth at least once. the current model is that ping is form action because it can only do things forms can do. sendBeacon is connect-src because it does things that XHR can do
... CSP matches this, but the fetch spec does not. I don't feel strongly either way

dveditz: I don't either

mkwst___: let's take it back to the list

[SRI] Escaping mixed-content blocking for video

bhill2_: Mark watson from Netflix asked us to consider this

devd: should we discuss this as part of SRI or as part of the Mixed content spec?

mkwst___: regardless of what we do with mixed content there is a desire of people to get large files with integrity

<bhill2_> raise ISSUE SRI for very large files / streaming

devd: I would feel better if the subject of this topic were changed to @@. I agree this could be pushed to SRI v2 and not done in v1

bhill2_: let's shoot for that

<bhill2_> ACTION: bhill2 to raise issue for SRI large object /streaming integrity [recorded in http://www.w3.org/2014/11/17-webappsec-minutes.html#action01]

<trackbot> Created ACTION-203 - Raise issue for sri large object /streaming integrity [on Brad Hill - due 2014-11-24].

bhill2_: should we reply to Mark that he should split this into two issues?

mkwst___: Mixed content is in last call. If there's a comment we'll have to address it
... they want to serve video over http on a site that's https, and we need to decide whether we want to allow that in the browser and what kind of UI.

<bhill2_> ACTION bhill2 reply to Mark Watson that 1/2 of his issue is a Last Call comment to MIX

<trackbot> Created ACTION-204 - Reply to mark watson that 1/2 of his issue is a last call comment to mix [on Brad Hill - due 2014-11-24].

<bhill2_> dev: SRI gives tools for integrity, MIX yields a state, UI treatment of that state is left to browsers

<bhill2_> dveditz: one concern with mixed content is possible leaking of cookies, could add an attribute to suppress cookies

<bhill2_> mkwst: not out of the question, it's not a good idea, but it's better than status quo

<bhill2_> ... not clear how to get there, exceptions for XHR leave holes, maybe need a variant that only allows video

mkwst___: there was some stuff in SRI about XHR but it's out for v1

Re: [CSP] Clarifications regarding the HTTP LINK Header

<bhill2_> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0251.html

<bhill2_> deian: doesn't hurt to have a few extra lines of text to clarify the interactions

<bhill2_> ACTION bhill2 does LINK really violate CSP guarantees?

<trackbot> Created ACTION-205 - Does link really violate csp guarantees? [on Brad Hill - due 2014-11-24].

bhill2_: let's skip on to referrer policy issues while Mike is trying to reconnect

Further Referrer policy stuff

<bhill2_> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0160.html

dev: would prefer if i could specify which referrer is used, this is used for all kinds of analytics

<bhill2_> dev: getting more control over referrer string is important for widely deployed analytics tools

<bhill2_> devditz: arbitrary referrer?

<bhill2_> dev: same origin only. can already do this with history.pushState(), but it is fragile

dev: same origin! but yes. in theory can already do this with pushstate but it's fragile

mkwst___: not clear this would be used and it makes things more complex, but no strong objection if it's necessary and might replace some redirects

dev: suppressing referer completely isn't that useful

bhill2_: facebook does a lot of redirects to make the referer the same on clicked links.
... is itbetter to use a predefined set of buckets or allow a more expressive syntax that lets them specify exactly what the site wants

mkwst___: I like dev's suggestion because it's simple, "this is the referrer for everything on this page".

bhill2_: it's good to provide the widely used options in a declarative fashion, and complex stuff needs to be punted to an imperative spec (like ServiceWorker?)

<bhill2_> ACTION bhill2 reply on referrer suggest imperative policy controls in ServiceWorker

<trackbot> Created ACTION-206 - Reply on referrer suggest imperative policy controls in serviceworker [on Brad Hill - due 2014-11-24].

mkwst___: webkit, chrome and opera are already shipping a declarative meta header, we should at least specify that

Clarification of CSP sandbox and workers

<bhill2_> http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0211.html

bhill2_: skipping back to earlier in the agenda...

deian(?): what happens to a worker created from a sandboxed iframe?

<bhill2_> deian: what if we include sandbox header when returning a worker

<bhill2_> mkwst: that is a good use case, but we should delegate behavior to HTML

mkwst___: I do see value in sandboxing (unique origin) a worker, controlling access to localStorage and so on
... seems like it should be specified by HTML though, not CSP

<bhill2_> ACTION bhill2 to raise definition of sandboxed worker in HTML spec

<trackbot> Created ACTION-207 - Raise definition of sandboxed worker in html spec [on Brad Hill - due 2014-11-24].

bhill2_: if no objections consider the call adjourned
... we'll be back in 2 weeks

- DRAFT -

Web Application Security Working Group Teleconference

17 Nov 2014

Attendees

Contents