WebAppSecWG TPAC 2011 F2F - Oct 31 -- 31 Oct 2011

<stpeter> tell ekr to stop yammering so we can start the meeting :P

<stpeter> bhill2: only joking ;-)

<bhill2> we'll get going at 5 after

<anne> i'll be there at 10AM, is that okay?

<bhill2> yes, we are expecting you then, and we'll head back to WebApps with you afterwards for the joint session

<anne> currently at webapps; having to be at three WGs at the same time is really hard

<anne> k thanks

<bhill2> unless we have a bigger breakout room that will fit four WGs

<Eric> so anyone knows what is going to be broadcasted to the IRC channel?

<stpeter> is anyone in IRC not in the physical room? just curious

<Eric> me

<stpeter> well, I see that anne is not in the physical room, for one

<stpeter> zakim rocks

<stpeter> bhill2 is reviewing the agenda

<Eric> I'm using the voice bridge too, thanks

<stpeter> bhill2 puts on screen http://www.w3.org/2011/08/appsecwg-charter.html

<stpeter> deliverables being content security policy, secure cross-domain resource sharing, secure cross-domain framing (see charter for details)

<stpeter> brandon has no comments on CSP

<stpeter> CORS is joint deliverable with WebApps WG

<stpeter> UMP status is somewhat less clear, discussion needed

<stpeter> SCDF is farther in the future

<stpeter> coordination desirable with IETF WebSec WG on Frame-Options / SCDF

<stpeter> Jeff Hodges: do we want / need to investigate a broader approach, not just single headers

<stpeter> Brad Hill: especially clickjacking is an artifact of the web architecture, how do we deliver policy for solving?

<stpeter> milestones might need to be revised / updated

<stpeter> charter review questions...

<stpeter> Larry Masinter: it's hard to tell what the scope of this WG is

<stpeter> i.e., where the boundaries are

<stpeter> Larry: might want to document things that we're not doing that need to be done

<stpeter> LM: what is the filter to decide what is in scope for this group or not?

<ekr_> Larry: don't want to lose track of things we decide are out of scope.

<stpeter> LM: don't want to lose track of things that are decided to be out of scope -- need an overall roadmap to web security

<masinter> I have a TAG action item http://www.w3.org/2001/tag/group/track/actions/607 to hand off http://www.w3.org/2001/tag/2011/02/security-web.html

<ekr_> Brandon: my luggage password is 12345678

<bsterne> ekr_: nice

<ekr_> Larry: This is John Kemp outline of the history and security features of the web. WE didn't finish it and would like to hand it off to a WG focused on Web security.

<ekr_> Larry: Please accept it as input somehow.

<ekr> bhill2: What's the process for doing something with this?

<ekr> Larry: This is an attempt to outline the overall frameworj.

<ekr> Larry: Should document why these particular deliverables.

<ekr> bhill2: Sounds like something we want ot publish somehow, but it's not clear to me how to handle it.

<ekr> tlr: If the WG wants to rearrange structure of deliverables within the same scope, that's fine.

<ekr> tlr: if you want to add something normative to the list of deliverables nad it's not covered by the current scope, then you need to recharter

<ekr> Larry, tlr: this happens frequently

<ekr> tlr: this sounds like a non-normative document. [so probably ok -- EKR]

<ekr> stpeter: we had the same issue with websec. wanted to work on a framework. Looked at the low hanging fruit.

<ekr> =jeffh: should be looking at the long-term thing as we chip away

<ekr> tlr: what's the relationship between all these documents?

<stpeter> ekr: there certainly is space for a document about overall direction (how all these things work together)

<ekr> ACTION: Investigate this question and figure out how to proceed on it [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action01]

<trackbot> Sorry, couldn't find user - Investigate

<stpeter> ekr: worry about putting stakes in the ground for particular solutions will partly determine the large solution space in the future

<ekr> ACTION: unassigned - Investigate what to do with adocument of this scope. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action02]

<trackbot> Sorry, couldn't find user - unassigned

