See also:
Agenda
Raw Minutes taken on OkSoClap Etherpad
IRC log
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."
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
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
NM:
PROPOSED RULES:
* 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)
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.
http://w3ctag.github.io/capability-urls/2014-07-23.html#tahoe-lafs
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
session:
http://googleonlinesecurity.blogspot.com/2012/08/content-hosting-for-modern-web.html
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.
https://github.com/w3ctag/packaging-on-the-web
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
---
https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
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
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)
http://www.w3.org/2014/07/permissions/
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?
[agreement]
https://www.w3.org/2001/tag/group/track/actions/871
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
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>
ADJOURNED