Technical Architecture Group F2F Meeting

23 Jul 2014

See also: Agenda
Raw Minutes taken on OkSoClap Etherpad
IRC log


Yehuda Katz (YK), Dan Appelquist (DA), Yves Lafon (YL), Domenic Denicola (DD), Tim Berners-Lee (TBL), Sergey Konstantinov (SK), Alex Russell (AR), Peter Linss (PL), Jeni Tennison (JT), Dave Herman (DH)
Noah Mendelsohn (NM)
Daniel Appelquist & Peter Linss
Yves Lafon, Dave Herman


Agenda: https://www.w3.org/wiki/TAG/Planning/2014-07-F2F#Proposed_Topics

Attendees: Yehuda Katz (YK), Dan Appelquist (DA), Yves Lafon (YL), Domenic Denicola (DD), Tim Berners-Lee (TBL), Sergey Konstantinov (SK), Alex Russell (AR), Peter Linss (PL), David Herman (DH), Noah Mendelsohn (NM)


Minutes from last f2f, day 2 ( some actions recorded ): http://www.w3.org/2001/tag/2014/04/02-f2f-minutes.html#ActionSummary

Domenic: there are discussions on public-webapps to document fetch options (link to the metadata on URL action)

ACTION-862 - Incoporate comments on guide and put it into respec (on Dom) 

DD: Yes I did that.

[DA: I'm closing that action]

[Discussion re: ACTION-860, ACTION-861]

YK: Let's keep those open.

DD: YK you should read http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0127.html

[ACTION-859: Talk to psig on whether or not it’s possible to amend the tag charter to allow for rec track docs to run under the standard w3c ipr rules. on DKA]

DKA: did action 859, and it will not be possible to do REC track documents within the TAG, as TAG members are not representing their employers.

YK: how about creating the doc then sending it to a group with the right IPR?

DA: We can't force a group to rubberstamp something from us.

YK: There may be an interesting coincidence that our work does not require IPR declarations.

YL: Packaging and URL will be done in another group (with input from us)

DKA: right, URL will be done in Webapps.

DA: Full list of open actions: https://www.w3.org/2001/tag/group/track/actions/open (there are a lot of them)

DA: We should try to make the list of actions closer to the reality

Discussion [ACTION-865: Find jquery animations people and ask if they could build on top of web animations action on YK]

YK: I will try to connect people.

DA: [I will update the action]

DH: Articulating the vision is a good idea. We could do more evangelism about "this is the way people should be working together."

Articulating the vision

YK: Having smaller modules in general...

DH: An extensible web blog... [could be too much time committment]

DA: Do people have ideas to create a more in-depth document about design principles ?

This is the stub document in GitHub: https://github.com/w3ctag/design-principles/blob/master/extensible-web.md

YK: Happy to push it along.

DH: There is lot of education to do, more related to community management, engage people in participating in things they didn't tought of.

DA: I created a new action: https://www.w3.org/2001/tag/group/track/actions/868

TAG election

Noah's proposal: http://lists.w3.org/Archives/Public/www-tag/2014Jul/0049.html

NM: My proposal is in two parts which are potentially separable: 1 )to allow a company to have one extra in case of change of affiliation, until the next regular election. 2) to change the limit on membership by an organization from one member to two.

DA: Addressing the issue about affiliation change may work, raising the limit per organisation is getting resistance.

YL: Note that the rule in the process document is not protecting from collusion of companies with some common interest.

YK: the TAG has moral authority, that why people listen to the TAG, not real authority (per charter).

NM: I've been concerned about assertions that the TAG has no authority. There are specific responsibilities called out in the charter, e.g. to coordinate relationships with other technical organizations and to advise "the director" (Tim). Of course, things work best when the TAG persuades on the merits.

RESOLUTION: We strongly endorse Noah's proposal when it comes to affiliation changes, we also support raising it to 2.

DD: we should say "we strongly support raising it to 2."

TBL: "companies should not have undue influence but individuals are operating on their own not as reps of their companies, and they commit to be impartial."

DD: "trust the election"

DH: I think that having the limit is good as irrespective of the organization, people have biais based on what they work on. Also having limits avoid political issues in trying to avoid the TAG being taken over by one company.

