Re: Life cycle and security model - status

On Wednesday, October 16, 2013 at 3:42 PM, Kostiainen, Anssi wrote:

> On Oct 16, 2013, at 1:07 AM, "Kostiainen, Anssi" <anssi.kostiainen@intel.com (mailto:anssi.kostiainen@intel.com)> wrote:
> 
> > - integrate with Task Scheduler
> 
> 
> I should have perhaps mentioned a couple of concrete use cases for this:
> 
> - A web-based email service that fetches an update from the network every X minutes, notifies the user of new mail if any.
> - A web-based calendar application that notifies the user of scheduled calendar events.

This is out of scope, as we don't handle timezone info.  
> > From the end user's point of view, the apps should just work even if the application/tab is closed.
> 
> 
> The app should be able to schedule new tasks without requiring to create a user interface, thus this or equivalent functionality needs to be exposed to service workers.
agree.  
> 
> Another related thing.
> 
> I'm wondering if we should try to make Task Scheduler compatible with the browser security model. A model similar to Web Notifications might work: pop up an infobar to get the user's consent to schedule a task, revocable by the user afterwards if needed. Do this either at the installation time [1] or when add() is invoked, or both.
> 
> I'd like to make sure evil.com (http://evil.com) can not abuse TaskScheduler by waking up the system every minute to show ads without my consent. This would be especially critical in the context of the drive-by web and service workers that can remain running in the background and can schedule new tasks without visible user interface.

I think there is a bit of a problem with this API in that we don't have a lot of clarity about how it would be used. 

In any case, I agree you don't want random sites scheduling tasks. Tasks that don't have an associated service worker would simply be discarded. 
 
> I agree this is partly an UX issue, that is out of the scope for the specifications.
> 
> Thoughts?
Permissions are going to affect all these APIs so we need to find a consistent model. Stacking API access requests is getting a little annoying, so we should try to address this permissions problem more fully.   
> 
> [It seems a functionally equivalent chrome.alarms API is exposed to event pages.]
> 
> Thanks,
> 
> -Anssi
> 
> [1] oninstall = function (e) { e.services['alarms']; };
> (as per the service worker proposal)

Received on Wednesday, 16 October 2013 16:29:04 UTC