See also: IRC log
<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: 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
thx
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)
yeah
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!