DA: The issue is not the spirit of the rule, but the disruptions it caused in the recent past.

DH: I feel convinced that Noah's rule change is the right one (allowing n+1 to the next election, and bump the limit to two).

DD: The action is to send the message to the AC and the AB right?

DA: Yes, and I am willing to take that action


  * A Member organization is permitted at most two participants on
    the TAG. However, if a change of affiliation of an already seated
    member causes this limit to be exceeded, up to three members from
    the same organization may remain members until results of the next
    TAG election become effective.
Split proposal:
        If a change of affiliation of an already seated
    member causes this limit to be violated, up to one additional member 
    from each organization may remain a member until results of the next
    TAG election become effective.
    (and of course separately propose raising the limit to two)

DA: +1

TBL: +1

[general consensus that this is the right approach]

DA: I will take this back to the AB/AC.


EWS: Sep 11, Berlin.

Next F2F in London (Telefonica, near picadilly circus) 29 Sept - 1 Oct.

TPAC: Santa Clara (27 Oct -> 31 Oct), We have monday/friday reserved - will do ad-hoc.

2015 6-8 Jan (NYC or BOS)

2015-04-[21-23] f2f SFO? (or Europe)

Capability URLs

snapshot draft: http://w3ctag.github.io/capability-urls/2014-07-23.html

JT: been through the comments on the Capability URLs document. Tried to address comments as trade-offs, no golden rules pro or against, just weighting issues.


noah: I too couldn't figure out what the sandbox thing was trying to say

JT: added pros and cons of fragments holding the key.

NM: I saw the email about specifying levels of entropy, but I'm nervous that being specific is beyond the TAG's expertise, and that the amount "required" might change over the years. I suspect it's better that we just point out that entropy, etc. must be sufficient to the security needs of the particular application.

AR: any recommendation on entropy and hashes?

JT: See http://lists.w3.org/Archives/Public/www-tag/2014Jun/0003.html don't know what need to be said.

NM: seems to be out of the TAG's expertise, and also something that is in flux, as recommendation may change in time. It is also application-specific.

JT: It could be useful to have some indications about good practises to help people who are not specialists in security.

AR: The baseline advice is "don't invent something, rely on existing sources" (like for entropy).

JT: About Section 3.2, see http://googleonlinesecurity.blogspot.co.uk/2012/08/content-hosting-for-modern-web.html , not sure I documented it properly.

AR: is the comment about using different origin per user?

JT: See email.

Another probably worthwhile use case is for providing access to documents that are inherently unsafe to host in authenticated / sensitive origins within an otherwise authenticated

AR: Issue is that hosting unsecured documents at your main origin may lead to exposing other things. Will ask what exactly he wants to see here.

AR: The general consideration is about the use of cookie and/or capability URIs in the context of authenticated spaces.

NM: Overall, I like where it's heading. I see risks in the use of it. I would like to rebalance the introduction, also there are lots of details for the positive examples, not that much on  issues for problematic examples.

DA: I like detailing potential risks, can we link to instances where leaks happened (when possible)?

JT: Risks are described, but it's missing examples.

<discussion about capability URLs and canonical URL for the same content, and how to link>

DD: The site could to replacement of the capability URI depending on who you are, if it's you, the location will be replaced to the canonical URL.

ACTION: Domenic to suggest something on 5.3 for capability URLs draft

ACTION: Noah to suggest some additional intro text and fles out some of the examples of risks

JT: We should try to keep examples realistic.



JT: no progress since last time we discussed it in a telcon.

DH: Jonas Sicking sent me a set of requirements for packaging. The baseline is to try to stick with the URL approach. The major thing we overlook is not breaking URL.

AR: Jeni's proposal is coherent with that.

<discussion about history of why this approach was choosed over URL tweaking>

Background: https://github.com/w3ctag/packaging-on-the-web#specialising-urls discusses possibiity of specialising URLs

DH: We need to get feedback from Jonas first.

<discussion about use case, optimization or first-class citizen that can be moved around and shared>

JT: We need to work through the examples, and explain the issues short-term, mid-term and end-term of both solutions (URL only or package as proposed).

DH: want to work offline on that?

JT: Sure.

