Technical Architecture Group Teleconference -- 12 Feb 2015

<trackbot> Date: 12 February 2015

<dka> trackball, start meeting

Powerful Features & such…

<dveditz> thx, wseltzer

OMW

I can scribe

are we doing minutes a new way?

<dka> Scribe: slightly

fair enough.

thanks

dka: just to introduce, something I didn't mention in email is that this is a topic we had been meaning to scheudle TAG time about for a while. We discussed at at LON F2F.

<dka> https://github.com/w3ctag/meetings/blob/gh-pages/2015/telcons/02-12-powerfulfeatures.md

dka: alex, yan, anything to add?

<dka> Alex: on the chrome team we’ve been looking to https for powerful features such as push, service worker, etc… this falls into line with [our thinking]...

dka: yan?

<Travis> Zakim: [Microsoft] is me

yan: alex summarised it

wseltzer: the work that the webappsec group has started up and is good. It's too bad that mkwst couldn't join, but this proposal has seen a lot of discusison on our mailing list. We're interested in discussing it here because of a comment we recieved in charter review.
... a reviewer expressed concern about who should decide when something is powerful; who should restrict this?

<dka> http://www.w3.org/TR/powerful-features/

wseltzer: since the TAG is our design group, it seems the TAG should help decide how to allocate responsibility

<dka> http://www.w3.org/TR/powerful-features/#is-feature-powerful

wseltzer: who looks out for the various interests? (developer, user, browser)

dka: there's a leading statement in the intro about impacting privacy and security
... TimbBL and brad are on the q

timbl: I wanted to comment that it's important to separate "https:" from encryption

<dveditz> dka: that "is feature powerful" section has been substantially rewritten: https://w3c.github.io/webappsec/specs/powerfulfeatures/#restrictions

timbl: I think it's important to encrypt HTTP; confusion about address space and protocol

thanks dveditz; could you q+ to give us an overview of the changes?

dka: this is something we debated at a prior F2F

bhill2: I think wendy did a good job of summarizing, but to provide more context, the spec has 2 sections: is this poweful? and if it is, is the context sufficiently secure?
... we've recieved input from other WGs that they want help specifying the second part and are happy to delegate to webappsec
... addressing timbl's point, there's a concern about authenticating origins
... mozilla has filed a formal objection about the charter language

<dveditz> mnot: I believe it's the one I linked to

bhill2: there's some hope that the TAG could be a formal review board; the hope is that a given group review with the TAG but that webappsec not normatively create language here

<Domenic_> mnot: I think it's https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful

<wseltzer> https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful

<dveditz> and https://w3c.github.io/webappsec/specs/powerfulfeatures/#algorithms would be normative

dka: is the idea that this should be guidance and that this guidance should be self explanatory? Is the idea that the TAG would deal wiht this in cases where there's a dispute?

<mnot> I can see making the question of whether a feature is powerful non-normative; the definition of how powerful features are restricted needs to be normative (i.e., if you say you conform to this spec, it sticks)

bhill2: groups want to make their own decisions about what is "powerful"
... they don't want webappsec making that decision for them

<dveditz> I'm sorry, wendy is correct, #is-feature-powerful not #restrictions

bhill2: but if some on this call thought it was irresponsible, the hope is the TAG might be the right group to make that sort of call

<timbl> This seems to to me to be to be squashing into a one-bit protocol something which is normally a big matrix under the user ’s control

<wseltzer> [bhill said: "is feature powerful" would be non-normative; while "is context sufficiently secure" would be normative]

bhill2: TAG is elected, webappsec is "just another working group"

dka: is there someone from MOzilla here?
... can someone re-interpret/contextualize the objection?

<Domenic_> https://www.w3.org/2002/09/wbs/33280/WebAppSec-Recharter-2015/results

dveditz: I'm a co-chair of the webappsec WG, so am a bit conflicted, deferring to dbaron

<wseltzer> Mozilla's objection

dbaron: I think it has been covered reasonably well. The major concern is that people worried that the experts on a subject being overridden in ways that they couldn't argue tradeoffs about

dveditz: there were some groups, e.g., WebCrypto, who had hard-fought battles and the webappsec group was accused of a power-grab

Domenic_: one thing I'm hoping is that we could have a joint-TAG-Webappsec deliverable to create a rubric
... I think it would be a shame to not have normative language
... jurisdictionally, it seems like the TAG is the right group, but webappsec has the expertise

