Web Application Security Working Group Teleconference

<bhill2> happy to add that

wseltzer: and "html 5.1" ?

<bhill2> and Mike wanted to discuss possible next F2F?

Bermuda?

Minutes approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2016-01-13-webappsec-minutes.html

<bhill2> minutes approved by unanimous consent

agenda bashing

<scribe> scribenick: dveditz

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0163.html

bhill2: wanted to spend time talking where we are as a group and where we're going
... can also talk about normative references to whatwg specs, a possible next F2F.... anything else?

whoa

<wseltzer> mkwst: 3 visitors from Google's infrastructure security team

work mode

bhill2: in the last year we've focused our calls on individual spec status on a regular basis
... but looking for what to talk about on next calls I see 16 specs "in flight"
... a couple of those are close to CR but most look like they're not making much progress toward implementation/adoption

<wseltzer> Specs in progress

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

mkwst: part of the problem is that we have a lot of specs that are ideas as opposed to solid things people are working on
... such as "clear site data" which we very much want to implement but I'm having trouble finding someone to implement
... and on the other hand we have things that are potentially good ideas that we want to explore, but we don't know. e.g. Entry point regulation
... needs some love in terms of implmementation/experimentation but also discussion about the controversial points
... I agree with the way you framed it, brad, in the agenda in terms of "too many things in flight". But I'd like to resolve that in favor of
... "go faster" rather than "do less stuff". but I do agree having a lot of specs just hanging is not good

bhill2: one of the things happening at W3c is that a lot of groups are moving towards having an "incubator mode" to do the initial exploration
... and only have a formal group when there's already work toward having multiple implementation
... Microsoft has been very supportive of the incubator work mode, for example

teddink: in general microsoft is very supportive of using incubator groups to iterate on things considered to be "good ideas" where there's less pressure from W3C processes, until you have some implementations
... before taking it to the w3c leadership to form a formal standards group

mkwst: I think de facto we /are/ incubating, but we're doing it by publishing working drafts rather than doing it in a separate group
... I'm happy to more explicitly incubate, as we are with CORS-1918 and @@, that are happening in other standards but are discussed here
... but de facto those discussions involve many of the same people so I don't see it as important to make a strict distinction between incubating and standardizing

bhill2: my concern is less that we're weighing the group down--we have a good community--but that we may be weighing down the pipeline of implementors
... what can we do to help guide implementation. I'd rather have 3 specs implemented by multiple browsers than to have all the specs implemented but by non-overlapping browsers

teddink: I like Mike's proposed idea. makes it easier to make those prioritization discussions (internally) if we can point to a group where other vendors have prioritized the same issues

<bhill2> dveditz: At Mozilla, overwhelmed by the number of specs and focusing on what we can do with the people we have

<bhill2> ... a shared sense of prioritization in the group would help us understand that we are working on what others are focused on

<Zakim> wseltzer, you wanted to follow up on mkwst's suggestion re threat model

wseltzer: I like mike's thoughts about describing the threat model that each spec is good at addressing

<bhill2> wseltzer: group could produce threat model document(s) non-normatively and then give reports indicating what specs are relevant and people could give feedback on what is important

<Zakim> mkwst, you wanted to suggest priority queue for features, regardless of spec.

mkwst: noticed in conversation with folks at Google there's discrepancies in implementations between browsers. could be useful to create a prioritization list
... in particular thinking of small things like nonces from CSP2

<wseltzer> +1

mkwst: that would be very useful even if "implement all of CSP 2" is overwhelming

<bhill2> bhill2: a visible priority queue would be useful guidance to other UA vendors who aren't here

wseltzer: I like the way this is developing. espcially if implementors took the prioritization as a list of things there was real "customer demand" for particular features

bhill2: two concrete outcomes are a threat modeling section, and a list of implememntation priorities

<Zakim> mkwst, you wanted to note that the priorities should, ideally, be set by developers.

