See also: IRC log
<trackbot> Date: 15 December 2014
<bhill2__> zakim aaaa is bhill2
<francois> zakim aabb is francois
<jww> Zakim aacc is jww
<bhill2__> zakim insists on correct punctuation
<bhill2__> scribe volunteer?
<bhill2__> Meeting: WebAppSec Teleconference 15-Dec-2014
<bhill2__> Chairs, Bhill2, Dveditz
<bhill2__> Scribenick: bhill2_
<bhill2__> http://www.w3.org/2014/11/17-webappsec-minutes.html
<bhill2__> No objection to unanimous approval of prior minutes.
<bhill2__> http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0056.html
<wseltzer> +1
<bhill2__> whoever just joined from aaee can you please mute?
<bhill2__> bhill: any interest from others in adding a strict mode for subresources to mixed content?
<wseltzer> [publishing moratorium: 19 December through 5 January 2015 ]
<bhill2__> ... twitter and facebook would like this
<bhill2__> mkwst: we have time given publication break to work on this, so no objections
<bhill2__> dwalp: we have folks on vacation, can we respond first week of 2015
<bhill2__> wseltzer: W3C publication break is 19-Dec to 5-Jan
<bhill2__> ... and +1 to the feature
<bhill2__> mkwst: work trying to hammer this out, many people are out of office, target mid-January for a CR seems reasonable
<bhill2__> wseltzer: where are we in process transition?
<bhill2__> bhill: on linst we seemed to agree on continuing to have an informal LC process, but it isn't part of W3C formal steps anymore regardless
<bhill2__> http://www.w3.org/TR/powerful-features/
<dveditz> bhill2__: this is a new spec we’re taking on, but pretty much all the features were formerly in MIX
<dveditz> bhill2__: new working draft triggers a new call for exclusions (see group calendar on our homepage)
<bhill2__> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html
<dveditz> … we’ve had a new charter up for review for a few weeks now
<bhill2__> bhill: feedback from lawyers at Facebook that this was not a bad thing but was outside the narrow IPR scope of this group so far
<bhill2__> bhill: proposed a compromise to accept it, but keep it tightly scoped to JS API only
<bhill2__> dveditz: ambivalent, agree it is useful but somewhat outside our group's current scope, happy to accept it with proposed changes
<bhill2__> dveditz: hearing no objections...
<bhill2__> dev: seems like a very long list
<bhill2__> dveditz: some of those pieces were broken out of or sprung from existing specs
<bhill2__> mkwst: this takes us through July 2016, it is long, but we have time and new people coming in to do this
<bhill2__> ... not a bad thing to bring in new things with people to do them
<bhill2__> bhill: yes, part of earlier consideration was that there are editors to own this new work
<bhill2__> dveditz: some of the dates for new work are fictional
<bhill2__> mkwst: have we hit any dates ever?
<bhill2__> bhill: I pulled those dates out of a hat, if we don't try to hit a date, we'll never make progress
<bhill2__> dveditz: there are some with schedule risk because they are not well defined or have sample implementations yet
<bhill2__> wseltzer: next steps are taking this to W3C management which should go quickly, then polling AC reps to indicate support
<bhill2__> ... and commit resources, this will help us gauge interest
<wseltzer> ACTION: wseltzer to take charter to w3m for review [recorded in http://www.w3.org/2014/12/15-webappsec-minutes.html#action01]
<trackbot> Created ACTION-208 - Take charter to w3m for review [on Wendy Seltzer - due 2014-12-22].
<bhill2__> jww moves to adopt the draft charter
<bhill2__> dev seconds
<bhill2__> dveditz: with no objections, WG unanimously decides to send the charter for w3c management approval
<bhill2__> http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0028.html
<bhill2__> terri: have we talked to the Web of Things CG about this?
<bhill2__> mkwst: we have generally punted IoT concerns out of this group
<bhill2__> bhill: Geolocation group is doing this themselves, we're not driving it
<bhill2__> mkwst: not actually clear that they're doing that - there is a thread, but it is unresolved
<bhill2__> dveditz: some concerns at mozilla if it is mandating or using as examples features that have had their own intense debates about this
<bhill2__> ... to the extent that those groups have made their own decisions, they don't want us to reverse them
<bhill2__> mkwst: we are trying to lay out a framework for deciding what a powerful feature is
<bhill2__> ... personally I feel some groups have made some poor decisions about this
<bhill2__> ... I don't believe that this spec is mandating that specific features be restricted to HTTPS, but that a category be restricted
<bhill2__> ... we can have healthy debate whether a feature falls into that category or not
<bhill2__> bhill: there is also a split in responsibility here between WebAppSec and TAG
<bhill2__> mkwst: we are defining the contours here of what is powerful, would be sad if we didn't try to outline when we think the algorithm should be applied
<bhill2__> mkwst: a good place to focus discussion is on section 3: "Is feature powerful?"
<bhill2__> mkwst: there is still ongoing discussion, and we should put together a new draft in January / February that includes some of these ideas, like subresource vs. navigation policies
<bhill2__> ... this is going to take some time, still some big topics to discuss and decisions to make
<bhill2__> http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0045.html
<bhill2__> bhill: wanted noncanonical-src but ok with a shim
<bhill2__> dev: yes, as version 1, but may still be good in future version
<bhill2__> jww: +1, freddyb is also +1
<francois> also +1 from me
<bhill2__> dev: javascript reporting is painful and not as useful as CSP-style implementation
<bhill2__> bhill: important for an experiment like this to get data from operators and not just implementers
<bhill2__> dveditz: like the idea of a unified w3c reporting uri spec
<bhill2__> ... from a website's perspective, if you are listening and start getting new reports you weren't expecting, that is bad
<bhill2__> bhill: nice for supporting policy evolution to associate each policy with its own endpoint
<bhill2__> dev: but would be great to filter reports in JS
<bhill2__> mkwst: error reporting in the DOM is shippping already
<bhill2__> bhill: do we expose SRI errors in the DOM?
<bhill2__> dev: shouldn't be a blocker for v1
<bhill2__> dveditz: most resources support onError and onLoad events
<bhill2__> mkwst: we did some work in order to avoid information disclosure for hash-guessing
<bhill2__> bhill: retaining room for spec authors and UA implementers to manage information flow here is good defense against malicious resource authors
<bhill2__> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/hJwYZOOPaH4
<bhill2__> jww: some disagreement on whether this is for 3rd-party integrity or integrity without confidentiality
<bhill2__> ... and sub-camps, given one of those threat models, do you care if it's over http or not
<bhill2__> ... would like to hear from application developers on this
<bhill2__> bhill: set of customers who want to use this but have parent resource insecure is small, perhaps null
<bhill2__> mkwst: seems a reasonable intrepretation
<bhill2__> ... hope we can have non-same-origin workers in future and language also makes sense ther