<masinter> TAG ACTION-607: Find an appropriate way to make available http://www.w3.org/2001/tag/2011/02/security-web.html to the Web App Sec working group

<ekr> dsr: can oyu create the action item cause I'm apparently too stupid to figure it out

<stpeter> ekr: broad framework will either result in duplication or deprecating "patchwork" solutions

<scribe> ACTION: bhill2 to find an appropriate way to make available http://www.w3.org/2001/tag/2011/02/security-web.html to the Web App Sec working group [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action03]

<trackbot> Created ACTION-1 - Find an appropriate way to make available http://www.w3.org/2001/tag/2011/02/security-web.html to the Web App Sec working group [on Brad Hill - due 2011-11-07].

<stpeter> ekr: ask ourselves, "is this patchwork solution committing ourselves to unfortunate consequences in the future?"

<stpeter> masinter says at least document the future-oriented concerns when working on the patches

<ekr> dsr: are you going to take over scribing? I don't mind doing it for a but, but I have to leave for about 45 min in about 20

<ekr> thanks

<scribe> scribenick: dsr

Brad: we are a little bit over the time for the introduction, most of the rest of this morning we are committed to joint work, and Anne is comming here at around 10am

Brad runs through today's agenda.

<scribe> agenda: http://lists.w3.org/Archives/Public/public-webappsec/2011Oct/0007.html

<stpeter> discussion on tooling

<stpeter> usually specs are in CVS

<ekr> ACTION: bhill2 get brandon CVS access. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action04]

<trackbot> Created ACTION-2 - Get brandon CVS access. [on Brad Hill - due 2011-11-07].

<stpeter> oh, dsr is scribing, let me know how I can help :)

<ekr> ACTION: bsterne to move CSP to CVS from Mercurial. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action05]

<trackbot> Created ACTION-3 - Move CSP to CVS from Mercurial. [on Brandon Sterne - due 2011-11-07].

<stpeter> abarth notes that there are a lot of CSP versions out there on the web

<stpeter> Brandon can do that

Adam: a lot of developers have trouble finding the latest version of the spec for CORS (?)

<stpeter> dsr: s/CSP/CORS/ :)

<stpeter> er

<stpeter> other way around

<ekr> ACTION: bsterne to seek out all old CSP drafts and point them to the new verison [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action06]

<trackbot> Created ACTION-4 - Seek out all old CSP drafts and point them to the new verison [on Brandon Sterne - due 2011-11-07].

<stpeter> this is about CSP

<stpeter> ekr: the thought is to have fortnightly calls

<stpeter> bhill2: we need to find times that are least painful

Brad: points people at the reverse side of the scribe cheatsheet where you can see the timezones for Berlin, San Jose, Seoul and Beijing. There are no good times for calls, so lets try to pick the least painful.

Thomas: let's see who expects to participate in calls?

<ekr> ACTION: ekr to set up a doodle for selecting a time for calls. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action07]

<trackbot> Sorry, couldn't find user - ekr

<ekr> ACTION: erescorla to set up a doodle for selecting a time for calls [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action08]

<trackbot> Sorry, couldn't find user - erescorla

<ekr> ACTION: erescorl to set up a doodle for selecting a time for calls [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action09]

<trackbot> Created ACTION-5 - Set up a doodle for selecting a time for calls [on Eric Rescorla - due 2011-11-07].

<ekr> I finally know my own username

A show of hands suggests that around 6 people plan to regularly attend calls.

Adam: for some W3C drafts there is a problem that the latest published draft is often out of date.

Brad: this is a question for the editors for decide how frequently that want to push the editors draft out as a public WD.

Thomas: publish at least every 3 months, but perhaps not when the content is changing very rapidly. The pub WD can link to the editor's draft

Brad displays the CORS editor's draft from 30 Sep 2011

<stpeter> Anne arrives

Anne arrives and introduces himself

<stpeter> CORS implementation...

Anne: CORS is pretty much done and implemented in 4 perhaps 5 browsers

<stpeter> widely deployed and shipped (Adam says IE has a subset of it)

A test suite is however still lacking.

