19:23:17 <RRSAgent> RRSAgent has joined #tagmem
19:23:17 <RRSAgent> logging to http://www.w3.org/2015/02/12-tagmem-irc
19:23:19 <trackbot> RRSAgent, make logs public
19:23:19 <Zakim> Zakim has joined #tagmem
19:23:21 <trackbot> Zakim, this will be TAG
19:23:21 <Zakim> ok, trackbot; I see TAG_Weekly()3:00PM scheduled to start in 37 minutes
19:23:22 <trackbot> Meeting: Technical Architecture Group Teleconference
19:23:22 <trackbot> Date: 12 February 2015
19:32:40 <mkwst> mkwst has joined #tagmem
19:55:06 <dbaron> dbaron has joined #tagmem
19:55:20 <bhill2> bhill2 has joined #tagmem
19:56:41 <yan> yan has joined #tagmem
19:57:38 <Zakim> TAG_Weekly()3:00PM has now started
19:57:46 <Zakim> +dka
19:57:54 <dka> zakim, what is the code?
19:57:54 <Zakim> the conference code is 0824 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dka
19:58:13 <dka> trackball, start meeting
19:59:14 <dka> Chair: Dan
19:59:23 <Zakim> + +29008aaaa
19:59:23 <Zakim> +WSeltzer
19:59:32 <dka> Topic: Powerful Features & such…
20:00:14 <dka> zakim, aaaa is mnot
20:00:14 <Zakim> +mnot; got it
20:00:33 <mnot> mnot has joined #tagmem
20:00:36 <Zakim> +BHill
20:00:50 <mnot> zakim, who is here?
20:00:50 <Zakim> On the phone I see dka, mnot, WSeltzer, BHill
20:00:52 <Zakim> On IRC I see mnot, yan, bhill2, dbaron, mkwst, Zakim, RRSAgent, timbl, dka, wseltzer, wycats, Domenic_, dherman, slightlyoff, plinss, projector, Yves, trackbot
20:01:04 <Zakim> +Yves
20:01:40 <Zakim> + +1.408.505.aabb
20:01:50 <Zakim> +[IPcaller]
20:02:06 <dveditz> dveditz has joined #tagmem
20:02:16 <yan> zakim, +1.408.505 is me
20:02:18 <Zakim> +yan; got it
20:02:19 <Zakim> +[Mozilla]
20:02:23 <Zakim> +??P11
20:02:28 <wseltzer> zakim, [IPc is dveditz
20:02:28 <Zakim> +dveditz; got it
20:02:40 <Domenic_> Zakim, P11 is me
20:02:40 <Zakim> sorry, Domenic_, I do not recognize a party named 'P11'
20:02:41 <dveditz> thx, wseltzer
20:02:52 <wseltzer> zakim, mute me
20:02:52 <Zakim> WSeltzer should now be muted
20:03:30 <slightlyoff> OMW
20:05:08 <Zakim> +slightlyoff
20:05:18 <slightlyoff> I can scribe
20:05:40 <slightlyoff> are we doing minutes a new way?
20:05:40 <dka> Scribe: slightly
20:06:05 <slightlyoff> fair enough.
20:06:07 <slightlyoff> thanks
20:06:45 <slightlyoff> 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.
20:06:49 <Zakim> +TimBL
20:08:12 <dka> https://github.com/w3ctag/meetings/blob/gh-pages/2015/telcons/02-12-powerfulfeatures.md
20:08:13 <slightlyoff> dka: alex, yan, anything to add?
20:08:26 <Travis> Travis has joined #tagmem
20:09:30 <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]...
20:09:37 <Zakim> +[Microsoft]
20:09:46 <slightlyoff> dka: yan?
20:09:55 <timbl> q+
20:09:58 <Travis> Zakim: [Microsoft] is me
20:09:59 <slightlyoff> yan: alex summarised it
20:10:01 <bhill2> q+
20:10:07 <Travis> Zakim, [Microsoft] is me
20:10:07 <Zakim> +Travis; got it
20:10:15 <wseltzer> ack wseltzer
20:10:29 <dka> q?
20:11:07 <slightlyoff> 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.
20:11:33 <slightlyoff> wseltzer: a reviewer expressed concern about who should decide when something is powerful; who should restrict this?
20:11:35 <dka> http://www.w3.org/TR/powerful-features/
20:11:55 <slightlyoff> wseltzer: since the TAG is our design group, it seems the TAG should help decide how to allocate responsibility
20:12:10 <dka> http://www.w3.org/TR/powerful-features/#is-feature-powerful
20:12:20 <slightlyoff> wseltzer: who looks out for the various interests? (developer, user, browser)
20:12:44 <slightlyoff> dka: there's a leading statement in the intro about impacting privacy and security
20:12:57 <dka> ack timbl
20:12:58 <slightlyoff> dka: TimbBL and brad are on the q
20:13:32 <slightlyoff> timbl: I wanted to comment that it's important to separate "https:" from encryption
20:13:44 <dveditz> dka: that "is feature powerful" section has been substantially rewritten: https://w3c.github.io/webappsec/specs/powerfulfeatures/#restrictions
20:13:54 <slightlyoff> timbl: I think it's important to encrypt HTTP; confusion about address space and protocol
20:14:19 <slightlyoff> thanks dveditz; could you q+ to give us an overview of the changes?
20:14:31 <slightlyoff> dka: this is something we debated at a prior F2F
20:14:34 <dka> ack bhill
20:15:20 <slightlyoff> 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?
20:15:45 <slightlyoff> bhill2: we've recieved input from other WGs that they want help specifying the second part and are happy to delegate to webappsec
20:16:07 <slightlyoff> bhill2: addressing timbl's point, there's a concern about authenticating origins
20:16:22 <slightlyoff> bhill2: mozilla has filed a formal objection about the charter language
20:17:03 <dveditz> mnot: I believe it's the one I linked to
20:17:13 <slightlyoff> 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
20:17:17 <Domenic_> mnot: I think it's https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful
20:17:21 <wseltzer> https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-feature-powerful
20:17:25 <dveditz> and https://w3c.github.io/webappsec/specs/powerfulfeatures/#algorithms would be normative
20:17:49 <dka> q?
20:17:49 <slightlyoff> 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?
20:17:58 <Domenic_> q+
20:18:04 <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)
20:18:07 <slightlyoff> bhill2: groups want to make their own decisions about what is "powerful"
20:18:15 <slightlyoff> bhill2: they don't want webappsec making that decision for them
20:18:35 <dveditz> I'm sorry, wendy is correct, #is-feature-powerful not #restrictions
20:18:40 <slightlyoff> 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
20:18:42 <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
20:18:46 <wseltzer> [bhill said: "is feature powerful" would be non-normative; while "is context sufficiently secure" would be normative]
20:18:52 <slightlyoff> bhill2: TAG is elected, webappsec is "just another working group"
20:18:54 <slightlyoff> q+
20:18:56 <slightlyoff> q?
20:19:10 <slightlyoff> dka: is there someone from MOzilla here?
20:19:22 <slightlyoff> dka: can someone re-interpret/contextualize the objection?
20:19:28 <Domenic_> https://www.w3.org/2002/09/wbs/33280/WebAppSec-Recharter-2015/results
20:19:44 <slightlyoff> dveditz: I'm a co-chair of the webappsec WG, so am a bit conflicted, deferring to dbaron
20:19:59 <dka> q?
20:20:11 <wseltzer> -> https://lists.w3.org/Archives/Public/www-archive/2015Feb/0001.html Mozilla's objection
20:20:30 <slightlyoff> dbaron: I think it has been covered reasonably well. The major concern is that people worried that the experts on a subject being overridden that they couldn't argue tradeoffs about
20:20:43 <slightlyoff> s/that/in ways that/
20:21:07 <slightlyoff> dveditz: there were some groups, e.g., WebCrypto, who had hard-fought battles and the webappsec group was accused of a power-grab
20:21:17 <dka> ack Dom
20:21:46 <slightlyoff> Domenic_: one thing I'm hoping is that we could have a joint-TAG-Webappsec deliverable to create a rubric
20:21:57 <slightlyoff> Domenic_: I think it would be a shame to not have normative language
20:22:14 <slightlyoff> Domenic_: jurisdictionally, it seems like the TAG is the right group, but webappsec has the expertise
20:22:20 <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.
20:22:30 <slightlyoff> dka: that's interesting. We're working on some joint-deliverable with other WGs
20:22:34 <slightlyoff> q?
20:22:50 <slightlyoff> dka: if there's value on having this as a joint deliverable, It might add more weight
20:22:56 <timbl> Three levels of dealing with trust:
20:23:10 <slightlyoff> dka: the other question is: is it really possible to have a normative algorithm?
20:23:32 <slightlyoff> dka: we can have a definition, but it feels like there will always be edge cases
20:23:45 <dka> q?
20:23:46 <slightlyoff> speaking personally, I agree with dka there
20:23:52 <dka> ack slig
20:24:11 <timbl> q+ 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 from 2 to 3 not from 2 to 1
20:24:14 <Domenic_> slightlyoff: having a strong rubric that is endorsed by the tag doesn't necessarily end the debate
20:24:22 <dka> q?
20:24:28 <Domenic_> slightlyoff: you still need to figure out what the correct escalation path is
20:24:38 <slightlyoff> q-
20:24:38 <dka> ack tim
20:24:39 <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
20:24:39 <Zakim> ... from 2 to 3 not from 2 to 1
20:24:47 <Domenic_> slightlyoff: would like to understand what people who are objecting think the correct group is for the kind of stuff---TAG or not?
20:24:56 <slightlyoff> timbl: I have yet to be convinced that having a 1-bit secure flag is healthy
20:25:35 <slightlyoff> timbl: I have experience of systems where when you divide groups into "Trusted" vs "Untrusted" , you create failure scenarios. E.g. network security
20:25:50 <slightlyoff> Domenic_: that isn't the proposal, it's necessary but not sufficient
20:26:33 <slightlyoff> 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
20:26:43 <dka> q?
20:26:44 <slightlyoff> timbl: but the way browsers do it right now with the origin model are broken
20:26:56 <bhill2> current state without this spec is 4) "I trust ???" <- could be anyone
20:27:11 <slightlyoff> timbl: you can argue that the origin model is a 1-bit space
20:27:13 <wseltzer> [I see this context as necessary for even knowing you're talking to A]
20:27:20 <bhill2> we're trying to move from 4 -> 1 first as a necessary precondition for any further improvement
20:27:26 <slightlyoff> timbl: and as you move things into that model, things break
20:27:28 <slightlyoff> q+
20:27:41 <mnot> q+
20:27:46 <slightlyoff> timbl: find some eamples that there's value in making this rough cut
20:27:49 <bhill2> q+
20:27:53 <wseltzer> q+
20:28:25 <wseltzer> q+ to say necessary but not sufficient
20:28:36 <slightlyoff> timbl: the utility of a single bit seems dubious to me
20:28:41 <slightlyoff> (summarises)
20:28:43 <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)
20:28:51 <slightlyoff> dka: there's a related question of data minimisation
20:28:53 <dka> data minimization  http://www.w3.org/2001/tag/doc/APIMinimization.html
20:29:05 <dka> q?
20:29:09 <slightlyoff> dka: there was a 2011 draft that didn't go anywhere.
20:29:14 <dka> ack sli
20:29:51 <darobin> darobin has joined #tagmem
20:29:51 <dka> Alex: I was curious about the notion that this is a one-bit space.
20:30:20 <dka> … current CORS has issues - don’t think the same origin model is broken though.
20:30:44 <dka> q?
20:31:29 <slightlyoff> q+
20:34:16 <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.
20:34:31 <timbl> q?
20:34:33 <dka> ack mnot
20:34:37 <bhill2> yay!
20:34:39 <slightlyoff> mnot: wanted to talk about the original topic
20:35:02 <slightlyoff> mnot: 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
20:35:02 <timbl> agreed abot scope creep partially
20:35:44 <slightlyoff> mnot: talked about this with ekr & <scribe failure>. One of the proposal we talked about was to come up with a plan where all new features after some date require TLS
20:36:04 <dveditz> timbl: it's warm (enough) here in california, too
20:36:06 <dka> q?
20:36:13 <dka> ack bhill
20:36:20 <slightlyoff> mnot: can Mozilla folks comment about how that relates to the objection? is it about the goal or the application of the policy?
20:36:23 <slightlyoff> q-
20:36:50 <slightlyoff> dbaron: I think what mnot said is reasonable. There was disagreement among Mozillians on this topic
20:37:13 <slightlyoff> thanks mnot
20:37:22 <wseltzer> s/<scribe failure>/rbarnes/
20:37:34 <dka> q?
20:37:46 <slightlyoff> mnot: a lot of the meat of the objection was driven by, e.g., ekr's concerns
20:37:54 <slightlyoff> dbaron: I was just going to...
20:38:07 <slightlyoff> bhill2: I wanted to bring this back to the original concern; it's just a first step
20:38:20 <slightlyoff> bhill2: we're not saying all apps should be omnipotent
20:38:54 <slightlyoff> bhill2: 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
20:39:11 <slightlyoff> bhill2: all we're doing is trying to establish that the person asking is who they say they are
20:39:32 <slightlyoff> bhill2: today, with HTTP, you could be giving that away to anyone between you and the origin party
20:39:51 <slightlyoff> bhill2: this is just the first part of a richer language around confining origin composition
20:39:51 <dbaron> q+
20:40:12 <dka> q?
20:40:14 <dka> ack wendy
20:40:18 <dka> ack wsel
20:40:18 <Zakim> wseltzer, you wanted to say necessary but not sufficient
20:40:28 <dka> q?
20:41:09 <slightlyoff> 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.
20:41:58 <slightlyoff> wseltzer: 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
20:42:13 <dka> ack db
20:42:20 <slightlyoff> dbaron: ...
20:42:37 <dbaron> I seem to not be unmuting...
20:42:51 <wseltzer> ack dbaron
20:42:52 <dka> zakim, unmute dbaron
20:42:52 <Zakim> dbaron was not muted, dka
20:43:13 <dbaron> Yeah, locally muted, and SIP sometimes breaks this way when muted a long time
20:43:17 <dbaron> I'll comment on IRC in a second
20:44:07 <slightlyoff> dka: there's a question of normativeness about such a document
20:44:25 <yan_> yan_ has joined #tagmem
20:44:59 <slightlyoff> dka: if we could do some joint work, perhaps that's a way forward
20:45:01 <slightlyoff> q+
20:45:06 <dka> ack sli
20:45:43 <dka> Alex: we need to focus on the escalation path.
20:45:54 <dka> … [too fast]
20:46:00 <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
20:46:00 <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.
20:46:46 <slightlyoff> Domenic_: excited taht webappsec is doing the hard work, but agree we should be in that role
20:47:07 <bhill2> I think it is also fine if the TAG wants to invite a technical opinion from WebAppSec in the event of a controversy
20:47:35 <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.
20:47:48 <slightlyoff> dka: regarding a joitn doc, are people happy for us to be part of this?
20:47:59 <slightlyoff> dka: and second question, should the escalation path be better specified?
20:48:12 <dka> Alex: yes.
20:48:52 <slightlyoff> dka: would TAG members be willing to help?
20:48:59 <slightlyoff> yan: yes
20:49:04 <slightlyoff> dka: I think we have a proposal
20:49:24 <slightlyoff> dka: other comments?
20:49:56 <slightlyoff> dka: 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
20:50:03 <slightlyoff> +1 to that
20:50:06 <bhill2> +1
20:50:43 <slightlyoff> 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
20:51:03 <slightlyoff> q+
20:51:10 <dka> q?
20:51:32 <dka> q+ to ask about time-frames and how this lines up with our April f2f…
20:52:08 <slightlyoff> timbl: we've done rule-based work that creates a lot more depth including use, not just identity
20:52:12 <Travis> +1 on trust policy negotiations. This was stuff I delved into in college 10 years ago... forgot most of it now :)
20:52:49 <dka> ack sli
20:53:17 <dka> ack dka
20:53:17 <Zakim> dka, you wanted to ask about time-frames and how this lines up with our April f2f…
20:53:24 <slightlyoff> slightlyoff: this only deals with the negative side of that equation
20:53:36 <slightlyoff> timbl: http can do more than HTTPs
20:53:54 <Zakim> -Domenic
20:53:58 <slightlyoff> timbl: because the bar has not been set; there isn't an expectation that it's broken
20:53:58 <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
20:54:03 <dka> Thanks for your participation, Domenic!
20:54:26 <bhill2> it's not about being a carrot/stick thing, it's about protecting users
20:54:35 <slightlyoff> slightlyoff: other work is addressing that, including "marking http as bad"
20:54:49 <slightlyoff> timbl: http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
20:55:01 <dka> Next f2f coming up in April 21-23 in SF. Also Extensible Web Summit coming up on 20 April in SF (extensiblewebsummit.org)
20:55:04 <slightlyoff> dka: <logistics>
20:55:49 <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.
20:55:51 <slightlyoff> dka: discussing there is probably too late. Is there something we can attach to our f2f that _would_ help you?
20:56:00 <slightlyoff> bhill2: the issue is more about recharter
20:56:40 <slightlyoff> slightlyoff: one option is to have non-normative text and an escalation path
20:57:09 <slightlyoff> dka: not sure that's something for the TAG to decide on...but do we have some agreement from the Mozilla side about that?
20:57:39 <slightlyoff> dka: wseltzer what's your view?
20:58:18 <slightlyoff> 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
20:58:35 <slightlyoff> dka: you could also put into the charter that webappsec could work with the TAG on it as a joint deliverable
20:58:36 <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
20:58:53 <slightlyoff> thanks, dveditz
20:59:22 <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...
20:59:26 <dbaron> I need to get some feedback from some other people at Mozilla.
20:59:34 <timbl> </ramble>
20:59:35 <slightlyoff> dka: sounds like the proposal needs socialization outside the group
20:59:53 <slightlyoff> timbl: happy to continue this in another forum = )
20:59:59 <slightlyoff> ugg, sorry
21:00:13 <slightlyoff> wseltzer: I hear willingness to jointly edit the work and we'll take that back to webappsec
21:00:24 <slightlyoff> dka: going to adjourn
21:00:32 <slightlyoff> dka: next week is CSS extensibility/houdini
21:00:32 <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
21:01:00 <slightlyoff> dveditz, perhaps y'all can follow up on-list once you have more feedback?
21:01:15 <dveditz> webappsec for sure, or do you mean another list?
21:01:15 <slightlyoff> dka: wanted to re-iterate strong support
21:01:21 <slightlyoff> <adjourned>
21:01:23 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-tagmem-minutes.html Yves
21:01:23 <Zakim> -yan
21:01:24 <Zakim> -TimBL
21:01:25 <Zakim> -dveditz
21:01:25 <dka> trackbot, end meeting
21:01:25 <trackbot> Zakim, list attendees
21:01:26 <Zakim> As of this point the attendees have been dka, +29008aaaa, WSeltzer, mnot, BHill, Yves, +1.408.505.aabb, [IPcaller], yan, dbaron, dveditz, Domenic, slightlyoff, TimBL, Travis
21:01:26 <Zakim> -dbaron
21:01:29 <Zakim> -Yves
21:01:29 <Zakim> -WSeltzer
21:01:30 <Zakim> -mnot
21:01:33 <trackbot> RRSAgent, please draft minutes
21:01:33 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/12-tagmem-minutes.html trackbot
21:01:34 <trackbot> RRSAgent, bye
21:01:34 <RRSAgent> I see no action items
21:01:34 <Zakim> -dka
21:01:36 <Zakim> -BHill