==== Lunch break ===

Agenda items for afternoon

* EME next steps
* Layout APIs next steps
* Service worker /  extension spec patterns



DA: blah blah blah homeopathy blah blah

DA: we need to agree on next steps for EME

SK: feedback would be appreciated

AR: we closed the topic the other day by discussing ways we could help. sounded like that was a conversation for us to continue

DA: we agreed within the task force mailing list we'd help bring some of these perspectives

SK: should we use the EME Opinion doc as a starting point?

AR: got a good chunk of technical info we didn't have before

DA: for instance opinion note doesn't mention sandboxing of CDM. that's one thing we discussed with david: how language within spec might be strengthened wrt sandboxing. now, we also discussed that sandboxing doesn't apply with e.g. secure boot

YK: my takeaway: there are areas of agreement with TAG and David; most high value thing we can do is back him up on those issues

AR: seemed like a lot of those were on interop

YK: agreed

SK: I'll change EME opinion to talk about sandboxing and will add notes on interop, then I'll send it out to HTML working group

layout APIs redux

AR: I was looking into font and line breaking APIs. we have this stuff in platform, just not lined up well. we don't have things like list of fonts or metrics of fonts. speaking with a startup that needs this in a GL container, was going to collaborate with them on font access they need. will try to come back with something concrete

PL: it's a growing list

AR: it is, but good to do evolutionarily

YK: servo team thinking about factoring

DD: not the same thing?

YK: unknown? they were thinking about minimal set of callbacks

DD: ah ok

AR: can we schedule time in next couple weeks to start thinking through?

PL: sure. we could start sketching out APIs

AR: we could come back with an enumeration of areas of investigation

PL: have to think about different languages and writing modes

AR: extension apis for service worker: permission-based approach; design api such that it can always fail. you get an API object and hand it in if you get permission. this style is something we want to proliferate

DA: you can rely on the platform not having to grant permissions?

AR: this is a dodge. it's meant to lubricate the question of what UI should you create, if any, and when should you enable a particular permission, if at all. a lubricant that lets UAs and users come to agreements in different ways over time (without adopting the Android/iOS models)

AR: in service of letter users revoke permissions too. in chrome working on new UI for coalescing permissions granted by a web app, with toggles you can disable

DA: relationship to SW is what?

AR: there are APIs plugging into SW, and it's those APIs that end up needing permission (e.g. notifications, which can be annoying)


DA: I will be attending this meeting.

AR: that's all!

DH: [...] is there a space for standardization - do we need API around asset management, space management, etc... 

AR: ios does a better job than android on this

YK: android is like "delete all storage for this app" which is not useful

AR: we have eval so we can't separate program from data

AR: could imagine version of storage api that allowed tagging items, or a central repository -- all about static stuff. but danger zone is that when you don't know what stuff is, you can only blow up the world (like android). and you won't know

DH: that's why it feels like the app needs to be in the loop on this

AR: had similar questions around resource pressure. some way to note the priority of a set of resources so you can choose to evict one and not others. what I think we've come to understand is for priority where you can tell the system what you need space-wise and how much you're being charged for, that's probably best we can get done

YK: it's equivalent

AR: it is, but it's also the minimal thing we can do

AR: hoping for something similar for resource management; describe what you've got and ask you to delete stuff. thinking about cooperative management rather than explicitly exposing filesystem abstraction

DH: distinguish resource pressure with automatic release from explicit management on part of user (store episode offline then delete after)

AR: there's cataloguing, sorting, and letting you manage; that's what app invariably winds up doing. you could imagine putting more of that logic in the system interface level, or more like the android model you do it in the app

DH: maybe as SW starts landing we'll see apps doing more in-house UI for this, and maybe it just doesn't need the system UI

AR: maybe we'll see like a "cache explorer" UI

DH: though that won't really have domain-specific smarts

AR: maybe it's a step along the way to figuring out what incremental changes we might want, and we don't know what we don't know yet so I'd rather take it a step at a time

DH: agreed

DA: more and more web apps on mobile making more and more permissions requests and the more requests you make of user, the more they are desensitized to it ("YES I WANT THE CATS JUST GIVE ME THE CATS")

