WebAppSec WG Teleconference Nov 20, 2012

20 Nov 2012


See also: IRC log


+1.650.648.aaaa, [Mozilla], +1.206.304.aabb, +1.310.597.aacc, +1.866.317.aadd, +1.415.596.aaee, [IPcaller], mkwst, dveditz, abarth, gioma1, Tanvi
Adam Barth, abarth


<imelven> hello !

<bhill1> Scribe: Adam Barth

<bhill1> Scribenick: abarth

/invite rrsagent

<gioma1> gioma1 is on the phone

<scribe> Meeting: <name> (WebAppSec WG TPAC2011 F2F [Oct 31|Nov 1] 2011)

<scribe> Scribe: abarth

<scribe> ScribeNick: abarth

no minutes for TPAC yet

busy week of catchup for bhill1

should be ready for next call

bhill1: any more items for agenda?
... Add discussion of CSP 1.1 to FPWD
... after rechartering discussion
... news
... TPAC successful
... met with anne about CORS
... CORS should be stable for several years
... we should try to get to CR, making progress down that road
... invited expert from web accessibility working group
... related to UI safety algorithms
... updated the text based on this information
... In other news, CSP 1.0 has been published as a CR
... and a FPWD of UI safety
... IETF was in Atlanta and liasoned with websec working group
... IETF web sec agreed to move work on future of frame-options to UI safey draft
... Tobias will join the working group to help with that work
... TPAC plenary session about fingerprinting
... is it futile?
... link to slides posted to the privacy interest group mailing list
... many open concerns, unsure if any consensus
... harder problem than many realize
... need to have a concrete understanding of the threat model for privacy
... next item on the agenda: CORS CfC
... much discussion at TPAC
... remove the diagram that bhill1 added in the interest of moving the document forward
... incorporated all the comments from jeffh
... (all non-normative)
... some normative changes, mostly bug fixes
... some positive feedback, but not much
... please indicate consent on the mailing list
... i helps to have people weigh in when we go to the director
... even something as simple as a +1 helps
... art commented on the exit criteria

<dveditz> that's for CSP, not CORS, right?

for CORS

<dveditz> are there not two complete implementations?

bhill1: is there any objection to setting the exit criteria for CORS as
... two independent implementation of each feature
... individually
... …. no objections
... next item: test suite status
... discussed at TPAC

hi mkwst

<mkwst> hi abarth :)

Zakim: aaaa is abarth

bhill1: Need to fix test suite with Vary: Origin
... seems like a sharp edge in protocol
... we need to have independent implementations of the user agent portions of the specification
... do you think we should require reference implementations of the server side?

abarth: I don't think there's a risk that it's not implementable on the server. I've personally done like four of them

bhill1: ok, maybe we can leave that out of the exit criteria
... next item: rechartering
... sent link to the list

<bhill1> http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/att-0094/Web_Application_Security_Working_Group.htm

bhill1: updated version of the charter from TPAC
... mostly the same as the current charter
... updated timelines to match reality
... added CSP 1.1 with LC in july, etc
... similar schedule for "sub resource integrity"
... want to get a good feel for people's interest in exploring this topic
... been discussed previously as a link fingerprint
... web site can include a hash of the sub resource
... verify that the content you receive is exactly what you expect (e.g., from a third party)
... could also supply an alternate transport that's more cache-friendly
... such as HTTP
... but avoid trigging mixed content warning
... adding more complexity might be a tarpit
... we should liaison with the HTML working group
... there was strong interest in TPAC, but want to discuss with a broader audience

abarth: there are definitely people inside of google who would like to see this happen, but that's been true for a while and it hasn't happened yet

dveditz: one concern from mozilla is questions about sorts of resources would this work for?
... we also need to worry about the privacy aspects of HTTPS in addition to integrity
... not that a particular resource was loaded, but more the cookies

bhill1: are these technical concerns that can be ironed out?

dveditz: people are excited about the integrity checking, but some concerns about the interaction with the security indicators

abarth: should i dig up proposals from the internal discussions from google?

dveditz: there are lots of proposals floating around
... they come down to similar functionality

bhill1: I don't have a proposal beyond a chalkboard sketch
... are people interested in doing this in this group?

<dveditz> my answer was not a "no" :-) .. if you've got something concrete it might be a good start

<jeffh> Gerv is one of the folks to chat with: http://www.gerv.net/security/link-fingerprints/

abarth: I'll dig around for the design docs and encourage the folks who are interested in them to join the working group

jeffh: I think this something to explore and if the right people show up and have cycles, it could be great

