Web Application Security Working Group Teleconference -- 16 Mar 2015

<trackbot> Date: 16 March 2015

<ekr> Zakim is fighting with me

<bhill2> 92794

<ekr> yeah, I ended up being hung up on

<ekr> [Mozilla] has ekr

<rbarnes> o hai

<deian> Zakim: aacc is deian

<ekr> zakim: who is here?

<bhill2> scribenick bhill2

<deian> i can do it

<deian> charter revieerd by the advisor committee. it was approved by by the AC. there was formal objextion by mozilla. we're trying to resolve that today. one issue was on the decisions process that was resolved. the second portion was the deliverable for COWL and concern that it was not clear enough. the charter language was updated and we have prototype implementation

<deian> bhill2:^

<rbarnes> who is speaking?

ekr: question is about side-channels, not about whether you can write software if you pretend side-channels don't exist.

deian: not exposing any new covert channels.
... only adding flow-control to overt channels.
... still enforcing csp, etc.
... want to close overt channels.
... give developers control, not remove risk of side-channels.

ekr: reading the text, says "untrusted code", core of the problem.
... "untrusted" => covert is in scope.

deian: sure. we can change that.

ekr: what you just said is fine, text doesn't reflect it.

<ekr> Deian had proposed "untrusted, but not malicious."

<ekr> That's probably not quite the language I would use, but I can live with it

<deian> bhill2: next up was epr. updated the text to address comments. no objection on this. consensus

<deian> ekr: thanks :)

bhill2: (moving to priviliged context)
... (read text of charter)
... meeting with Mozilla and TAG.
... following that meeting, dropped normative requirements for the definition of "powerful features"
... work with TAG, provide advice, decisions are decisions for other WGs.
... TAG, as elected body is better placed to review those decisions.
... (in a wind tunnel)
... (not in a wind tunnel)
... met with TAG. advice is non-normative, encourages WGs to consider privacy impact of delivering certain features over plaintext.
... leaves decision in the hands of WG and ultimately TAG.
... joint-deliverable with TAG.
... spirit of the spec dictated by TAG, not crazy security folks like Mike. Who is crazy.
... anyone interested in addressing concerns to the group?

rbarnes: to clarify, the current concerns are:
... the concern with charter language around "advisory".. in IETF, regardless of non-normativity, there's a tendency for those to be treated as gospel.
... target we're going for is really to change the focus away from recommendations as to what should be in or out.
... focus on examples where decisions have been made.
... WebCrypto, getUserMedia.
... had discussions, made decisions.
... tradeoffs. compatibility, security.
... rather than presuming to make decisions, better to discuss past discussions as examples.
... at charter-level, recommend moving from 'non-normative advice' to examples we've learned from the in past.

ekr: rbarnes represents the concerns well.
... been through one round of this style of analysis being used to force groups to do certain things.
... our experience is that non-normative and normative language are similar.
... 33 seconds from "this is non-normative" to "this is good advice, why not make it normative?"

mkwst: if it is good advice, why not make it normative?

ekr: to be frank, concern is that
... as bhill2 suggested, meta-concern is that self-appointed group of security experts decided to dictate to the w3c.
... means everyone has to pay attention to it.
... i think it's bad advice.

<bhill2> mkwst: if it is good advice, why shouldn't people pay attention to it?

rbarnes: maturity of discussion issue here.
... no consensus about the right box of advice, set of rules to cover large set of cases.
... high confidence that we'd think the same things about specific examples.
... subtle exercise to deal with future cases.
... not at a point right now to wrangle about where we recommend use of priviliged contexts.
... focus on defining priviliged contexts instead.

bhill2: should consider rules inside context of W3C.
... non-normative text isn't normative, per charter.
... explicitly reserved for WGs and review by TAG.
... charters voted on to define those scopes.
... not a handwave away. redefine charter. 18month window.
... unlimited debate? my reading of concensus is that this WG and the TAG both want that debate.
... should think about the security concerns. not endless, but should think about them.
... other WGs want that advice.
... ehard specifically from geolocation working group.
... reevaluating their choice, want advice, want that thought process.

bjill2: process by which reviews happen, standing to make review, working groups or TAG.

bhill2: not in the same boat as IETF, no process without end.