mkwst: the one thing important: prioritization should come from developers. I have people inside Google saying "I need X" and I'm sure Brad hears from facebook folks

bhill2: something usable everywhere is better than the exact thing I want that only works in one browser

<teddink> I agree as well - web servelopers and large web properties should play a critical role in wjatever prioritization we come up with.

<teddink> Developpers, that is.

bhill2: we could have an anonymous voting system, or one where voters can declare their affiliations, and see if we can come up with a rank order.

mkwst: voting system or not, doesn't matter, but a wiki page we all "kind of agree on" would be useful. don't want to wait to get this going

fetch dependencies

bhill2: let's go to more fun meta work.... normative references to specs outside w3c

"fetch dependencies"

<wseltzer> https://www.w3.org/2013/09/normative-references

wseltzer: one of the fun bits of w3c process we have guidelines for normative references
... looking at the stability of the reference docs, the nature of the dependencies
... inside w3c we have criteria for stability for reaching recommendation status. outside groups may or may not meet those criteria and we have to look at them individually
... in particular we have a lot of specs depending on the "fetch" spec and the director has raised concerns about that -- is it stable and subject to wide public review?
... tim also has some concerns about implementation of some specific fetch features (worry that the CORS interactions aren't very clear to developers)
... worries that may indicate there hasn't been enough public review
... we have multiple specs working through the w3c process that have this dependency. the closest to recommendation status is sub-resource integrity so we have to resolve this

mkwst: as someone who works on chrome, the fetch spec is what we work from regardless of whether it's a normative reference
... if I can't reference the thing I'm actually using in my specs that raises problems
... WHATWG has a renewed vigor in defining HTML, and there's a group in w3 working on HTML. it's clear to me what to do with WHATWG -- I send a pull request. not clear to me how to interact with the W3 group
... this is difficult, but browsers gonna browse -- whichever one we reference the behavior will most closely match what the whatwg is producing at the moment

jochen__: have run into problems with the referrer policy spec where certain things are not specified
... and it seems easier to get that fixed in fetch than through W3c

thx mkwst

wseltzer: we do need to do what developers and implementors need, trying to figure out how to make that better.

bhill2: we want to make progress, to get things completed and done, and the best thing is to use what the browsers are implementing from. that current seems to be the fetch spec. I'd like to make progress producing things for developers to use and not get hung up on political battles

wseltzer: any other implementors want to say something here? I too would like this to move forward

<teddink> I would have to chat with other folks on the Edge team that work on standards before I speak on behalf of Microsoft on this topic.

mkwst: the "secure context" spec might be a good one. depends on fetch but not anything in HTML "5.1", could be a good clean first forcing function

<wseltzer> dveditz: Mozilla is moving toward fetch

<wseltzer> mkwst: if you see things you don't understand, file browser bugs

mkwst: if things are unclear file bugs.... we might need better behavior or better error messages

potential F2F

F2F

bhill2: last topic is potential F2F

<teddink> Microsoft is also doing work towards a fetch implementation

<wseltzer> http://conferences.oreilly.com/oscon/open-source-us May 18-19 in Austin, TX

wseltzer: OSCON is in autin this year... if people are already going there that might be an opportunity

<teddink> I agree - a F2F would be great.

mkwst: I raised the idea of f2f because people inside google wanted to talk to security spec folks and would be good for us

<bhill2> wseltzer: TPAC is in Lisbon in September

wseltzer: TPAC is in lisbon in september this year

<terri> F2F sounds great, but my travel has to be booked a quarter in advance

<jochen__> May 18/19 is also Google IO, dunno how many google folks will be involved in that who also might want to go to the f2f

<wseltzer> [2016 W3C Technical Plenary (TPAC) will be held on 19-23 September 2016 at the Congress Center of Lisbon, in Portugal.]

terri: is May a quarter in advance? or would it have to be after June?

<wseltzer> https://www.w3.org/Consortium/Recruitment/#security-engineer

bhill2: thanks everyone. will send out some follow up items offline