W3C

Web Application Security Working Group Teleconference

22 Oct 2013

Agenda

See also: IRC log

Attendees

Present
BHill, Wendy, abarth, glenn, mkwst, CCarson, gopal, gmaone, +1.650.386.aaaa, tanvi, +1.714.795.aabb, neilm, ekr, +1.415.596.aacc, puhley, +1.781.369.aadd
Regrets
Chair
bhill2, ekr
Scribe
mkwst

Contents


<trackbot> Date: 22 October 2013

<bhill2> test

<ekr> bhill2: test received

<ekr> I will be a few minutes

<ekr> late

<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

Minutes approval

<bhill2> last meeting's draft at: http://www.w3.org/2013/10/08-webappsec-minutes.html

bhill: Objections to approving minutes?

everyone: ...

bhill: approved.

Agenda Bashing

bhill: Any other business?

wseltzer: Charter? Add to agenda, thanks to those whose reps commented.

tracker

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

bhill: delay ACTION-141 to mid-December. Not CSP 1.1.
... ACTION-143

(sorry; missed a bit there. my network connection is poor.)

bhill: push ACTION-143 to next call.
... 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.
... ACTION-146.
... 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 it done?
... 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.

UISecurity input protection algorithm

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0062.html

bhill: posted a new draft of UISecurity spec.

<gmaone> https://dvcs.w3.org/hg/user-interface-safety/raw-file/43644c06b379/user-interface-safety.html#alt_heuristic

<wseltzer> ACTION-134?

<trackbot> ACTION-134 -- Brad Hill to report dependencies on event types -- due 2013-05-25 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2011/webappsec/track/actions/134

bhill: touch/pointer events might not be defined in all agents;

<bhill2> https://www.w3.org/2011/webappsec/track/actions/134

bhill: "should" requirement documented in http://www.w3.org/2011/webappsec/track/actions/134
... does that avoid the dependencies, abarth?

abarth: looks fine.

bhill: closing.
... compositing.
... 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 now.
... if at risk, we can make a decision later.

frame-options location

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0049.html

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 call there.
... one cohesive document describing approach to securing UI.

tanvi: timelines will be fairly similar?

bhill: editorial timelines similar.
... 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.

script hashes, inline and src'd

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0070.html

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.

referrer control strawman

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0086.html

<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.

mkwst: wait?

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.

Charter update, AOB

<wseltzer> http://www.w3.org/2013/07/webappsec-charter.html

<wseltzer> https://www.w3.org/2002/09/wbs/33280/security2013/results

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 to charter.
... next step is to present to tomorrow's w3c meeting.

bhill: thanks, and good night!

<wseltzer> trackbot, end teleconf

Summary of Action Items

[End of minutes]

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