rbarnes: i don't think that what you're proposing we develop is somethig i'd disagree with.
... provide tools for others to make decisions.
... see the word "recommendations", think "decision". in case XYZ, you should do A.

bhill2: a "recommendation" is what the W3C calls "specification".

rbarnes: "non-normative advice"?

bhill2: feel like we've met the sprit of the objection more than halfway.

rbarnes: rephrase as soemthing like "provides notes, considerations, things to be taken into consideration"?
... that phrasing would make me more comfortable.
... happy to provide text.

bhill2: can you live with this text?
... waited 3 months. filed objection last day.
... refused to work on the list. didn't show up to the TAG call.
... gone through consensus process with community.
... hesitate to extend this process even longer if we're that close.

dveditz: this is just _charter_ text. spec text can be argued with.

ekr: didn't refuse to engage. david was on the TAG call.

bhill2: specifically invited to join the mailing list. primary work mode.
... obligation to take changes back to stakeholders. would like to know if you can't live with this, given knowedge of the W3C's rules.

ekr: happy to engage on the mailing list.
... acrimonious in the past, thought better to do it live.
... wouldn't suicide.
... also wouldn't withdraw formal objection.
... doesn't take long to circulate question on the list.

rbarnes: process?
... pretty small, pretty specific change to the text.
... can provide specific words.
... whats the process implication of the text change?

bhill2: depends. engaged with the tag, went back to the list with that compromise position.
... specific desire on the part of the TAG and this group to provide advice. not normative or definitive, but should provide advice.
... this would meaningfully walk back the intent to encourage discussion and advice that's the standing consensus of a large number of stakeholders in this process.
... can't just change overnight without going back through and reengaging those stakeholders.

rbarnes: what would be the concrete action to resolve this change?

bhill2: not convinced that anyone but you and ekr want this change.
... not convinced resolving the objection would represent consensus.

ekr: pretty clear process for that case.

bhill2: are there other folks on this call who are in agreement with this change?

dveditz: unclear as to what words that have been spoken are those for this change.

rbarnes: non-normative advice -> examples and considerations(?) (help me here rbarnes)

<bhill2> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html

rbarnes: would mean revising doc, more for tone.

<bhill2> https://w3c.github.io/webappsec/specs/powerfulfeatures/

<bhill2> https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege

<bhill2> <- currently has no RFC2119 language at all

<bhill2> no SHOULD, no MUSt

<terri> I don't see an "algorithm" here: https://w3c.github.io/webappsec/specs/powerfulfeatures/#feature-requires-privilege

<bhill2> mkwst: there are broad categories, not an algorithm

<bhill2> ... in fact, most categories are defined with the help of examples

<bhill2> ekr: some of these examples are currently available in insecure contexts and will only be changed slowly if ever

<bhill2> mkwst: not sure why the particular words you want are more or less problematic than the other

<bhill2> ... the existing language does not give this group any power to dictate to any other group

<bhill2> ... explicitly delegates it to the TAG which does have the moral standing to give advice to other groups

<bhill2> rbarnes: in IESG today, any kind of "this thing should be that thing" makes it difficult to say "this thing should not be that thing"

<bhill2> mkwst: not convinced there is significant support for your position in this group or TAG

<bhill2> rbarnes: what is helpful is providing other groups with the tools to make better decisions.. they know their features better than we do

<bhill2> ... more productive to provide a toolset

<bhill2> mkwst: don't we need to give those groups a context to make their decisions in?

<bhill2> ... it is our role as members of WebAppSec and W3C to help groups understand the context in which they are working and the impact of the features they are creating that may not be visible if focused only on the feature itself

<bhill2> rbarnes: really important to have security considerations covered and input from security community into any given feature

<bhill2> ... if you look at documents in IETF, they don't see this is secure, this is not, they say these are the things to keep in mind when writing your security considerations section

<bhill2> rbarnes: not comfortable with language that says "the conclusion you should reach is..."

<Zakim> wseltzer_, you wanted to comment on timing

<bhill2> plan for course of ACTION:

<bhill2> EKR and RBarnes to draft a proposed change to public-webappsec and tag mailing list, seek expressions of support

<bhill2> these will be considered in reviewing the charter with the Director for determining the shape of consensus

- DRAFT -

Web Application Security Working Group Teleconference

16 Mar 2015

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output