DA: I've started in past month that web sites with nothing to do with location are requesting location -- obviously coming from 3rd party ad networks

AR: even on google.com we find users rarely give us location

DH: saying "no" doesn't prevent you from continuing so probably the path of least resistance

AR: there's no way to pass a string through to the UI. jonas is a fan of that

TBL: I think that's the most important issue for privacy

AR: the assumption is that people lie

DH: and users ignore it

TBL: if they lie people will find out and there'll be backlash

AR: this relates to first party vs third party too

AR: as you compose web apps with iframes, when UI is brought up around giving your location, it's not clear visually which one is asking for it. I think we have restrictions today around iframes asking, but there's going to be a de facto policy over time

DA: in past you've talked about model where app could negotiate with UA around asking for various permissions, fallback permissions, etc

AR: I think that ended up being a little more than really necessary; some high order bits: revokability. should sites like malware sites even be allowed to ask for some permissions. those are the kinds of things we're exploring

DA: do you think installing app around manifest ought to be in spec, or UA-specific

AR: this API style doesn't back you into any strategy on how to grant permissions. we're going to have diversity of views

AR: today there's a hostage negotiation whenever there's a new version of an app in e.g. android. those are poor user experiences and they lead to distrust because user is not in control. don't want to foreclose options that UAs are going to explore. that will be tough on developers but developers always have to deal with not being given permissions

AR: hope we can get to a point where we can do storage partitioning via CSP. there's a proposal right now called origin sandboxing where you're disconnected from everything

YK: iframe sandbox does this now, right?

AR: yes but storage is transient. want storage to be persistent

AR: if you have a raw socket API that's unconstrainted, there has to be a way that it can be constrained again

AR: there's gonna be a class of magical things where users do have to eventually say "yes I trust this thing"

DA: which brings back topic with Jungkee and Wongseok about sysapps. is there a way to make that progress. standing criticism that sysapps isn't webby enough, but they say that's why they created sysapps

AR: if not working on the web what's the point?

DA: right and some stuff could be for the web but should be separated out

AR: I see: task scheduler, contacts, messaging, telephony, sockets. then they want bluetooth, calendar, device caps, idle notification, network storage

DA: isn't there also a separated web NFC api?

DD: also convo topic about how many specialized protocols we should be creating?

YK: basically do we need NFC or just a lower-level thing like raw sockets

DA: cf http://www.w3.org/TR/nfc/ , https://wiki.mozilla.org/WebAPI/WebNFC

DH: what are the constraints around raw sockets? has anyone made progress on how it could possibly work?

YK: keep makes sense to me

AR: people at mozilla like jonas think signing (and restricting so you know what the set of code is) is promising

YK: can we create a list of things that are non-keep and keep permissions?

AR: chrome engineers don't believe you need signing and packaging. they're exploring the behavioral half of the story

YK: we have revokation with malware model

AR: right, that's revokation. we can do more fine-grained too, like slightlyevil.com can't have access to your contacts

YK: would be great if we can get the people afraid of raw sockets to enumerate why they're willing to give raw sockets to an android app but not a web app, then we can start attacking a solution to that list

AR: my approach is: design APIs where people can keep saying no till they say yes; allow UAs to make different choices

DH: so your approach to keep is to do it within google in chrome as a way to just automatically decide to say "yes" to some of these

YK: this decoupling is good because Firefox can choose the same or a different strategy without blocking the apis making progress

DA: does this entail some design processes for designing APIs to go ahead and ask these questions

DH: IOW, can we unstick API design questions every time worrying about infobar apocalypse? or put differently we have to socialize the idea that API questions are decoupled from UI questions

AR: that's right.

DD: Should we articulate this as an API design guideline?



TBL: ignoring how the data is being used

AR: this is where jonas's idea of passing a string through where api can indicate why it wants to use the data

YK: I thought you had this

AR: I did, people convinced me to eliminate it, Jonas re-convincing me to add it again

TBL: for things like email, company will ask do you want updates etc; for push I could imagine a similar thing

DA: permission you're granting is for nytimes.com to send push notifications, but you configure them within the app

AR: you're suggesting giving even more metadata; e.g. nytimes.com could register different channels. this was in an earlier version of my proposal but it was removed