<stpeter> Anne: there is no test suite

We need that to move forward.

<stpeter> Anne: we need a test suite in order to move forward

Brandon: is anybody driving the UMP proposal or has it fizzled out?

Anne: Tyler and Mark Miller.

One thing the UPM folks want to avoid is leaking credentials across origins.

Brad: what about test suites?

Anne: it has been pretty much ad hoc to date, but is getting a little better

It is not so clear how much you can do without the html image element.

<stpeter> Adam: seems fine to use an API to test this

Adam: it is fine to say you should use a given test API

cites the webkit solution

Anne: we may be able to use some work from within Opera, I will ask

[ CORS editor's draft: 30 Sep 11 -- http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html ]

Thomas: is the an issue list for CORS?

<stpeter> masinter: would be nice to have a test suite for MIME sniffing, too

<bhill2> ACTION: bhill2 to set up testing mailing list [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action10]

<trackbot> Created ACTION-6 - Set up testing mailing list [on Brad Hill - due 2011-11-07].

<bhill2> ACTION: bhill2 to set up mecurial repo for test cases [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action11]

<trackbot> Created ACTION-7 - Set up mecurial repo for test cases [on Brad Hill - due 2011-11-07].

<bhill2> ACTION: bhill2 to coordinate with phillipe or mike @ w3c on testing infrastructure [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action12]

<trackbot> Created ACTION-8 - Coordinate with phillipe or mike @ w3c on testing infrastructure [on Brad Hill - due 2011-11-07].

<stpeter> Anne: not sure if redirect handling is implemented

<stpeter> Anne: other thing holding up CORS is generic complaints about the model as a whole

<stpeter> Anne: objections are both aesthetic and architectural

<stpeter> Anne: e.g., some people don't like the header names

<stpeter> Anne: I think we've addressed most of the concerns to the extent possible

<stpeter> TLR: documenting those concerns and give people a final chance to object against resolutions would help

<stpeter> Anne: from WebApps side, what is the best discussion venue?

<stpeter> bhill2: any concerns with effect of CORS on sandoxed resources?

<stpeter> bhill2: are there cases where unique origins do not transofmr to null? (e.g., data: URL)

<stpeter> bhill2: we might want to look at how this intereacts with CSP, too

<stpeter> (scribe is not capturing everythere here, sorry)

<stpeter> abarth mentions previous proposal to assign a long random string to each origin (was discussed on WebApps list)

<stpeter> masinter: so it would seem

<stpeter> abarth: currently forbidden to do * and with-credentials -- would it make sense to allow this for applications that know what they are doing?

<stpeter> masinter: it sounds like we need to document an issue with CORS and caching

<stpeter> masinter: i.e., what you could do and what the tradeoffs are

<bhill2> ACTION: abarth to document interactions between CORS and caching / vary header and best practices [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action13]

<trackbot> Created ACTION-9 - Document interactions between CORS and caching / vary header and best practices [on Adam Barth - due 2011-11-07].

<stpeter> another question about "is UMP alive or dead?"

<stpeter> bhill2: we have an action item to follow up with proponents

<bhill2> ACTION: bhill2 to invite mark miller and tyler close to join WG, comment on UMP [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action14]

<trackbot> Created ACTION-10 - Invite mark miller and tyler close to join WG, comment on UMP [on Brad Hill - due 2011-11-07].

<bhill2> PROPOSED: (masinter) That this WG track and ensure that cross-refs to this WG's specs from other areas are correct

<stpeter> I referenced both http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05 and http://tools.ietf.org/html/draft-hammer-webfinger-00

<bhill2> RESOLVED: WG shall work to ensure that cross-references to this group's deliverables by other specs are present and correct

<stpeter> masinter: if other specifications want or need to reference the output of this WG, those are part of the requirements from our "customers"

<bhill2> ISSUE: anne to harmonize header spec with OWS / new definitions in HTTP work @ IETF

<trackbot> Created ISSUE-1 - Anne to harmonize header spec with OWS / new definitions in HTTP work @ IETF ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/1/edit .

<stpeter> anne: Content-Type currently a "simple" header

<bhill2> ISSUE: check for simple/standard request needs to check what the value of content-type header is to determine CORS request type

<trackbot> Created ISSUE-2 - Check for simple/standard request needs to check what the value of content-type header is to determine CORS request type ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/2/edit .

<bhill2> ACTION: Anne to document content-type header values that influence determination of simple / non-simple CORS request type [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action15]

<trackbot> Created ACTION-11 - Document content-type header values that influence determination of simple / non-simple CORS request type [on Anne van Kesteren - due 2011-11-07].

<JEFFH> test

<bhill2> RRSAgent draft minutes

<bhill2> EKR has proposed we swap rooms with the Web RTC meeting after lunch, any objections?

<bhill2> (they are too cramped, but their room could accomodate our numbers)

<bhill2> we are retaining original room

<scribe> scribenick: dsr

Brandon: we have an implementation of spec, there are some minor changes pending, but I don't see any blocking issues to moving the spec forward.

Brad: let's see if we can resolve the immediate questions and get the document out after tomorrow's meeting.

Adam: we would like to include some examples and tutorial stuff to help developers.

There are somethings to discuss, but these can wait until after publication as a first public working draft.

Brad: it seems that Microsoft are looking at CSP, so we may even have two and a half implementations.

Hopefully Microsoft will attend tomorrow and can tell us more.

Brandon: the externalization of JavaScript is a problem for many websites. It is a non-trivial amount of work - there is pain.

No clear way to short cut this, other than putting out implementation guides.

Adam: if people start with CSP it proves to be much easier.
... if you move the policy from the header and put it in an HTML meta element that could help.

Peleus: how about sites using content from various different places?

Adam: there are some tools that help to visualize just what is going on.
... attackers can insert elements with ID's that clobber other scripts.

Brad: there is precedent for W3C to describe security guidelines for specific specs.

Adam: Eduardo describes a way of using JSONP by attackers to get your script to call something on an attackers site.

Brad: developers say JSONP is everywhere and they would like a way to use it safely.

Brandon: with JSONP you are making complete trust in the website you are calling.

Eric: this is people who should have been using CORS, but are stuck with JSONP.

Adam: we can tell them, but the impact for these developers of switching is too high.

<bhill2> ISSUE legacy apps make heavy use of JSONP interfaces that are unlikely to be replaced by CORS - how to enable secure use of this?

Adam: we suggest using CORS together with JSONP when appropriate.

Brad: this still involves some changes to their code.

<bhill2> abarth: hacky way is to pull content, see if it parses as JSON, and assume it could've been loaded via script src= anyway

Brad: if you using iframe and postmessage you can build a sandbox

<bhill2> abarth: perf issue there, two requests for one piece of data

Brad: would it make sense for CSP to cover a solution for that?

Brandon: CSP requires site participation

Brad: not really
... we want support for CSP to degrade gracefully. we wouldn't want to add jsonp-src instead of script-src to get the benefits of a more strict parsing mode?

Brandon: I would prefer to leave this out of the document at least for now.

Eric: yeah, this sounds like a science project ....

Brad: I agree with Brandon that we need strong interest from developers before including it.

Brandon: each time colleagues come back from OWASP they bring an idea for a new feature for CSP.

Adam: once we finish version one, we should open the floor for new ideas.

There could be a period of experimentation, academic papers etc. and the good ideas would filter down.

Brandon: there would need to be really compelling stories for adding anything into version one at this point.

<ekr> I feel like this is document should be subtitled "Provide Adam Barth with a 2013 research agenda"

Brad: agree with moving quickly on publishing v1.0 for CSP. What about content sandbox issue, though?

some discussion about legacy browsers and content sniffing, e.g. thinking the content is HTML and just inserting it anyway.

Brandon: what other types of content might you want to render in a sandbox?

Adam: SVG
... this sounds like something for 1.1, and we should iterate quickly.

Eric: can we all agree on an algorithm for making the 1.0 cut?

Adam: thinks that are implemented in Gecko

Brandon: I would change that to in gecko or webkit

Peleus: happy with that provided there is wording on future extensibility

<bhill2> ISSUE: How to handle directives that are not understood in v 1.0

<trackbot> Created ISSUE-3 - How to handle directives that are not understood in v 1.0 ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/3/edit .

Adam: I am super excited about extensibility. I would suggest that if your process sees a directive it doesn't understand, it should ignore it.

<bhill2> ACTION: abarth to document lack of critical semantics on policy directives, behavior on unknown extensions or new directives [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action16]

<trackbot> Created ACTION-12 - Document lack of critical semantics on policy directives, behavior on unknown extensions or new directives [on Adam Barth - due 2011-11-07].

<bsterne> https is also allowed://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#other-user-agent-considerations

<ekr> ACTION: abarth to create a wiki page for soft registrations of directives people are experimenting with [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action17]

<trackbot> Created ACTION-13 - Create a wiki page for soft registrations of directives people are experimenting with [on Adam Barth - due 2011-11-07].

<bhill2> RESOLVED: Without unanimous consent, no directives without an extant implementation will be included in CSP version 1.0

<bhill2> (as of 10/31/2011)

<bhill2> bhill2: move to call for comments in anticipation of FPWD for CSP following incorporation of minor edits resolved tomorrow

Eric: how soon can we have a CSP 1.0 document ready for publication?

Brandon: we should go over the list of issues first. There is also some editorial feedback to look at.

Jeff: the spec could do with some rewording to make it easier to understand

this is more than trivial editorial change

Brad: how about two weeks to get it ready?
... why don't you remove the proposed directives session if the editors don't object.

Brandon: I will do that right now.

Eric: why don't you do that and we can issue a call for comments with a deadline of next Tuesday

<ekr> ACTION: bsterne to remove proposed directives and make any urgent editorial by COB tomorrow. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action18]