bhill1: we add two liaison groups to the sys apps group and the web crypto group
... had a joint session with web crypto group
... sys app is starting up
... to adding OS-level API for web content
... the first thing they have to do is come up with a security model
... we should make sure that the security models are consistent and function well with CSP
... ekr wants to make sure we can extend sandbox to make sure it controls access to crypto stuff
... any additions or objections to this list?

<mkwst> again.

bhill1: move to formal approval at the next call

<jeffh> am not certain what "this list" refers to, but the above stuff wrt providing feedback into "sys app" work sounds nominally fine

"this list" means the list of groups to liaison with

<jeffh> k, thx for clarification

bhill1: next issue: CSP 1.1 issues
... which things before FPWD and which after as issues?

mkwst: I think its probably worth looking at the issues we currently have

<dveditz> jeffh: the "Dependencies and Liaisons" section of the proposed charter

<jeffh> thx

mkwst: not in a big rush to get a draft out the door, but nothing seems like a big blocker

<bhill1> http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0025.html

bhill1: first issues: continuing the discussion about inline styles
... jonas joined us at TPAC to discuss this issue

abarth: ian sent me some text---i will review by EoD

<imelven> thanks adam

imelven: there have been some more iterations inside mozilla, but nothing too suprising
... there are two pieces
... one is about the text about what inline styles to block

<jeffh> is the proposed txt re inline styles on the mailing list?

imelven: and the second is about a hierarchy from font-src to style-src
... add a check when a stylesheet requests a non-image subresources

dveditz: I think it was more that background image is a specific value
... as opposed a string that gets parsed

abarth: that generally makes sense to me, but I need to get into the details

dveditz: mostly about clarity
... they just want to have a spec that's clear

imelven: I think its fine to do that in 1.1

abarth: we can clarify as much as we want in 1.1 and then bring that text over to 1.0 when we move to PR

<bhill1> http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0028.html

bhill1: next item: restricting APIs in CSP
... basic question is whether its worth having a mechanism to restrict API access like getUserMedia
... crypto, device APIs that allow access to features


bhill1: ekr has proposed that new features be enabled explicitly in CSP rather than blacklisted
... thoughts from those on the call?

dveditz: we've already gone to a "turn things off" model
... largely out of worries about forward compatibility
... but I am concerned that we're adding features all over the browser

mkwst: maybe the solution is to combine with sandboxing
... might work well for get user media

dveditz: yeah, but you only get one shot at it
... otherwise there will be a time when the UA knows about the feature but doesn't know to sandbox it
... the next version of the UA might break content
... I find the idea appealing, but it is problematic
... alternative: watch every spec is every working group

mkwst: sandbox might have less breakage

<imelven> that was me

<jeffh> s/is every/in every/ ?

<imelven> sorry

actually that was imelven

dveditz: we try to keep on top of the features that are going into our browser and we can try to police them
... if we agree quickly enough, it might be possible

<mkwst> ... Zakim doesn't like me.

abarth: sys apps will likely want to do this for sys apps api, but scaling to the whole platform is tough

<jeffh> where "this" is somesort of whitelist ?

<mkwst> "this" is an opt-in model for new APIs.

yes, features off by default and then needing to be whitelisted in a policy to enable them

bhill1: we might want to explore these possibility in CSP 1.1

<bhill1> http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0083.html

bhill1: maybe we should table this until we get some concrete proposals
... next topic: subsuming X-XSS-Protection in CSP
... created by Microsoft when then added their XSS filter
... not formally specified, but also in WebKit
... adding into CSP gets us reporting too

mkwst: what I've added to CSP 1.1 currently is very basic---just three states
... its unclear how to make the reporting worthwhiel
... we might need to revisit that at some point
... the specification itself is very straightforward

dveditz: of the few sites that are using CSP many of them have inline script turned on
... so adding a report for when the XSS filter finds something seems worthwhile

<dveditz> how do you specify the reporting URL? yet another header?

<dveditz> addition to the X-XSS-Protection header?

<dveditz> or are you saying that you've added it to your CSP impl

dveditz: we added a report-uri parameter to the X-XSS-Protection header

^^^ that was me talking to dveditz, not something he said

<dveditz> site authors probably just want to know 1) that you blocked/found something, 2) what's the URL (which contains the filtered xss by definition)


bhill1: last issue on the agenda: are there certain types of directives that don't make sense in the meta tag
... I would rather spend the last four minutes on asking mkwst and abarth if we're ready to move towards FPWD of 1.1

<dveditz> I'm agnostic whether this happens in CSP or not. seems like a useful feature wherever it goes

abarth: I support moving to FPWD so that we have something to work on

bhill1: send me a version so we can start that process
... that brings us to the end of the agenda
... thanks everybody
... submit comments on UI safety and CORS CfC

<imelven> thank you ! :)

<jeffh> thanks!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2017/02/15 22:32:52 $