<timbl> I can see that it may be that it is valuable to separate the defining of the trusted context into a sep spec because othergroups mihgt forget things like e./g. http://localhost/ which are trusted and file:// which is trucsted.

dka: that's interesting. We're working on some joint-deliverable with other WGs
... if there's value on having this as a joint deliverable, It might add more weight

<timbl> Three levels of dealing with trust:

dka: the other question is: is it really possible to have a normative algorithm?
... we can have a definition, but it feels like there will always be edge cases

speaking personally, I agree with dka there

<Domenic_> slightlyoff: having a strong rubric that is endorsed by the tag doesn't necessarily end the debate

<Domenic_> slightlyoff: you still need to figure out what the correct escalation path is

<Zakim> timbl, you wanted to say Three levels of dealing with trust: 1) I trust A. 2) I trust A with infro B. 3) I trust A with info B for purpose C. .. we should be moving the world

<Domenic_> slightlyoff: would like to understand what people who are objecting think the correct group is for the kind of stuff---TAG or not?

timbl: I have yet to be convinced that having a 1-bit secure flag is healthy
... I have experience of systems where when you divide groups into "Trusted" vs "Untrusted" , you create failure scenarios. E.g. network security

Domenic_: that isn't the proposal, it's necessary but not sufficient

timbl: if you could show me 3-layer items -- I trust A to do B and allow C -- the set of people you need to trust is big, and it is useful to remove some
... but the way browsers do it right now with the origin model are broken

<bhill2> current state without this spec is 4) "I trust ???" <- could be anyone

timbl: you can argue that the origin model is a 1-bit space

<wseltzer> [I see this context as necessary for even knowing you're talking to A]

<bhill2> we're trying to move from 4 -> 1 first as a necessary precondition for any further improvement

timbl: and as you move things into that model, things break
... find some eamples that there's value in making this rough cut
... the utility of a single bit seems dubious to me

(summarises)

<dveditz> one of the items in our charter, COWL, is designed to give a way for site A to say it trusts site C with info B, which approaches what timbl was describing (but not quite the same)

dka: there's a related question of data minimisation

<dka> data minimization http://www.w3.org/2001/tag/doc/APIMinimization.html

dka: there was a 2011 draft that didn't go anywhere.

<dka> Alex: I was curious about the notion that this is a one-bit space.

<dka> … current CORS has issues - don’t think the same origin model is broken though.

<dka> Alex: you made the point you want to treat serving your web site over tls that it can use other origins - but we don’t do that - so it’s not a one-bit system.

<bhill2> yay!

mnot: wanted to talk about the original topic
... looking at the Mozilla objection, this isn't questioning the increase in the use of TLS, it's just a question of how to get there

<timbl> agreed abot scope creep partially

mnot: talked about this with ekr & rbarnes. One of the proposal we talked about was to come up with a plan where all new features after some date require TLS

<dveditz> timbl: it's warm (enough) here in california, too

mnot: can Mozilla folks comment about how that relates to the objection? is it about the goal or the application of the policy?

dbaron: I think what mnot said is reasonable. There was disagreement among Mozillians on this topic

thanks mnot

mnot: a lot of the meat of the objection was driven by, e.g., ekr's concerns

dbaron: I was just going to...

bhill2: I wanted to bring this back to the original concern; it's just a first step
... we're not saying all apps should be omnipotent
... we're starting from a place where users hae to enable things that have power and impact privacy. It isn't even clear that who they're granting that power to is who they think they're granting it to
... all we're doing is trying to establish that the person asking is who they say they are
... today, with HTTP, you could be giving that away to anyone between you and the origin party
... this is just the first part of a richer language around confining origin composition

<Zakim> wseltzer, you wanted to say necessary but not sufficient

wseltzer: this is one element of giving users understanding understanding and control over capabilities. The first step is knowing that who you're talking to is who you think you're talking to.
... webappsec has a strong collection of experts and is a good place to shake out implications and corner cases, and I'd like to understand if the TAG is interested in co-authoring or putting normative restrictions on

dbaron: ...

<dbaron> I seem to not be unmuting...

<dbaron> Yeah, locally muted, and SIP sometimes breaks this way when muted a long time

<dbaron> I'll comment on IRC in a second

dka: there's a question of normativeness about such a document
... if we could do some joint work, perhaps that's a way forward

<dka> Alex: we need to focus on the escalation path.

<dka> … [too fast]

<dbaron> The thing I was going to comment on is that another underlying concern that I've had is the way cross-working-group work happens. In particular, it's pretty common for the opinion of a working group on a particular topic to be led by an opinionated gruop of 1-3 people, and this can lead to a failure mode with working gruop interaction, where those 1-3 people in two different groups (e.g., the TAG or WebAppSec and a group developing a feature) have a differe

<dbaron> nt opinion on a topic, and end up convincing the entire groups to back their opinions, when things would work better if the discussions happened together rather than separately so that the broader members of the groups can be convinced by the whole set of opinionated people rather than the parts just in their groups.

Domenic_: excited taht webappsec is doing the hard work, but agree we should be in that role

<bhill2> I think it is also fine if the TAG wants to invite a technical opinion from WebAppSec in the event of a controversy

<dbaron> I'm ok with the TAG being involved in the document, although it does introduce some additional complexity; just worth being very careful about keeping discussions unified rather than having fragmented discussions.

dka: regarding a joitn doc, are people happy for us to be part of this?
... and second question, should the escalation path be better specified?

<dka> Alex: yes.

dka: would TAG members be willing to help?

yan: yes

dka: I think we have a proposal
... other comments?
... I'm concerned that we don't leave timbl's issue on the floor. We need to think about the disclaimer around the note that just moving to an authenticated connection doesn't imply full trust

+1 to that

<bhill2> +1

timbl: there are 2 problems to having a single boundary: positive and negative failures. In the positive sense, being trusted for anything vs. negative: not being trusted for anything
... we've done rule-based work that creates a lot more depth including use, not just identity

<Travis> +1 on trust policy negotiations. This was stuff I delved into in college 10 years ago... forgot most of it now :)