<trackbot> Created ACTION-14 - Remove proposed directives and make any urgent editorial by COB tomorrow. [on Brandon Sterne - due 2011-11-07].

<ekr> ACTION: erescorl and bhill2 to issue a call for comments before an FPWD to last one week tomorrow COB [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action19]

<trackbot> Created ACTION-15 - And bhill2 to issue a call for comments before an FPWD to last one week tomorrow COB [on Eric Rescorla - due 2011-11-07].

<ekr> PROPOSED: Move LC to February 2012 and CR to April 2012

<ekr> PROPOSED: PR June 2012 and Rec July 2012

<ekr> ACTION: anne to update the milestones with dates he feels comfortable with [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action20]

<trackbot> Created ACTION-16 - Update the milestones with dates he feels comfortable with [on Anne van Kesteren - due 2011-11-07].

<ekr> ACTION: bhill2 to add 1.1 as an item on the WG page. [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action21]

<trackbot> Created ACTION-17 - Add 1.1 as an item on the WG page. [on Brad Hill - due 2011-11-07].

Plans to update working group page to indicate change in schedule.

<bhill2> FYI: tracker is at: http://www.w3.org/2011/webappsec/track/actions/open

<bhill2> ACTION: bhill2 to round-trip decision on sandboxing in CSP to WHATWG [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action22]

