[Credential Management]: Tiny prototype to play around with.
BCCing public-webapps@, as this proposal started there[1]. It looks like it might be reasonable to charter the spec work as part of the WebAppSec WG[2], however, so I'm moving the conversation here for the time being. Way back in August, I proposed a credential management API. After some generally positive conversation with folks at Mozilla and other vendors, I started poking at a prototype in Chrome to help us evaluate whether the API made any sense. As of some time earlier this week, there's enough in Canary to start looking at. If you visit https://credential-manager-api-test.appspot.com/ in Canary with the '--enable-credential-manager-api' flag set, you can save credentials via `navigator.credentials.notifySignedIn()` and retrieve them via `navigator.credentials.request()`. It only supports local credentials, and doesn't do any of the UI song and dance that's still very much TBD, but it's a nice proof of concept. Note: Don't do this on any profile with data you care about. The current implementation just blindly returns the first credential that matches the origin on which the API is called, without user mediation. That's probably not something you want to expose to the web in its current state. :) I'd invite you to take a look at the strawman proposal ( https://mikewest.github.io/credentialmanagement/spec/), and help me decide whether the API makes any sense. If nothing else, it'll give us something to talk about at TPAC. [1]: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0141.html [2]: http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0009.html -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: Push API and Service Workers
On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: This is very helpful. I assume the browser running the service worker can be a very light-weight version (or a subset of the full browser) since we don't need to render an actual webpage. Is that the right expectation? If you can split that somehow it might be somewhat lighter weight, yes, but I wouldn't expect that to be easy. I agree we don't want to display a notification for each push message. Meanwhile, for certain type of messages (e.g. realtime communications), we don't want to miss them or delay them, e.g. an incoming video call. I'm trying to figure out which of the following should be the right flow for the scenario. Please let me know if you see other options. I started an exploratory thread on letting the service worker open up some kind of window that could help with this, but I suspect it's still too early. (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? (1) will also likely involve a service worker or an even slower network fetch to get to the application, as I pointed out. -- https://annevankesteren.nl/
RE: Push API and Service Workers
On Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote: (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? (1) will also likely involve a service worker or an even slower network fetch to get to the application, as I pointed out. Re#1, most devices have native push client already which can connect to its notification servers in the cloud. I expect simple/generic actions can be defined without involving any script engine (or service worker). RE the slower network fetch, it might not be the best user experience on mobile devices if we open up websockets and prefetch the app page before the user consent (i.e. to pick up the call). Of course, it can be a developer decision if the spec (and web platforms) provide the options. Re #2, it'd be great if some folks could comment on the scheduling and latency question. Thanks, Shijun
Re: Push API and Service Workers
On 16 October 2014 08:55, Shijun Sun shij...@microsoft.com wrote: Re #2, it'd be great if some folks could comment on the scheduling and latency question. There are number of variations on how this all works out. And multiple sources of latency. A mobile device in a low power state follows a process that is approximately: 1. network pages the device 2. device establishes a network context (considerable delay in some cases here...I've heard 2s isn't unusual...gah!) 3. network delivers the push message 4. OS delivers to push service on device (some services may initiate a user notification at this point based on the message contents, but it isn't a default mode) 5. OS awakens a push handler (a subset of the application) 6. push handler runs code to determine what to do, which may be Steps 5 and 6 are entirely analogous to the service worker case. The problem that Anne highlighted is the risk that the service worker requires download and installation when the event arrives. I think that we should be recommending that push messages are run from a previously installed (and cached) service worker. Latency really matters here. We could, of course, get fancy and require update of the SW if it has expired from cache, or maybe allow update for messages that are marked low priority, but I'd consider that to be a second-order optimization.
Re: Push API and Service Workers
On 16 October 2014 16:22, Shijun Sun shij...@microsoft.com wrote: On Thursday, October 16, 2014 12:42 AM, Anne van Kesteren wrote: You need a browser to run a service worker. The browser is pinged and it might then decide to start running a service worker to process the incoming message, or maybe decide to hold onto it for a bit. If the browser is not running it might be booted, depends a bit on the implementation details. That will likely evolve over time. This is very helpful. I assume the browser running the service worker can be a very light-weight version (or a subset of the full browser) since we don't need to render an actual webpage. Is that the right expectation? Yes, the subset required by Service Workers consists of things like a JavaScript engine, network stack, local storage, and an implementation of the APIs exposed to Service Workers. But you don't need a DOM tree, rendering/graphics, UI etc. So the battery cost and RAM usage can both be reduced somewhat, depending on how modular your browser architecture is. Without service workers that application might not load fast enough over the network to take that call. Also, it seems undesirable to always get a notification for each incoming push message. It should just be a new communication channel for the application. I agree we don't want to display a notification for each push message. Meanwhile, for certain type of messages (e.g. realtime communications), we don't want to miss them or delay them, e.g. an incoming video call. I'm trying to figure out which of the following should be the right flow for the scenario. Please let me know if you see other options. (1) the Push Client displays a notification right away, the user chooses to pick up the call or dismiss, the browser launch with the app based on user decision. (2) The Push Client wakes up the browser, which start the service worker, which pushes a notification, then the user can decide whether to answer the call, the app launches based on user decision or browser goes back to sleep. Re #2, I'm still fuzzy about the schedule of the service worker, so ask the question again, would there be a delay if the service worker is not scheduled to run when the message comes in? I'm not sure what you mean by 'scheduled', but no. A key benefit of Service Workers is that the browser can start and stop them whenever it feels like. Thus Service Workers are usually stopped, and get woken up on demand to handle events like incoming push messages. In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than 100ms to handle the event when Chrome and the SW are already running. Since push messages aren't usually triggered by a user action (like a button click), but instead by some external event, these latencies are already likely to be imperceptible to users. (If you're interested in scheduling SWs to run periodically in the background, there's been a proposed Background Sync https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md API that might permit that; but that's independent from the Push API). Hope that helps, John Best, Shijun
Re: Push API and Service Workers
On 16 October 2014 11:17, John Mellor joh...@google.com wrote: In our prototype on Android, it takes less than a second (not yet optimized) to wake up Chrome from a cold start and handle the event in a Service Worker (the demo writes to IndexedDB and shows a notification), versus less than 100ms to handle the event when Chrome and the SW are already running. Since push messages aren't usually triggered by a user action (like a button click), but instead by some external event, these latencies are already likely to be imperceptible to users. If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations.
RE: Push API and Service Workers
On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote If the push message is being used to deliver a call notification, that sort of delay will definitely be noticed. And I'm assuming that you've tested on a high end Nexus or something like that. Add the latencies involved in waking an idle device and that turns into a very long post-dial delay. People abandon calls for that sort of delay. Not saying that you are doing it wrong or anything, but just trying to set the right expectations. The RTC scenario is listed explicitly as one of the use cases in the Push API wiki [1]. I expect there is enough interest in the group. Should we allocate some cycles in TPAC to figure out details of the E2E flow? [1] http://www.w3.org/2008/webapps/wiki/Push_API
CustomElement: Type extension on custom tag
Is it legal to register a type extension on top of an existing custom tag?
x-button is=x-submit-button/x-button
var ButtonPrototype = Object.create(HTMLElement.prototype)
document.registerElement(x-button, {prototype: ButtonPrototype})
var SubmitButtonPrototype = Object.create(ButtonPrototype)
document.registerElement(x-submit-button, {extends: x-button,
prototype: SubmitButtonPrototype})
Chrome's native registerElement doesn't seem to like this. It throws
the following error.
DOMException: Failed to execute 'registerElement' on 'Document':
Registration failed for type 'x-submit-button'. The tag name specified
in 'extends' is a custom element name. Use inheritance instead.
The current Custom Element spec doesn't say any specific about this
situation. Is Chrome wrong? Or is this something the spec should
explicitly disallow?
Re: CustomElement: Type extension on custom tag
Hi Joshua,
I implemented Custom Elements in Chrome.
In the definition construction algorithm
http://www.w3.org/TR/custom-elements/#dfn-definition-construction-algorithm,
step 8.2, it says:
If BASE does not exist or is an interface for a custom element, set ERROR
to InvalidName and stop.
In this case, BASE is the x-button and it is an interface for a Custom
Element. I think this is the case you're hitting. I think Chrome roughly
matches the spec in this case.
It's another question whether the spec could be changed to allow this. As
an implementer, I would need to know if/what order each of the callbacks
for x-button and x-submit-button were called in when something happened to
an x-submit-button. There are also interesting cases like what happens if
the x-submit-button is registered before the x-button, and whether other
things are possible like type extensions that extend other type extensions.
In short, step 8.2 avoids a lot of potential complexity by limiting what
you can do with Custom Elements in this specific way.
Dominic
On Fri, Oct 17, 2014 at 7:36 AM, Joshua Peek j...@joshpeek.com wrote:
Is it legal to register a type extension on top of an existing custom tag?
x-button is=x-submit-button/x-button
var ButtonPrototype = Object.create(HTMLElement.prototype)
document.registerElement(x-button, {prototype: ButtonPrototype})
var SubmitButtonPrototype = Object.create(ButtonPrototype)
document.registerElement(x-submit-button, {extends: x-button,
prototype: SubmitButtonPrototype})
Chrome's native registerElement doesn't seem to like this. It throws
the following error.
DOMException: Failed to execute 'registerElement' on 'Document':
Registration failed for type 'x-submit-button'. The tag name specified
in 'extends' is a custom element name. Use inheritance instead.
The current Custom Element spec doesn't say any specific about this
situation. Is Chrome wrong? Or is this something the spec should
explicitly disallow?