<Zakim> dka, you wanted to ask about time-frames and how this lines up with our April f2f…

slightlyoff: this only deals with the negative side of that equation

timbl: http can do more than HTTPs
... because the bar has not been set; there isn't an expectation that it's broken

<bhill2> this isn't about saying you can't do CSS6 over http, it does lay out specific things like privacy concerns, sensors and persistence that motivate the choice

<dka> Thanks for your participation, Domenic!

<bhill2> it's not about being a carrot/stick thing, it's about protecting users

slightlyoff: other work is addressing that, including "marking http as bad"

timbl: http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

<dka> Next f2f coming up in April 21-23 in SF. Also Extensible Web Summit coming up on 20 April in SF (extensiblewebsummit.org)

dka: <logistics>

<mnot> At some point, it would be good to talk about the focus of the developer meetup next to the July F2F - focusing on security might be appropriate.

dka: discussing there is probably too late. Is there something we can attach to our f2f that _would_ help you?

bhill2: the issue is more about recharter

slightlyoff: one option is to have non-normative text and an escalation path

dka: not sure that's something for the TAG to decide on...but do we have some agreement from the Mozilla side about that?
... wseltzer what's your view?

wseltzer: I'm looking for language to put into the recharter and if we say that there's a designation for powerful features that's non-normative in webappsec and leave room for TAG endorsement to make it normative, that could be one way to address the objection

dka: you could also put into the charter that webappsec could work with the TAG on it as a joint deliverable

<dveditz> slightlyoff: I'm happy with the charter, and happier with the proposed revisions. But I wasn't among the ones at Mozilla objecting to it

thanks, dveditz

<timbl> “on the wrong side of the law” is I think not a valuable function, because it is single-valued. It falls into the trap of trying to partition the world into two cleanly separate parts, ((which is a bit lke dividin all logical formulas into true and false. Maybe there is a neat proof that such 2-level systems are bound to fail … )). I am reminded of the GEB metalamp discusssions and the Dictionaries in the Library issue...

<dbaron> I need to get some feedback from some other people at Mozilla.

dka: sounds like the proposal needs socialization outside the group

timbl: happy to continue this in another forum = )

ugg, sorry

wseltzer: I hear willingness to jointly edit the work and we'll take that back to webappsec

dka: going to adjourn
... next week is CSS extensibility/houdini

<dveditz> unfortunately when I presented the updates to the charter this week a lot of the relevant people were in Australia and elsewhere and haven't responded yet

dveditz, perhaps y'all can follow up on-list once you have more feedback?

<dveditz> webappsec for sure, or do you mean another list?

dka: wanted to re-iterate strong support

<dka> trackbot, end meeting

- DRAFT -

Technical Architecture Group Teleconference

12 Feb 2015

Attendees

Contents

Powerful Features & such…

Summary of Action Items

Scribe.perl diagnostic output