<trackbot> Created ACTION-18 - Round-trip decision on sandboxing in CSP to HTML WG [on Brad Hill - due 2011-11-07].

<bhill2> bsterne: workers are created from a script, this script must conform to the script-src directive

<bhill2> bsterne: XSLT stylesheets must conform to the script-scr directive

<bhill2> bsterne: any content added by XSLT application must be subject to original document's policy

<bhill2> bsterne: technically XSLT creates a new document, the CSP policy of the TEMPLATE is retained by the document that is the result of the transform

<bhill2> abarth: SVG as IMG should not be active content, if it is that is a defect of SVG, not something to be fixed with CSP

<bhill2> abarth: if loaded via object, same as plugin policy

<bhill2> bsterne: top level load of SVG? will have its own CSP header

<bhill2> abarth: what about object pointing to HTML?

<bhill2> ... does that get frame-src or object-src applied to it? or either?

<bhill2> ... we should clarify in the spec

<bhill2> ACTION: abarth to clarify policy applied for html loaded via object tag [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action23]

<trackbot> Created ACTION-19 - Clarify policy applied for html loaded via object tag [on Adam Barth - due 2011-11-07].

<bhill2> bsterne: investigate behavior for inline svg

<bhill2> bhill2: need a test case for this probably

<bhill2> bhill2: research on SVG as XSS source for reference/background : http://www.slideshare.net/x00mario/the-image-that-called-me