TBL: I'm less interested in channels than different levels. e.g. security update vs new widget to sell you. or flight delayed vs new flights to bangkok on sale!

AR: I don't know how to prevent APIs to prevent abuse

AR: android is getting some smarts around suppressing some notifcations based on how user interacts; we could get some experience with how to do notifications that aren't guaranteed to happen

The Next 700 Protocols

DD: Anne is trying to say the web is forever, it should not depend on fleeting protocols. I think his solution is something like an HTTP facade based on custom URLs in front of it

YK: sounds like a potential perf nightmare

DD: Dmitri has his "tubes" thing

DH: I haven't been able to make any sense of the tubes thing

DA: with bluetooth there are specific things you need to be able to pair the app with your device, things that are app-specific. would be worried about abstracting too much

DD: you get a MessagePort...

AR: lemme try. imagine I have a ServiceWorker at example.com and acme.com also has a ServiceWorker. origin model separates them, they can't talk to each other. there are cases where acme has services I'd like to use. could imagine an intent system with a mediator in the cloud. OR, you could imagine an RPC system like XHR where I could call a service at acme.com. but you want to distinguish remote vs local services. so how to talk to them? thought was what if I could call an API that would attempt to send an event to acme.com's ServiceWorker and if it wanted to it could return a MessagePort. not a high-level protocol

YK: how does this help with "I would like Thunderbolt on the web"

AR: let's say I had an HTC phone and you had an LG phone. they might have diff hardware. what if you could imagine lg.com already had a ServiceWorker. you could ask lg.com "can you tell me about a bluetooth device?"

YK: you could imagine that... but here's what I'm trying to understand. it started out with "the web is forever" but the thing we're doing is not "forever" but coupled to all sorts of technologies

AR: you will have fixed points in technology landscape that will outlive the hardware

DD: we'll have to ship code forever even when it goes away

YK: no, when it goes away no one is using it and you can unship the code

AR: <something>

YK: I see. argument is: device manufacturer can create proprietary protocols and ship them. special samsung bluetooth, special LG bluetooth, etc. surprised anyone likes this; you're throwing away interop

AR: how do you build momentum for new protocols? you have to allow them to evolve

YK: but it's unclear how to avoid bluetooth.js which is a collection of all the different vendor-specific

DH: Yehuda is talking about "we should standardize common things" and Alex is saying "we should create space for uncommon things to bootstrap into existence before they are ready to standardize"

AR: agreed

DA: I think there's also the concern about baking support for non-royalty-free technologies into the web

YK: there's a difference between royalty-free and interoperable. there's value in interoperability even if you don't have royalty-free. but I'm worried before we even get there we'll create space for non-interoperable anything

AR: should web be deprived of access to all that hardware in the interim?

YK: then you could just ship something in Chrome

DD: who are you and what have you done with Yehuda? ;-P

YK: it's unclear this is any different. it lets samsung add stuff, and maybe makes chrome feel morally better, but the net effect of proprietary stuff shipping on the web is the same.

PL: what if 2 years from now some other new radio format becomes popular? from a web app point of view I don't care if I'm talking bluetooth or some new thing? it's just a stream to me

AR: you absolutely do care!

PL: there are reasons to care, but at high level app, I often don't care

AR: we should make that the *easiest* way to do it

NM: is there a simple way to ask for the clean way

DD: JS gives you all you need to do this; the bluetooth.js lib on GitHub abstracts it away

NM: sometimes even publicizing that as a best practice

YK: it seems like Chrome doesn't want to ship non-standard features without a flag

DH: I'm confused. please to explain me please?

<people say stuff>

DH: I'm more confused.

YK: here's a matrix:

                |  HTC   |      Samsung        |
FF           |             |                             |
Chrome  |             |                              |

YK: your solution is making the vertical thing possible but I don't want it for horizontal

YK: tl;dr you are talking about making NPAPI work for JS. seems good.

AR: yes. thank you.

RESOLUTION: tentative agreement / consensus that the proposal articulated by Alex regarding a server-worker centric approach to device/capability access could be a good thing and let's continue to work on that yay.

<much nodding of heads ensued>


Sumamry of Actions

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-07-31 16:12:31 $