Present: Dan, Yves, Alex, Tim, Hadley, Travis, Peter, David, Mark, Andrew Guests: James Stewart, GDS (afternoon) Scribes: Mark (AM), Hadley (PM)
Agenda was bashed.
Encouraging custom device APIs vs Restful Architecture (Hadley) - e.g. Cars, TVs... the issue keeps coming up... can we come up with an architectural resolution?
Hadley: At what point do we think that the architecture of the Web should be replicated in closed contexts, like a car, or do we say that they can do what they like?
Travis: Privacy comes into play. Do I want all of my worlds to be connected? If so, what are the ramifications? At EWS Melbourne we discussed this.
Hadley: Good point. I was going to make the argument that the car is self contained, but it's not once you connect your phone to it.
Dan: The use case is you've got a phone or another Web device in your hand, connecting to the car by bluetooth. You're able to extract engine management data via this UI.
Alex: What do you need to do if you want to expose the data of this API at a URL? Both approaches are useful.
Hadley: Is that the point of commonality? If you want the resoruces to be accessable at a URL, Web principles apply?
Dan: Another URL-centric approach is more like the physical Web architecture. You go to a URL, pull down a Web app, it uses the bluetooth API to connect back to the data source you originally went to.
Yves: Trust model?
Dan: Same as normal bluetooth model. Because you receive the URL from a bluetooth source in the first place, you can skip some steps regarding association/pairing.
Yves: If it's used to control a car, you have to be sure you have the right signatures, etc.
Travis: Proximity is an important factor.
Yves: Fob hijacking overcomes proximity.
Hadley: I'm still looking for a general principle.
Alex: What's the difference between a watch and a car?
Hadley: How would we advise them
mnot: maybe we should approach this like a policy question, and talk about the benefits of various approaches. For many people, JS APIs are more approachable. If we can document the benefits and point them at tools to help them make thse choices, that might help.
Peter: I've been thinking about that, and failed to come up with a conclusive recommendation. In most cases, you really want both. There are many advantages to network APIs, but JS APIs are more approachable.
Travis: Is a JS API a curated view / more high-level view? Is a network API going to constrain an action?
- Andrew arrives *
Mark: talks about A Note on Distributed Computing
Travis: JS attempts to address this through asynchrous programming.
Alex: There's a TC39 meeting right now to try to advance this. Long story story, it's going to get easier to use async programming in JS.
Alex: I was reviewing the HBBTV spec, and they were using JSON RPC. That style is pretty natural using modern JS. But it is a network protocol, fundamentally.
Tim: There's a ridiculous amount of code currently, to support async.
Alex: This should get better soon. For example, arrow functions. They're a shorter, more concise way of handling most callbacks.
[http://tc39.github.io/ecmascript-asyncawait/]
Travis: All programming languages have encapsulation.
Tim: That doesn't work well with asynchronous programming.
Alex: Correct.
mnot: As the TAG, are we comfortable with major new functions (e.g., TV Control) being available only in JS and only in browsers. Is that good or bad for the Web? Could argue either way.
Alex: Sounds like TV question: runtime fused to hardware.
Andrew: My fear about having something in a black box is around updates; there isn't a good track record there.
Yves: Often, upgrades are there for only a limited amount of time. E.g., iPods, TVs. This will hurt evolution.
Alex: We've had experiences with browsers in the past; those browsers were being used for general purpose content. With a built-in tv or car browser, the principle is that you shouldn't be connecting to the Internet after its warranty runs out. They're reusing Web technology.
Travis: Warantee periods are because hardware wears out. Does software?
Alex, Tim: Yes.
Mark: It's pretty clear the industry is getting value out of the Web here; is the Web gettting value out of their participation?
Travis: Intuitively, no.
Tim: I want to write apps to e.g., send data from the car to my server. Tell my family where I am, for example.
Mark: Will they let us do that?
Tim: If not, people will velcro iPads over these screens.
Alex: In theory, they get access to a large community of people to create value for their screens. Barrier to entry to become a developer is lower.
Andrew: One issue is how the browser comes to be running on the car (embedded, or a container OS). Car manufacturers and browser vendors have different ideas of development velocity.
Dan: I'm hearing two conflicting visions. Thinking about automotive, we talked about the use case where you sit down with your device into a car, and it connects to an API to get engine control info. That could easily support Tim's use case. The other vision is that there's some kind of built-in display in the car like a TV-embedded browser, to produce the next generation of in-car display; it's not open to third party development.
Dan: The second thing doesn't sound interesting from a TAG perspective.
Tim: They may have both.
Automotive CG's use cases: https://www.w3.org/auto/wg/wiki/Use_Cases
Hadley: The danger from the Web perspective is that if it's done in the black-box way, the first use case isn't possible. We wouldn't want them to pre-empt future interoperability.
David: You don't want the W3C standard for this thing to be designed for the walled garden use case, and hard to work with the security model for working with arbitrary web content.
Dan: What are our next steps with the Automotive group? Travis?
Travis: Yes.
Peter: They came to one of our calls.
Dan: Should we send them something?
Hadley: They went away saying that they were going to redo their approach. We're waiting for them to produce a new draft. Do we need a general resolution? Eg: Closed, highly controlled Web environments are considered harmful to the future of the web. A closed application environment that uses open web platform standards is not the web. Capabilities such as access to sensors, automotive, TV, toothbrushes, etc... should be designed in the context of the open web, or to be useful in webby ways, rather than with the mindset of a closed “embedded browser.”
Hadley: Use cases:
a. the data could be useful on the Web, or through Web approaches
b. the Web architecture would/could make this data (re)usable
c. projecting the Web to your widget (ie., stand-alone web browsers)
d. adding your widget to the web (ie., new toothbrush exposed to the web)
Andrew: You want to use the web technologies in/with your hardware thing.
dka: If you are a device manufacturer, and you want to create a spec for your device, then you should do it in the context of these principles:
Andrew: Our concerns for how this interacts with the Web:
Openness - We prefer exposing data to 3rd party user agents rather than embedding agents into sensors, actuators or other hardware devices.
Modernness - Any web browser runtime that is able to consume content from the open web should be updated (and updatable) independently of the hardware device to which it may be attached.
Alex: A good goal might be to have some guidance for folks who are thinking about exposing new things to (or through) the web. Lots of new hardware includes browsers and these new "browser makers" might not share the values that existing browser/standards engagement has created. Explaining both those norms and how they evolved might help, also perhaps some API design guidance for folks who find themselves in this situation?
Scenarios:
- Embedding web runtimes into new environments (i.e. "put a browser on it")
- Exposing new APIs/capabilities to existing browser-based experiences
- Shipping new combinations of hardware/browser that might presume a fixed software stack that doesn't evolve as the content evolves
Alex: We could review the different use cases. If you have a widget... Use cases include: Projecting the web to your widget. Pulling data from your widget. (etc)
dka: don't make the same mistake we made with the mobile web, assuming these devices wouldn't have browsers in them. Now they all do. I think the same istrue with connected TVs. And possibly automotive... TimBL was talking about Tesla. Won't se see more cars receiving over-the-air updates?
Andrew: but the replacement cycle for a car is much longer than a phone
timbl: does it matter for updating the software?
mnot: If you are a browser... that's one update approach.
alex: advice for API design... when you want to expose new hardware that isn't yet portable outside your environment.
timbl: If car radios, now often therei s a 2 DIN slot. The idea was you could change your radio. We could evolve to changing the computer in your car.
mnot: I could use my mobile device, which I update/replace often.
peter: Most modern cars don't have that 2-DIN model. It's now all custom and proprietary.
mnot: The only standard now is the OBD-II, the little port under the steering wheel.
andrew: this could work like a bluetooth interface. I can replace my headphones, but still connect to the same system.
Timbl: I find bluetooth unreliable.
peter: it's getting better.
Travis: Browsers have such an array of APIs exposed at the same level, you almost want to have a degree program for sets of APIs, to prove competence. Maybe modularity of some of these things would be a good thing.
alex: ES6 modules isn't a thing yet; needs refactoring. For DOM APIs, we don't have any concept of that.
Dan: I tried to synthesise a resolution.
alex: I think it's still unproven that we can make good HTTP APIs... You would treat, if you want to expose things as APIs, as though they are things that live at a URL. But what goes inside that HTTP message...?
mnot: JSON schema? There are proposals in the IETF... but people are reluctant right now.
timbl: One of the nice things about RDF is it uses XML schemas... One of the issues with JSON is it doesn't have things like decimal
timbl: One you parse an RDF or XML something which has got a decimal in it... A good def in a language says "this is a decimal". But I'm disappointed it isn't in JS. There are temperatures, and amounts of money and very little else.
travis: where that data is processed in a browser, it's processed by JS
mark: a lot of our evangelisation efforts target people who are already Web developers, but this is something different; it's on-boarding people who want to add the Web to their non-Web devices / capabilties
Alex: for new browser vendors
Andrew: So far we've had 35 responses. I haven't prepared a summary yet.
Raw results: https://www.surveymonkey.com/results/SM-BXL6Z28S/
discussion of results so far
Ideas for making "meet the tag" better: - Picking topics ahead of time - having a list of topics we want to hit - could be a cleaned up version of the f2f agenda - Moderator prep - maybe a document we share with moderators - Coverage - recorded in some way - could be just asking one of the attdnees to write up notes - Potentially move to a notional fee - but where does the fee go?
Alex: HBBTV are specifying a subset of the Web platform. They're attempting to capture a "baseline" of what the Web can do, probably to use as acceptance criteria for a certification programme. It's called the Web Standards TV Profile. TV specs are referencing this. It references a 2012 version of EcmaScript 5.1. Everything else is just as out of date. All of ES6 is missing; all of WebGL is missing. There's nothing about WebRTC or ORTC. There's no ServiceWorker support. Canvas2D is marked as "not mandatory". There's more. I think we need to have an opinion about this document. HbbTV is only on instance.
Hadley: How much impact would our opinion have? Are people asking?
Alex: Having something to point to would be useful. There are additions here too; e.g., a new set of keyboard keytypes (for use with remote controls, presumably).
Mark: People tend to create profiles when something is a mess, and/or when they don't have any control over it. They want to put a sheet of glass over it so they don't have to think about it again.
Alex: They have been successful in making people not think about it again.
David: No DOM.
Alex: DOM is implied because of JS.
Mark: Where is this at?
Alex: HBBtv is in the wild; they're looking at version 2.
Mark: So we want them to start to converge.
David: Are they shipping frozen Web engines?
Alex: I assume.
Dan: What manufacturers?
Hadley: OITC transferred its specs to HBBtv.
Dan: BBC; Opera. What's Opera's view? Samsung.
discussion of next steps; agreed to reach out through the liaison
Mark: New working group in ietf called capport - define the problem and come up with solutiuons. I've written a draft problem statement. [we have some captive portal vendors]
Andrew: What would ideal solution be?
Mark: I've brought up the position that we should think before we create a smoother experience for captive portals (because we will encourage that). I've been seeing more public wifi networks that don't have captive portals. If we enable this then we will see more captive portals.
Tim: It also provides money e.g. to the hotel's restaurant...
Andrew: the wifi on the Underground has mandatory captive portal that just shows you an ad. It's an advertising intersticial.
Tim: You're not sure what the ideal would be. One ideal redesign is that the DHCP contains the info of what you [need to view]?
Mark: a new RFC that specifies how to do that - a DHCP option that carries a URL. Problem is that they standardized that without engaging with anyone who designes captive portals. Those vendors haven't adopted so far.
Andrew: if the primary use case for the captive portal is payment that's one set of needs if it's it's advertising then it's another...
Mark: so many techniques used for interposing the captive portal. It's a mess. Some people in the wg want to standardize something for non-browser clients. But most people do want to get [ui] in front of the user.
Andrew: Another case - I can't use my kindle [in a specific captive portal] because it can't interact with the captive portal. So would you be able to do the necessary negotiation on one device and then benefit from it on another device.
Hadley: How organized is the pro-captive-portal lobby?
[they're not in the room or if they are they're not participating]
[discussion on whetehr venues are moving to captiveless wifi or not]
Andrew: it varies geograpically.
[discussion of if it's illegal to have open wifi in some countries]
Andrew: in the UK captive portals pop up more frequently.
[consensus that captive portals aren't going away...]
Tim: one reason why wifi providers dont want to enable auto-login is that they have a limited capacity and they want to make sure [you are only using the wifi if you are really using your device].
[discussion on various airline lounges]
Mark: we have 2 sets of implementers who are not well aligned now.
scribe: Hadley
Alex: We're close to done with v1. Most of the issues we'll discuss in Redmond in 2 weeks will be for v2.
... Big issues: Shared workers and sub workers. Should "just work", but there are issues on lifetimes of attachment. Service workers have a different lifecycle than other workers.
...The addition of foreignFetch... adds a bunch of interesting new opportunities for how you might design APIs. Integration of modules and module workers are coming, maybe v1. We don't want it to block anything already done and shipped.
...The cache API... we've had a bunch of questions on how success and failure work, esp with HTTP status codes. If it's a 200, put it in cache. What if it's in 400 range? There will be work on some sort of an API to queu up large background downloads. e predicted, but haven't had demand yet, to start a download, allow the service worker to get out of the way, and then once you get to an error point or completion point — wake it back up.
dka: What's the user need?
alex: "I want to download this movie." Without a service worker, you have to tie the download to the page. We want this API to be split in parts: one is an event sent back to the service worker to say "hey, this is done."
travis: Doesn't tehre still need to be a foreground page open for that to work?
alex: To start the download. But from a permissions perspective — the browser could let you pause, for example. These are open issues, not designed yet.
...There are bunch of things punted to v2, not useful for getting the spec to CR.
...The whole spec moved to bikeshed recently.
... Re: foreign fetch. Basic idea: today, service workers allow you to handle . If you have a document for example.com, and you make a request for a cat gif hosted at example.com, and a 3rd party image (advertisement) from that page — both flow through the service worker. That means the third party (cdn.example.com) won't have a way to manage its own cache on the device. Its service worker won't be part of the conversation about subresources. WEd' like foreign fetch to let CDNs... like font CDNS, which can't fail fast today... so what most CDNs want to do is grab a subset of the total glyphs and then stitch them back together on the fly. Grab the ones they don't have. They don't want to replicate their font into every other service worker cache or uniquely identified global cache.
dka: Can't these be cached like regulatr things in the browser?
alex: Today, they are.
TimBL: Why was this not done originally?
alex: the service worker caches are per-origin. If I have one at example.com and one at foo.com, we can't know at request time that they are going to be the same. The HTTP cache hit rates are lower than we'd like. They are large, so there is pressure... and the CDNs want to improve the performance and reliability of these "asset management" questions.
travis: CDNs aren't even in the picture for service workers since they're not hte origin.
alex: They could be included... everyone could include the Akamai script for example, for that origin.
hadley: Are you then adding a CDN domain to an origin?
travis: you're adding it to the origin
alex: So these third party services can be CDNs, or analytics... In a foreign fetch word, you can simply have hte analytics provider do their own offline requests
mnot: Generally, third party performance is a big issue. In the long term, QUICK is also going to help with that
timBL: We've been talking about net APIs and javascript APIs... this is another sort of API. It's a software module with its own API.
alex: yes, and it falls back to HTTP. There's nothing about it that isn't HTTP
timbl: If I have a bunch of arbitrary computational routines, and I want to use this for javascript functionality.... If I do some foreign fetch and the service worker does what I want, then I've important a piece of javascript.
alex: at the level of files, yes. At the level of HTTP requests, yes. Service worker can already do that — but this is mostly about third party coordination. You don't want to trust the third party infinitely, and they don't want to trust you infinitely.
timbl: service worker is just for a particular domain.
alex: [goes to the whiteboard] Any tab open to a.com can talk to a service worker for a.com in the user agent Through a.com's service worker, I can also fetch a resource for b.com. If it's CORSed, the a.com service woker can read the b.com content. If not, the a.com service worker will see an opaque response. You may not want a trust relationship between a.com and b.com. But you might want b.com to install its own service worker after (closer to the network) a.com's service worker. If so, the b.com service worker would decide what to do with the resource.
timbl given that normally the browsers have chosen to make a.com as 'in the dark' as possible... you odn't want people fishing for whether there is a service worker or not. You don't want the local javascript to discern whether there's a secondary service worker.
andrew: if there is no definiteve signal to the a.com service worker, is it a trust relationship?
alex: if either service worker isn't there, it all still needs to work. It falls back to HTTP, as if it were a normal fetch to the network.
alex: This is a generic thing that opens up the ability to do different things.
timb: If your'e getting a graph of your bank balance then one of the ways to do it is to get a picture that is interactive, in a piece of hte website like an iframe.
alex: iframes are already covered by service workers... it would have its own.
timbl: If you think of these things abeing computed rather than just dumb data?
alex: There is a lot of slow background work, like analytics pings, happening all the time. For example, if a.com includes an alaytics script from b.com. It would be good if the script was cached, and if it were used often... We see chartbeat a lot. It's constantly polling and reporting, which is terrible for performance. It could install a servicd worker and batch up the data, and send it at some interval rather than (essentially) constantly.
travis: Is it a.com that has to install the foreign fetch?
alex: No, therei s a link header that goes to b.com and prompts it to install a service worker. Or you could do the "iframe dance".
andrew: This has potential use for polyfill i/o service that I maintain. I operate a CDN service that varies based on user agent, which is a bad idea typically. But this would allow you to do that variation only to the client.
alex: which is a computed response, as per TimBL's comment.
...For the fonts case — a.com might be requesting some rang of unicode of characters from some font from b.com, and then the next request might be overlapping. So what you want is for it to stitch the two results together, and then fetch the deltas. ...Sandwich does some delta encoding, but this could help.
mnot: We did delta-encoding for HTTP about 20 years ago, but this seems to be doing it with application knowledge which could make the difference. Patrick McManus did it... the RFCs are by Jeff Mogul. It's a layer between content encoding and transport encoding.
timbl: logically, it's like a patch?
mnot: yes.
andrew: I've seen people use range headers on this sort of thing.
mnot: Yes, and it's a mess.
dbaron: especially with fonts, there is a CSS feature deisgned for this but it's only impelemnted in 2 of 4 browsers. Unicode range.
alex: Yes, but it creates another problem: different sites may request different subsets. You want intelligent stitching.
dbaron: Google Fonts would split the font up in different ways so you have a relatively small file to fetch.
alex: Yes, empirically they wanted that to work and it hasn't.
dbaron: and HTTP/2 won't fix it?
alex: They want the eb service to be dumb... hasn't worked out.
dbaron: This sounds a bit messy because you want a bunch of type ranges in the font
timbl: What kinds of requests can the service worker make?
alex: It can do whatever b.com can do, in the background
timbl: It could write a font generator?
alex: Yes, you can already do some of that with service workers — if it's the same origin.
dka: Alex, you expect to be discussing/agreeing this at the service worker f2f then?
alex: Yes, foreign fetch, latent questions about background sync. We've just launched this in chrome. One shot background sync Use case: "I want to send this email — don't lose it." It would be better if the browser told hte user if it worked or not, and then tried again. A few hours later — much more contentious, as a use case.
...The way Apple does their cache strategy wouln't work; they'd need different copies of the service worker. Given the way theyv'e done cache sharding... a.com and b.com logically get separate caches in safari. They're worried about timing attacks, tracking users by watching how long a particular resource is available.
timbl: but if you put resources into that... If I'm moving money between my bank accounts, and the service worker is doing the sync with the bank, I want it to be consistent.
alex: the only question here is the Origin Relativity Principle. It suggests that the service worker for b.com from a.com must always be coherent. But c.com might see a separate instance and separate storage for b.com.
.. This still means a and b are separate, they don't have to have a trust relationship.
timbl: If a.com is an etherpad... we do need consistency for everyone using the pad. I'm thinking about this as providing a modular programming functionaility.
travis: that implies the service worker will have to maintain an always-on relationship ...The old shared worker model would work. If you have multiple tabs from a.com open, they should have access to the same cache.
alex: and that's the case with service workers. All my a.com tabs will see the same a.com service worker. But none can see the chain (including b.com's service worker). That might expose tokens embedded in URLs for b.com, for example in a redirect dance to establish cookies — which we assume today a.com will never see.
timbl: but it also means if you're writing code and you want to find out what happens... you have six different URLs in a redirect chain which are in effect canonical.
alex: Yes, you're correct — the goal here is to hide some of that info. We can tell you here it was a redirect.
timbl: we don't know which redirect it was, what those intermediate steps were. The code in firefox used to keep track of redirects that were equivalent, and if someone tried to use one it woudl prevent the user agent from injecting info into it.
alex: you'er already using a privileged context
travis: woudl the data still be useful if they were just the origin?
timbl: no. A lot of linked data stuff uses redirects — If you look up dbPedia for Barack Obama, you'll end up at a SPARQL server. Sometimes it's logically a thing, described by this document.
travis: you could optimise by jupming to some intermediate stage of the redirect chain
timbl: if somone later on refers to anhthing in the redirect change, you will know they are sameAs.
travis: you can only build that up by doing it
hadley: Unless they are explicitly marked as sameAs
timbl: For example, 301 and 302 are different. One says "I want you, today, this second, to fetch this version of it" and the other says "the URI you're using is wrong — change the link". Anyone using that needs to have feedback sent to them.
travis: both of those status codes are cause for redirect?
timbl: yes, and there are others for "removed".
[Review of HTTP status codes]
mnot: It would be nice if there were something that explained it's not a simple thing to expose.
andrew: if we're only concerned about temporary redirects... can we treat canonical redirects differently?
alex: we went for "as conservative as possible" to ship this. Would be happy to take that as a bug, going forward.
timbl: When we're talking about alternative security policy — at some point we'll need apps that can handle this.
alex: once you've created a totally priviledged path, or busted out of the same-origin model — the gloves come off and anything's possble.
dbaron: It's the sort of thing where — even though you say "the right way to do it is to use a 302", somebody will inevitably use a 301 and expose security vulnerabilities on their site
andrew: they can patch it. I'm strugging with timbl's use case though — why are you keen for that info to be exposed?
timbl: generically, a reditrect in the semantic web world says "this is the same as that". That's generic, and you can accumulate that. People build redirects to create efficiencies, or to go from one system to the next. It's such a generic thing — lots of different examples.
.... When I do fetch, my HTTP client is talking to the server. I'm trying to communicate between two programs. I'm using HTTP, but if something has moved I should be told so I can know, change my caches etc. I should be able to extend HTTP in unanticipated ways. The fact that fetch keeps you so much in the dark — is bizarre.
mnot: We discuss this a lot in HTTP workshops. Do we design HTTP just for the browser? We conclude we can't focus on just one community — but we do think they hold a unique and privileged position.
...Am I right in that most of hwat you want is debugging?
timbl: No, it's more principal than that. It's not just debugging, but also taking action on that in real time.
andrew: it feels like the intent of the server isn't clear cut, based on the response (error code).
mnot: A 301 permanent redirect doesn't mean you consider the URLs equivalent in the cache. Resource a is saying this, but resource b may not agree with that. It's one-way.
dka: Do we have feedback for the service worker f2f next week?
timbl: It's a general issue, disempowering. It would be useful to let the caller know a redirect has happened.
alex: Letting the caller know a redirect has happened — that's happened. The service worker can hide arbitrary work.
hadley: If all this is transparent to the user agent, doesn't that fulfill the value of seeing the full redirect chain? In terms of correcting 301s, etc. Why do we need a.com to know that b.com has a redirect chain?
timbl: It doesn't behave like the Web. ... b.com service worker is liek a script from b.com
alex: no, it's like b.com had installed a proxy on the local device that can only respond to requests that would have otherwise gone to b.com.
timbl: Can it do DRM, for example? Decryption, hold the keys in a way that a.com can't see?
alex: Yes.
dka: So: a message of concern from the TAG to the service worker f2f next week?
alex: I'm still struggling to understand the issue.
dka: Where a.com is coherent with everything, the b.com service worker isn't.
alex: the b.com service worker has a unified view of the world — from b.com's point of view.
timbl: and it can make CORS requests. It can decrypt copyright material and hold the keys locally. It can operate on behalf of a.com
dka: Is b.com's service worker aware it came from a.com's service worker?
alex: no, it will know it came from a request from a document at a.com ...b.com gets to do more than simply record the fact that it got requested.
dka: Without solving this problem here... the people expert in service workers are meeting next week. Is there something we can tell them to pay attention to? Can we try to formulate something over the next two days?
alex: Sure. Tehre will be a lot that fall out of this capabilitiy. The lifetime of these, the relative durability, etc. There's a lot we don't know yet.
timbl: We we talked about the DRM blob, it is sandboxed. It can't send info back (which bits of the video someone likes). Here — is there something similar? The privacy issues will just be something like webRTC's issue where the foreign service worker knows a lot the system, can sit there long term. Keep track of when your laptop is open and not.
dka: Yes, could be used for tracking
alex: It will ahve the same lifetime as a.com's service worker.
timbl: But the a.com service worker is trusted. The user asked for a.com. That's different from whatever b.com wants to do.
dka: What are the advertising and tracking use cases for this?
alex: I'm not too concerned because most of the use cases we've talked about, there is already a coordinating script running at a.com (like font CDNs). A lot have moved aawy from scripts and are using CSS includes instead.
timbL: but you're thinking about the design and useful use cases. But what aobut the malicious ones?
alex: That's generally not an expansion of authority. b.com (analytics scripts, etc) are already embedded already.
dbaron: You might be able to get it installed for other things not using a script now?
alex: Sure, like giffy. Third party gifs.
...It's a good point . We do need to think about it. But the point here is that a.com did something, and asked b.com to do something. And what b.com can do once it has a service worker. We are thinking about a document that describes the potential authority.
dka: Let's crystalise this over the next two days, to take to the Service Worker F2F. They can reply.
dka: Also, re things (watches and wearables) — I've been wondering how service workers apply to those. Especially those that have displays, can run a web environment but won't allow you to type in a URL.
...Hypothetically, when you install a web application, the service worker gets installed on your device (phone) — but if there is a companion web application that wants to run on your companion device (watch), it may install another service worker on that companion device. The service worker on the phone has a master/slave relationship with the service worker on the watch. Thoughts?
Alex: we've plaed with, in the mainfest format — . There's a start URL that you specify (home screen, what gets launched.) You could imagine similar entrypoints in the manifest. A set of android widgets, for example. A set of web pages, pointing back into the same app. ...But there is a lifetime management question: does the application launch when you @@@@@?
dka: Well, if you have a weather app on the watch, the phone is doing all the processing. and where you make the config choices (what cities you care about, etc.) The watch is acting as a slave display.
alex: I could imagine a few targetted additions to the manifest format, plus foreign fetch, getting you all the way there. The app fetches, through a URI specific to the watch. The manifest format could enunciate which "views" you want to expose. ...If I install the weather app on my phone, I could see a list of the companion watch apps.
dka: You might want the watch to be able to sychronise locally stored data with data on the phone
alex: Yes, which is why foreign fetch looks like magic. The system could be providing foreign fetch handlers too.
dka: Transparent to the web run time, it's sitting on the watch.
mnot: you're operating at a very abstract level; it's not about HTTP or DNS...
alex: Not really. If you loaded that app with dev tools, it would run as fetch and go all the way to the network. So it would be HTTP semantics.
*** break ***
Peter: Not much happened since Melbourne. There was a f2f afterwards, just working through problems on a lot of things.
...There was some progress on the layout API. Scrolling extensibility
...FPWD on worklets, Paint API (custom paint)... they're the most advanced.
alex: are there implementations of custom paint yet? Or worklets?
dbaron: I think chrome has some prototypes... not sure how far along. For worklets, probably needs someone really into ecmascript to read it and review very closely.
alex: That sounds like be Domenic or me.
dka: Any TAG feedback needed?
plinss: No
travis: this seems like it's about implied trust.
dka :is there a proposal on the table that implies trust based on wehther an app is using a service worker or a manifest file? I thought those were off the table
alex: There are some APIs being designed with the notion of site engagement, or karma... the notion that users engage with some sites more than others. There is no API for installing to the home screen. We want the browser to know you've been to a site enough that it isn't spammy to ask if you want it on the home screen. User engagement as a way of lifting things up out of the muck. ...But generally, no. No "exotic" powers that break the origin model, or don't require strong user consent to access things.
travis: do extensions factor in to this conversation? They are usually ultra powerful, have access to any origins, proport to act on behalf of the user, run in all the privilged context,s and have to be installed through some kind of brokered process that asks for trust. You can't have a drive-by extension install.
...There is an Extensions community group.
timbl: That's interesting.
andrew: what are we hoping to get from this discussion?
dka: good question. Is there specific work to comment on right now? ...When we had the original idea behind installation of a web app was that there may be additional permissions associated with a web app, like it shouldn't have to ask your permission to see your location every time. But the web platform has moved away from that. Even if it's installed on your home screen... We had this discussion in the TAG a few years ago. Should a web app installed on your home screen be any different than one running in a browser context across the network? We decided no, it should be the same.
timbl: I think this breaks the same origin policy. (If you want a Web app to be as powerful as a native app, you have to break the same-origin policy.)
dka: Right now, a web app is a web app. It comes from an origin, when I tap that icon on my desktop, it's still coming from that origin. There might not be a service worker associated. The same origin policy extneds to progressive web apps.
timbl: If you install a native app it gets full privilege.
[Group reviews previous discussion from 2014: https://github.com/w3ctag/meetings/blob/gh-pages/2014/09-london/09-30-minutes.md ]
andrew: if you were to change the security model, what would you attach that to? the whole idea of "installing" is nebulous. Is it having an icon on the home screen? Is it having its own context?
timbl: it depends on what permissions you give it. ...It's comparable with the permissions model that native apps have. So you treat it like native apps.
andrew: so you bake it into the install flow. So you prompt the user with a permissions dialogue that says, "this app will now have access to...."
timbl: Yes, something like that.
andrew: it essentially mirrors the process of installing an extention. It's essentially a same-origin breakout warning, in user speak. ...But I'm not sure what you attach that to. The request from the web page to be installed? Would you define the fact that you wanted multiple origin permissions in your manifest, so it asks the user?
timbl: I think we dediced it's better if the app asks for them when it needs them. More relvant to the user.
andrew: Would it only ask when installed?
timbl: Browser vendors pushed back very hard on asking users.
travis: you want to avoid friction between users and running their apps.
andrew: I think the risks of breaking the same-origin policy (by the user agreeing to everything) are higher than benefits to the user could be here.
travis: you almost have to write up a website that assumes use of the permissions, test all that functionality out, and then you have a dumb version of hte site that has no access to that.
andrew: websites can be pretty smart without breaking the same origin policy. Not often that it gets in the way, as a publisher.
timbl: A data browser would be one use case. Or a validator.
alex: in media, there is a tangled web of mitigating concerns that makes you liable for broadcasting royalties.
timbl: The proxy is also a massive security issue.
dka: One meta-point here is that we have been doing a lot of work, including service worker, permissions API, etc. to bend around the fact that we want web apps to be more powerful, to invoke device APIs (bluetooth, geolocation), — to be as powerful as native apps but still respect the same origin policy. So the web continues to meet its promise to the user of being a safe environment, not a vector of malware and spam (as much as native apps or extensions). and be as capable as native apps. ...For use cases like data browsing, could we imagine that working and still respect the web security model?
timbl: No, not without cheating. Putting in a proxy, which means your webapp has access to anything that runs through it. (If they run the proxy behind the firewall, then they're in trouble)
travis: In the limit, we could bring all the great capabilities that native apps can do, on a client, to the web in a safe origin-tied, with permissions prompts — we could eventually get them all. At that point capabilities are off the table, at which point data access is the next blocker, as Tim is saying.
alex: Take web bluetooth for example where we highly constrain on the web platform, compared to native: bluetooth before, and only speaks GATT.
travis: native can have low-level access to the hardware. We don't usually want web sites to do that.
andrew: except if we ask for consent.
mnot: with web sockets, you shorted the web security model.
timbl: You have to do all the things native apps can do. Permissions, etc. AT the moment, who looks at the list of sites they've enablied pop-ups from? ... Suppose I want to write Quicken. I want it to access all my bank accounts, by logging in with my credentials, but I don't want it to share it with the origin where I got the app from.
andrew: there is precedent in this already in extensions. You could build Quicken in an extension. ....So you could say, apps that are installed on the home screen are extensions.
dka: We're talking about proxies or general proxies — but in fact, I think right now that works by you going to your quicken; you might use a web browser to access quicken, but you use something like OAth to have quicken access the back end service of your bank.
andrew: But timbl is talking about sending a request directly to quicken with cookies, and you can see the request in your extension
timbl: Yes. And there is no home origin. Just an app of local data. When you downloaded software on a floppy disk in the old days... and installed it...
travis: it's the same kind of trust that you need to have low-level bluetooth API access.
dka: This is a different thing from the current view of progressive web apps. You have a web app, served over HTTP, exists at an origin. Using serviceworkers and the same origin policy, you can put more data into it — but it's still dependent on the app running somewhere else. ...Timbl, I think you're asking what security silo or origin would your quicken example be running under? ...We have a model for this: hybrid applications. Adobe Cordoba, for example. You build youre entire application using HTML and javascript, but you use Cordova to compile it into a native app container, using the same mechanism like a web view — but it's all local content using web technologies. ...That exists; but they have the same problem as other native apps — they need to be downloaded from an app store. Because they have an enhanced level of security, you want to have a gatekeeper to be sure malware doesn't get through that gate.
alex: Question: the systems we think are safe, that we give people access to — do they actually work? From my experience of the Android ecosystem ,they don't keep users safe.
dka: iOS too
alex: Chrome extensions system doesn't keep users safe either.
andrew: Users say yes when they shouldn't.
alex: Developers use someone else's SDK but don't look at what it does. Or buy apps from original authors and tweak them. Not clear what's running.
timbl: A policy response would help here.
alex: yes ... They've all done a better job than previous attempts did. But I don't think an install-time list lf permissions for consent, which you can't revoke, works. Android has moved back toward the web model, asking for permission at runtime. ...The web model is the safest model that anyone has come up with so far.
timbl: But it doesn't allow you to write a web browser.
alex: I want the capabilities, but I don't know right now.
timbl: Go native. Chrome is a native app, and it can access the whole web. If you ran it on iOS, and every time you used it asked you "are you sure you wqnt this to access every part of the web?"...
travis: I believe in trust not being static. Based on organic experience of customers using apps, in compbination with reputation... can respond in real time, shut down if needed.
andrew: Feels like it should all be possible
alex: A few years ago, we looked at using the packaging format, signed, CSP — set a permission of "you can't talk to anyone else." You'd be running effectively at a null origin, like extensions run today. No shared storage, no shared credentials. They can't access the web as you if you've logged in in another tab. You wouldn't have the ambient authority.
andrew: which, to be fair, you couldn't do in a native app either.
timbl: Well, in a native app you can access keychain.
alex: but password autofill should work.
andrew: What you're saying is, the friction should be fairly small.
alex: Yes; it'd stil be an install process.
timbl: If Quicken would put itself forward as being benevolent, and there is a reputation system behind it... The developer always imagines they're making decisionso nwhat the user would want. If you make it easier for open source to get in there, because it's generally written by people who are trying to go good... Formal review helps, and someone's personal reputation as a developer helps...
travis: I don't think there's an algorithm that resuts in "good" or "bad" for apps. I think it needs human subjective input.
timbl: there are some basic things. Not allowed to advertise, or send data back to yourself.
andrew: why not advertise?
timbl: Many free native apps, ad-funded, use people's data horribly.
Travis: case in point — different definitions of "good".
dka: One of hte good things about progressive web apps — if your browser is already authorised for Twitter, for example, then your (hypothetical) web app that you download for FT would recognise that ambient authority. ...But what we're talking about is a cross bread between a progressive web app and a hybrid app.
andrew: Re the word "progressive". If you require this high level of access for your app to be useful, like Quicken, you can't progressively enhance to having this many permissions and add value at each level; an engagement slope. It's not progressive. It's replicating the current model of native apps, which is "everything or nothing." This is different.
travis: Was thinking about facebook... people thinking it's evil but still use it. Is ther a sliding scale that makes facebook less powerful for people who don't like it?
dka: One answer: some people who don't want to give facebook all those powers use it through their web browser.
mnot: I've seen that too.
andrew: We've mostly been discussing the high privilege stuff... Different case.
travis: It would be nice if there were a progression of progressive web apps that do build that slope of permissions.
alex: @@@@@ format completely incompatible with web loading. Clear origin, but when running with high-privilege it has to be cordonned off. ...This is one strawman for how to get there.
dka: does this fit in with our discussion of reviving web packaging?
alex: yes. I feel like this isn't the top priority on my plate though.
dka: I agree with that. But we're getting feedback.... @timbl, is the fact that webapps don't have the permissions — is one of the reasons native apps dominate in the marketplace?
timbl: Partly that, and partly frustration that they aren't more powerful. ...When we see people producing a non-native environemnt, building packages —
dka: maybe it's a sign the web environment isn't powerful enough for them?
timbl: Yes
dka: but won't they have to reinvent all the security we've put into the web?
timbL: No. If you load a package, you trust it. ... It's used by developers rather than end users
travis: If I hear about an app, and I can see ratings and what its requested permissions are before I commit — and it's a one step commit — I didn't build up experience myself with the app. I'm relying on others.
dka: Even native apps are moving towards a model where it asks for permissions as it goes. Abusing my trust makes me more likely to uninstall that app.
mnot: that feeds reputation
travis: there is also a reduced functionality mode when you don't approve access to the location — it shouldn't just crash.
dka: I suggest we create a work stream around packaging. When we first specced it out, this was one of the use cases.
mnot: Alex, you said you'd seen increased interest in packaging. Was this it?
alex: No. it's the opposite world — where the content runs with no capabilities whatsoever.
Yves: You'd use it for distribution of software, applications
alex: It's generally content, not-active content.
mnot: Roy used to say you could ship a CD with data to prime the cache.
travis: so it's not on the web
mnot: No, it is on the web.
andrew: I have a different issue with progressive web apps. Is it in scope to discuss to discuss whether it is a mobile technology? Every reference i see is about replacing native apps on the web platform. Touch, push notifications, background sync, home screen. Things you associate with a mobile environment and not desktop.
travis: Funny; we talk about the opposite.
dka: Isn't the whole point that build a progressive web app and it covers everything?
andrew: Are there good examples? People aren't getting this.
alex: A few examples. For those sites that do it, it's mostly happening in emerging markets. Desktop is also where the web, frankly, has won. I do my email in a web browser, not in a desktop app. For some set of use cases.
andrew: I agree. What worries me is that it's taken effort and time to convince people to move from a "multiple site" approach (m.example.com) to one response site. I fear we're now encouraging a multisite model again: a responsive desktop site, and (mobile) progressive web app.
alex: I'm a bit surprised. The Facebook desktop site, is one of the most progressive web apps in the world
andrew: but the mobile site is a different site.
alex: The desktop site is very successful. ...My goal is to encourage everyone to build one responsive thing, and the technology should work everywhere. The only thing Chrome hasn't done is the ability to add to home screen. Everything else is active. ...You may not notice them because on desktop, you tend to assume you're online all the time.
dka: It wouldn't actually be on your desktop, it would be just a figment on your doc.
alex: What's the difference between that an Start Menu entry, right? Just a link that invokes an executable.
Andrew: I worry about the expectation we're setting with developers.
alex: We're working as hard as we can on the chrome team to make sure web devs have the tools to build and test desktop apps.
dka: Getting the word out that progressive web apps isn't just about mobile — important.
alex: The prompt is there on chromeOS, when you go to a progressive web app.
travis: Back in IE9, we built a progressive web app experience where you pull something down and dock it. It would run as an app experience. It was prototype, but when we tested it we found that as soon as you click a link — you need to be in a browser for it to make sense.
andrew: this is a ral problem with oath flows. In the FT webapp, it will spawn a separate browser process for links to different origins. Needs a hack to make the flow sensible. If you take away the naviation buttons, you're limiting what the user can do.
travis: maybe that's a good constraint to take away when you give high-privilege access.
dka: linkability is another issue... Feels like browsers may need to address this separately. How you link into a web app, and how you link out of it — tricky issues. ...If someone on twitter shares a link to an news article from within a progressive web app, then I should be able to open it either in the browser or in my installed instance of the web app.
andrew: if you click on a tweet in a progressive web app, and it links to another progressive web app, — you go from whole screen of one to the other. ?
alex: We have pieces of this in place. In chrome we're a bit hamstrung by android. The things you see on the home screen are triplets, not APKs. To fix that, you'll have to change how android handles certain intents.
dka: other browsers in android? Dependent on default? Another potential confusion for users.
andrew: On desktop: two tabs, two different progressive web apps... How might they interact?
alex: browser question.
travis: there could be fluidity between the experiences. If you could transport not just the link but also the history, and it travelled together with the navigation... It could be seamless.
andrew: Pinned apps (https://wiki.mozilla.org/Firefox_OS/Pinned_Apps) Example of mozilla's approach to deep linking into web apps.
https://www.w3.org/2014/automotive/charter
hadley: If their charter doesn't conflict with the things were discussing this AM (architecture and device APIs) —then I think we're happy with it. At least, I am.
travis: +1
mnot: [reads out loud the charter] [finds the things that cause us concern] ...They've done a FPWD, have a f2f in Paris at the end of April. Mailing list.
agreed: they aren't under charter review right now. We'll engage with them on specific issues.
proposed charter: feb 2016
https://www.w3.org/2016/03/tvcontrol.html
mnot: AC review has closed... but there might be room for feedback, or to engage with the group when they get started
dka: Assuing the actual mechanism for these commands to be sent is via bluetooth... Is that mentioned in there at all? Or any relationship with the bluetooth API? ... sounds very specific to broadcast TV. ...Do we have specific feedback?
mnot: arguably, you could get an electronic program guide from the web already. ...Control and video source...?
travis: Is that in the webRTC arena?
[enter our illustrious GDS host, James Stewart]
dka: Well, it feels like bluetooth to me. Some TVs are heading there already.
mnot: I'm less concerned about these use cases being javascript APIs than I was with the automotive. I'm struggling to articulate why.
dka: Maybe because your TV doesn't traverse the on-ramp at 70mph?
timbl: Yet.
mnot: My TV doesn't hold a lot of data...?
dka: Well, all your viewing history. A big hook for advertisers.
mnot: Also... Web and TV interest group: one use case is ad insertion. And EME. They are working on a "cloud browser" to standardise split browsers.
dka: TV is coming up a lot here. TV control, HDR colours, web and tv, etc. Especially if we're talking about ads being spun into existing content...
timbl: on Friday the spec to make the toothbrush on the Web?
mnot: Should we spend a bit more time with the TV groups? My worry is that they don't have the web mentality, don't have a lot of love and attention from the TAG or the browser folks...
Proposed resolution: The TAG is concerned about the fragmentation of web / TV scenarios and work. These include HBB TV web subsetting of web technology specs, web&Tv working group cloud browsing, tv control API... We would like to
mnot: I feel like we should be friendly first, get to know them, before publishing a resolution.
dka: Maybe this is more an internal comment to the W3C team then? To encourage coherence internally?
hadley: with that many groups, we may be the only ones looking at all of those specs. Maybe the manufacturers, but that would be impressively joined up of them.
dbaron: It's possible the interest group could help coordinate. It's worked in other areas.
Yves: Yosuke Funahashi (W3C team) to join the meeting tomorrow morning (Weds), around 9AM BST.
mnot: mark watson did a piece on the landscape of entertainment, in the w3c. MIght be a good refresher. https://www.w3.org/2016/Talks/ac-slides/AC2016_Entertainment.pdf
https://www.w3.org/2015/hasec/2015-hasec-charter.html
dbaron: a number of issues were raised at the AC meeting
dka: One of the issues: if you have hardware that can be you on the web, it would a "super-duper app" that would cross the same-origin policy.
dbaron: It wasn't clear what some of the work items were. But also, there were previous proposals that looked like supercookies.
mnot: Also it looks ambitious for one working group.
hadley: what should we do with this?
dbaron: given that there were concerns expressed... it might not go through as is.
dka: Let's see what comes back after those are resolved and then comment on it.