<bhill2> bsterne: how to restrict plugins with no URI / origin, e.g. gears

<bhill2> abarth: include such local extensions as part of the origin 'self'

<bhill2> ... so plugin-src = none will disallow, * or self will allow

<bhill2> peleus: for edge-case plugins, not for flash

<bhill2> abarth: more about extensions that add capabilties

<bhill2> bsterne: consider adding a way to make policy more granular wrt: plugin loading, to specify mime-times in addition to origins

<bhill2> abarth: e.g. allow flash, but disallow java

<bhill2> erk: for 1.1 at least, how to determine mime-types

<bhill2> bsterne: must be compatible with current object-src directive

<bhill2> bsterne: on topic of policy intersection, existing mozilla documentation describing an algorithm for this has been left out

<bhill2> jeffh: for header + meta

<bhill2> bsterne: or for multiple headers

<bhill2> abarth: thought first policy wins should be algorithm on first encountering this

<bhill2> bsterne: use case is edge load balancer or WAF applying additional policies on top of developer-supplied policy

<bhill2> bsterne: proposal is to say that anything that violates any policy is blocked

<bhill2> ekr: options: first policy wins, or strict AND, or define an intersesction algorithm

<bhill2> abarth: strict AND puts pressure on future to never add "positive" directives to CSP

<bhill2> abarth: preference is first policy wins, second is AND, anything more complicated is vastly less preferred

<bhill2> general agreement that complex intersection is not desired

<bhill2> ekr: are there opptys for injection of weaker policy to win?

<bhill2> abarth: examples exist with anti-XSS filters being injected to nuke protective scripts, e.g. framebusting

<bhill2> abarth: blocking is not always security-positive

<bhill2> abarth: can be made safer by only accepting meta tags in the HEAD, e.g.

<bhill2> bsterne: FF will never try to intersect a META with a header

<bhill2> bsterne: and first META tag wins

<bhill2> bsterne: FF is: AND of headers with no META, or the first META tag only if no headers

<bhill2> abarth: complexity budget is spent, keep it simple

<bhill2> ekr: can we resolve now?

<bhill2> bsterne: don't think so, no iron clad preferences, but prefer to wait for CfC to see if any other implementors (esp. site owners) have preferences

<bhill2> ISSUE: solicit for input on policy intersection / conflict resolution

<trackbot> Created ISSUE-4 - Solicit for input on policy intersection / conflict resolution ; please complete additional details at http://www.w3.org/2011/webappsec/track/issues/4/edit .

<bhill2> topic is back to csp issues

<bhill2> bhil2: can we save header policy as a meta tag?

<bhill2> abarth: not going to work well due to repackaging of dependent resources

<bhill2> bsterne: don't re-write or save things that got blocked

<bhill2> bsterne: hard thing is same origin restrictions for scripts, etc. how to deliver behavior that site expected when it was online

<bhill2> abarth: another approach to saved content is to take out all scripts, but doesn't work well

<bhill2> abarth: best to take it out of scope, document in security considerations

<bhill2> bsterne: agreed with abarth

<bhill2> bsterne: will add security considerations indicating no expectation of security in a local disk context

<bhill2> bhill2: how to work for apps intended to be started locally

<bhill2> abarth: put in metadata blob specific to app delivery mechanism, no need to specify as part of CSP

<bhill2> abarth: coordinate with widget activity on where to put policy

<bhill2> abarth: CSP is great for this due to low cost of out-of-line delivery of script resources

