See also: IRC log
<trackbot> Date: 22 October 2013
<ekr> bhill2: test received
<ekr> I will be a few minutes
<bhill2> Meeting: WebAppSec WG Teleconference, 22-Oct-2013
<wseltzer> Charter diff: https://cvs.w3.org/Team/WWW/2013/07/webappsec-charter.html.diff?r1=1.14;r2=1.12;f=h
<bhill2> is P6 giorgio?
<bhill2> Gopal, are you able to scribe? JeffH sent his regrets today, you are next.
<bhill2> scribenick: mkwst
<bhill2> last meeting's draft at: http://www.w3.org/2013/10/08-webappsec-minutes.html
bhill: Objections to approving minutes?
bhill: Any other business?
wseltzer: Charter? Add to agenda, thanks to those whose reps commented.
bhill: delay ACTION-141 to
mid-December. Not CSP 1.1.
(sorry; missed a bit there. my network connection is poor.)
bhill: push ACTION-143 to next
... ACTION-144. Not tackling that in 1.1.
... ACTION-133. Consider that done.
... Cannot normatively spec what's in xpath.
... Structure changes dynamically. Implementers might want to include additional metadata, tagging ancestor elements.
... Closing, comment directly on draft.
... Both of dveditz's actions are still open.
... script interface?
mkwst: would like to get something into 1.1 if possible.
bhill: nice to have. can we get
... due date? help?
mkwst: probably. what's the 1.1 timeframe?
bhill: October. It would be nice not to slip.
mkwst: if i can't get it done this week, let's bump it.
bhill: updating due date.
... referrer policy, closing.
... new text for extension/CSP interaction.
mkwst: i thought dveditz was doing that. oops. will do that this week.
glenn: i'll work on that with mike.
bhill: updating due date.
bhill: posted a new draft of UISecurity spec.
<trackbot> ACTION-134 -- Brad Hill to report dependencies on event types -- due 2013-05-25 -- PENDINGREVIEW
bhill: touch/pointer events might not be defined in all agents;
bhill: "should" requirement
documented in http://www.w3.org/2011/webappsec/track/actions/134
... does that avoid the dependencies, abarth?
abarth: looks fine.
... text to list, comments back from david.
... new editor's draft. comments or questions?
... new algorithm looks good. might even be faster than the previous.
... looks like we could reuse some of the things coming up in webrtc; tab capture, etc.
... tracking dynamic region of changes for input protection might be problematic.
... remove ability to specify clipping rectangle around cursor?
... if no clipping window, and specify document root, probably breaks things.
gmaone: is this a roadblock we can't work around?
bhill: leave them in for
... if at risk, we can make a decision later.
bhill: thoughts on moving
frame-options out of UISecurity?
... dveditz proposed it. ian liked it.
... will this change the speed of adoption?
tanvi: why is it a bad idea?
bhill: collection of related
functionality in UISecurity spec. about ready to go to last
... one cohesive document describing approach to securing UI.
tanvi: timelines will be fairly similar?
bhill: editorial timelines
... browser folks comment on implementations?
abarth: questions about how the whole thing would look in compositor model.
bhill: maybe talk to whitehat folks. they like security. and they have a browser.
tanvi: frame-options. firefox has
frame-ancestors, which does more or less the same thing.
... kept in both prefixed and unprefixed header.
... folks can use it now, but we'd like to switch to the standard syntax.
bhill: input protection heuristic?
tanvi: don't know if anyone's looked at that.
bhill: let's revisit this before last call.
bhill: inline content only seems
to be the way the list is going.
... external script via separate spec; subresource integrity.
... no objection to script hashes apply only to inline content.
<bhill2> mkwst: more or less direct relationship to referrer control meta implemented in webkit browsers
<bhill2> three questions:
<bhill2> mkwst: ... 1: a good idea?
<bhill2> ... 2: how integration with Fetch should work or refer to / integrate with W3C spec?
<bhill2> ... 3. never mind..
mkwst: 3. multiple policies?
<bhill2> ... 3. multiple policies?
mkwst: questions around whether conflict resolution is reasonable. use-cases for single-page applications to inject policy for various views.
<bhill2> abarth: this is where a DOM API would be good, to set/unset it
mkwst: allowing loosening referrer policy would be different than other directives.
<bhill2> abarth: we could be in a better place in the future when better at mutating policies
abarth: might have some sort of mutable vs. immutable policy distinction.
bhill: could specify something around the api such that headers are immutable, but api-settings might be more flexible.
abarth: setting via api when views change.
abarth: we might address use cases in a different way.
mkwst: a little concerned about having differing behaviors for <meta> vs CSP.
abarth: introduces complexity to referrer policy for a document. if it comes from one, mutable, from the other, immutable.
<ekr> sorry had to go
mkwst: will ask for feedback on the list with a more clear description of the problem.
bhill: other business? charter update.
wseltzer: proposed charter, went
to advisory committee, members indicated support.
... comments: perhaps the group should add something about CSP for the legacy web, and for established frameworks like jQuery.
... is there anything we might want to clarify, respond to those comments about the scope>
bhill: script hash/nonce are the
major attempt in 1.1 to deal with legacy.
... not problematic to add that to scope explicitly.
... legacy libraries, eval is probably the main problem.
... is CSP the right place to tackle that? perhaps tainting would be better?
... more fundamental change.
... think we're getting good traction, actually.
??: feature detection would be useful.
bhill: yes, that's certainly an
interesting part of 1.1.
... objections to adding language to charter to deal with legacy?
wseltzer: would also be fine to
respond that we're working on that, without making any changes
... next step is to present to tomorrow's w3c meeting.
bhill: thanks, and good night!
<wseltzer> trackbot, end teleconf