See also: IRC log
<wseltzer> trackbot, prepare teleconf
<trackbot> Date: 13 August 2014
scribenick dveditz
<scribe> scribenick: dveditz
<scribe> scribe: Dan Veditz
Minutes Approval
http://www.w3.org/2014/07/16-webappsec-minutes.html
dveditz: hearing no objections the minutes are approved
Welcome David Ross from Google
Call for exclusions for Mixed Content issued July 22
period ends December 19, 2014
FPWD of Referrer Policy published Aug 7
http://www.w3.org/TR/referrer-policy/
Call for exclusions for Referrer policy issued Aug 7
period ends January 4, 2015
CSP2 Last Call period ends today
http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0017.html
dveditz: I propose extending the csp2 last call until the next call given light summer attendance and a specific request from Microsoft
mkwst: I don't want to keep extending, but a limited extension to next call would be OK
dveditz: that would be August 27
mkwst: I'm fine to extend further if there really are things to talk about, but not so much extending just because of lack of response
glenn: Kevin Hill responded on the list that 2 wks is reasonable
greghuc: what actually happens when CfCLC is over? is it set in stone?
mkwst: no, errors can still be
corrected, we just can't change the feature set
... I've been waiting for this period to end before starting on
CSP3 features so I'd like to get this out the door
http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0113.html
dveditz: I believe this was resolved in the list -- inline svg is NOT governed by img-src
http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0083.html
dveditz: inspired by the sandbox
attribute perhaps?
... is that part of this group or part of SW?
... alternate proposals, e.g. content-type
mkwst: they should design this in
the service worker spec and we can then evaluate their
solution
... don't think we will end up with a SW directive, I prefer
the content-type solution or something along those lines
dveditz: another concept was the
browser sending hints
... that is send whether a request is an IMG, or script, or
XHR, or service worker, etc
mkwst: would be worthwhile to
discuss further on the list
... we would probably want to add this kind of thing to the
Fetch spec
... should be relatively easy to specify as part of fetch if we
want to do this. there are certainly benefits but we need to
think carefully about whether there are drawbacks
... certainly not part of CSP
http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0003.html
greg: having read through the
responses to the Evernote concern it does look like everyone is
on the same page in terms of not wanting UAs to interfere with
addons and bookmarklets
... would like to have future versions of the spec be clearer
about these desires, perhaps even specifying the behavior of
bookmarks
mkwst: as a browser vendor I do
want extensions to work
... it's possible in chrome by modifying the header as the
response comes in. unfortunately most people doing that now
simply remove the header
... we need a more specific extension API so they can simply
add (whitelist) origins without conflicting with other
extensions rtying to do the same thing
... I don't think this belongs in the spec because by nature
it's a proprietary API
... although a note suggesting the approach might be
appropriate
glenn: we need to recognize that
UAs need to have the freedom to disable all extensions if it
wishes to do so, such as if users ask it to
... since there's no new information and we have general
agreement I don't think we need to take any action
greg: mike and dan -- do you see a bigger statement in future versions of the spec?
mkwst: I don't think the spec will say much more about proprietary extension things. But we consider the current behavior a bug and I don't expect chrome's behavior to change for the worse regardless of the spec
dveditz: Mozilla also considers the current behavior a bug and is trying to figure out ways to fix it
greg: as long as browser vendors recognize that there are valid reasons, not an attack, for extensions to be injecting resources and scripts into a page
http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0101.html
mkwst: Ian's concern was the spec
was very javascript specific. we did make changes to the spec
in response to the thread
... I dont' think there's anything wrong with the concept in
the spec, it's how we've stated it. we may need to find a new
wording but we have time to do so
... without Ian and Joachin on the call I don't think we can
resolve this here. should do this on the list
http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0009.html
dveditz: David Ross proposed EPR, but he's not on the call
<mkwst___> (zakim hung up on me, and now isn't letting me back into the meeting. :( )
dveditz: might be interesting to
take on in WASWG (we need to re-charter in September) but we
should discuss more on the list
... any other topics?
meeting adjourned