<bhill2> ACTION: bhill2 to liason with widgets activity on policy placeholder for widgets [recorded in http://www.w3.org/2011/10/31-webappsec-minutes.html#action24]

<trackbot> Created ACTION-20 - Liason with widgets activity on policy placeholder for widgets [on Brad Hill - due 2011-11-07].

<bhill2> bsterne: next item: should navigation of documents in a frame be subject to parent document's original restrictions?

<bhill2> bsterne: think that mailing list discussion resolution was yes, restrictions should be applied

<bhill2> bsterne: this includes user-initiated navigation

<bhill2> peleus: could this be used to break framebusting code in an iframe?

<bhill2> abarth: usually navigates to _top, not to different origin

<bhill2> bhill2: can break framebusting with iframe sandbox anyway

<bhill2> bhill2: top-nav and popups are not subject to this restriction?

<bhill2> bsterne: no, top-nav, popups do not inherit restriction

<ekr> mikesmith: I'm with W3C...

<ekr> recently launched a new activity (testing activity)

<ekr> wilhelm: co-chair of testing interest group

<ekr> ... we're looking at how people test. trying to standardize some different formats so it's easy to make tests portable

<ekr> ... standardizing web driver API which is an API for telling browser what tod o do

<ekr> ... can be used to automate a lot of different tests

<ekr> ... have some examples. about to show them

<ekr> mikesmith: in the meantime will talk about a system to let anyone run a test suite to let them run tests in their browser.

<ekr> ... allows you to get aggregated data from users about whethe tests work across different browsers

<ekr> bhill2: kinda like browserscope

<ekr> mikesmith: yeah

<ekr> ... test cases are HTML + some JS

<ekr> ... testharness.js allows success/fail detection automatically and auto runs the tests and submits the results

<ekr> ... we prefer that if you can you use testharness.js

<ekr> Wilhelm showing example.

<MikeSmith> http://w3c-test.org/resources/testharness.js

<ekr> wilhelm: a bunch of assert macros

<ekr> wilhelm: trivially easy to use.

<ekr> abarth: does this allow you to generate synthetic headers

<ekr> wilheml: you'd need to talk to a server you control

<ekr> ekr: compare to qunit?

<ekr> wilhelm: more tailored

<ekr> ekr: what about asynchronous

<ekr> wilhelm: yes, that works

<ekr> wilhlem: some cases where you have to do manual stuff

<ekr> ... language bindings for a dozen different languages

<ekr> ... (this is now simulating user input to browser)

<ekr> ... some browser-specific tests

<ekr> mikesmith: w3c runs the server so you can put stuff on it.

<ekr> ... it runs PHP

<ekr> mikesmith: adding support for websockets.

<ekr> philippe: yes

<ekr> abarth: webkit has a ton of tests we are willing to contribute

<ekr> abarth: how do you test that something didn't happen

<ekr> wilhelm: set a variable?

<ekr> bsterne: this isn't great in gecko either

<MikeSmith> mailing list for discussion about common testing needs/issues - http://lists.w3.org/Archives/Public/public-test-infra/ public-test-infra@w3.org

<ekr> abarth: there's some guy with a large test suite that I can probably dig up

<MikeSmith> http://lists.w3.org/Archives/Public/public-browser-tools-testing/

<MikeSmith> public-browser-tools-testing@w3.org

<ekr> mike smith: there's a new working group for the web driver API

<ekr> bhill2: is there a yardstick for testing quality before advancement

<ekr> mikesmith: we don't take a position on this. convention is two implementations that pass a test case.

<ekr> mikesmith: right now this has a hard-coded "two implementation" rule

<ekr> draggett: distinguish optional from mandatory features

<ekr> mikesmiht: not enforcing any test case quality standards

<ekr> mikesmith: there's a review case process for test cases. currently in HTMLWG we have separate folders and the approved test cases go in approved

<ekr> ... in the case of HTMLWG we have submission/ that does the obvious thing

<ekr> ... one of the things we want to do with the IG is write up best practices about how to do stuff

<MikeSmith> mike@w3.org

<ekr> ... if you want to start adding test cases, you need maintainer access. just write me

<ekr> ... need to flag test suites which are required for a WG

<ekr> ... it's not terrifically stable; having machine problems

<ekr> ... we do back up the DB

<ekr> abarth: can you use mercurial

<ekr> mikesmith: yeah, we can do that

nickscribe: dsr

scribenicj: dsr

<scribe> scribenick: dsr

Brandon: first is the report format, currently spec as JSON, but will be redone as form encoded.

the second is the blocked URI field in the report should be restricted to just the origin of the blocked URI if it is a cross origin violation

this isn't controversial, so I will just make that change.

We decided to scapt the DOM event.

s/scapt/scrap/

Adam: I am willing to give up on the form encoding and just go with JSON instead

Brandon: I have a couple of things. One Adam identified today: should violation block loading of content, I kind of think it should.

should read should blocked content fire an event that the page can see.

Adam's example: if an image fails to load you get an error event, similarly we should define events for other content.

the failure of loading the image could be due to CSP, or network problems or ...

Brendan: Adam has already created a fix so that bookmarklet's work even for a page with CSP. Previously the bookmarklet was treated as part of the web page and blocked with its policy.

Adam's fix was to hook into the navigation ...

Adam: the spec doesn't need to explain the implementation, just to say that bookmarklets should work.
... issue about the policy URI. Slow.

Brendan: only slow for the first time.
... okay leave this as an open issue.

Brad: some implentors may find it easier to maintain the policy at a location pointed to by the URI rather than embedding the policy in the headers.

Peleus: this is a benefif of the Flash security policy file.

s/benefif/benefit/

Brad: perhaps we should including a performance warning in the spec.

Brendan: Mozilla wants to make ensure that if http is allowed then https, likewise for websockets and websockets over TLS.

Are there any cases where this isn't appropriate?

Adam: maybe one way to handle this is to allow people to add the protocol scheme to the location. Then http implies both, whilst https is restricted to just http over TLS.

The http and https could be run on different servers, e.g. with user content on the https server making it a bigger target for attackers.

Eric: it is kind of odd having http scheme implie https

s/implie/imply/

Brandon: the no scheme implies both for a CSP source, explicit schemes don't

Adam: agrees
... I think we really want star to mean everything.

Brandon: I hadn't intended that and we should make that explicit in the spec.

If you only want star you can't whitelist schemes.

Eric: if you want to say any URI with https?

Adam: you would write "https:" that is supported by the grammar.

Brendan: I could definitely live with star meaning any scheme, any host or any path

s/path/port/

Brendan: we currently say that if no port is specified you use the port of the page.

s/port of the page/default port of the protocol scheme/

<bhill2> members should review JeffH's comments at: http://lists.w3.org/Archives/Public/public-web-security/2011Mar/0039.html

<bhill2> agenda adjustments for tomorrow:

<bhill2> 10:00-11:00 block will be used to revisit any last calls for inclusions in v1.0 FPWD

<bhill2> 13:00-onward block will be used to discuss Secure Cross-Origin Framing and Mashups charter item

<bhill2> bhill2 will send out updated agenda so remote participants can join at appropriate times

Discussion about new directives.

The webappsec WG will standardize these.

Brad: do we want a means to black list new features

Adam: this sounds like something to discuss for 1.1

Brad: the browser vendors here are on short release cycles, but others are on a much longer release cycle and may only implement 1.0 and take a long while to move on to 1.1

Discussion about unspecified concerns e.g. by OWASP about new HTML5 feautures including web sockets.

Brad: we want to avoid a long delay between the discovery of a new attack and the ability to deal with it using CSP.

We could make use of black lists for this, e.g. to disallow injection of specific tags.

brendan: this is clearly not in scope for 1.0, despite being something that some people were hoping for.

Jeff mentions the discussion back in 2010 on white and black lists.

It may be worth taking a second look at that as a lot of the arguments were clearly laid out.

we adjourn for the day

- DRAFT -

WebAppSecWG TPAC 2011 F2F - Oct 31

31 Oct 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output