task scheduler api?

[Robert Kroeger]

Hi Christophe,

I was wondering what you (or anybody else) would think about attempting to implement the task scheduler api (http://www.w3.org/2012/sysapps/web-alarms/) in blink?

Rob.

--
Robert Kroeger
rjkr...@google.com

[Elliott Sprehn]

On Wed, Aug 21, 2013 at 12:07 PM, Robert Kroeger <rjkr...@google.com> wrote:

Hi Christophe,

I was wondering what you (or anybody else) would think about attempting to implement the task scheduler api (http://www.w3.org/2012/sysapps/web-alarms/) in blink?

Has any other browser vendor expressed interest yet? The API looks pretty good, though it's a bit sad we're dropping more junk on navigator.

- E 

[Ian Hickson]

On Wed, 21 Aug 2013, Robert Kroeger wrote:
>
> I was wondering what you (or anybody else) would think about attempting
> to implement the task scheduler api
> (http://www.w3.org/2012/sysapps/web-alarms/) in blink?

Can't you basically do this with setTimeout()? The only part that you
can't do that with, the background-wakeup feature, seems like a scary
security risk and implies a dependency on:

http://www.w3.org/TR/runtime/

...which looks to not have a Web-compatible security model (looks like an
app model with up-front permissions grant, manifests, etc).

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Justin Schuh]

On Wed, Aug 21, 2013 at 12:25 PM, Ian Hickson <i...@hixie.ch> wrote:

On Wed, 21 Aug 2013, Robert Kroeger wrote:
>
> I was wondering what you (or anybody else) would think about attempting
> to implement the task scheduler api
> (http://www.w3.org/2012/sysapps/web-alarms/) in blink?

Can't you basically do this with setTimeout()? The only part that you
can't do that with, the background-wakeup feature, seems like a scary
security risk and implies a dependency on:

   http://www.w3.org/TR/runtime/

...which looks to not have a Web-compatible security model (looks like an
app model with up-front permissions grant, manifests, etc).

These are the first thoughts I had as well.

-j

[Christophe Dumez]

Hi,

Ian is right that the Task Scheduler API (like other Sysapps API) is targeted at Web applications and relies on the Runtime API [1].

The task scheduler API differs from setTimeout() as it allows Web apps to start themselves at a given time (similarly to cron jobs but for Web apps).

Kr,

-- 

Christophe Dumez

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Robert Kroeger]

On Wednesday, August 21, 2013, Justin Schuh wrote:

On Wed, Aug 21, 2013 at 12:25 PM, Ian Hickson <i...@hixie.ch> wrote:

On Wed, 21 Aug 2013, Robert Kroeger wrote:
>
> I was wondering what you (or anybody else) would think about attempting
> to implement the task scheduler api
> (http://www.w3.org/2012/sysapps/web-alarms/) in blink?

Can't you basically do this with setTimeout()? The only part that you
can't do that with, the background-wakeup feature, seems like a scary
security risk and implies a dependency on:

   http://www.w3.org/TR/runtime/

...which looks to not have a Web-compatible security model (looks like an
app model with up-front permissions grant, manifests, etc).

These are the first thoughts I had as well.

Thanks for the feedback. 

FWIW: the problem that prompted me finding this API was wanting to answer the following question: how does one implement a drive-by-web alarm clock webapp for a mobile web browser. 

I agree with Ian that this would be easily implemented via setTimeout in a tab on a constantly running device.

Speaking of background-wakeup: why is background-wakeup very scary until combined with other scary permissions (e.g. microphone). Navigating to a site automatically gives the site permission to (ab)use the computational resource on my machine provided the JS is reasonably well behaved (like in a worker). Is the concern that "sleeping" a device is a stronger promise to minimize battery use than switching to a different tab or application on the device?

Rob.

 

-j

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

--
Robert Kroeger
rjkr...@google.com

[Adam Barth]

On Wed, Aug 21, 2013 at 1:49 PM, Robert Kroeger <rjkr...@google.com> wrote:

Thanks for the feedback. 

FWIW: the problem that prompted me finding this API was wanting to answer the following question: how does one implement a drive-by-web alarm clock webapp for a mobile web browser. 

It's not possible.  Web apps don't have the ability to start themselves.  They need to be started by the user.

I agree with Ian that this would be easily implemented via setTimeout in a tab on a constantly running device.

Speaking of background-wakeup: why is background-wakeup very scary until combined with other scary permissions (e.g. microphone). Navigating to a site automatically gives the site permission to (ab)use the computational resource on my machine provided the JS is reasonably well behaved (like in a worker). Is the concern that "sleeping" a device is a stronger promise to minimize battery use than switching to a different tab or application on the device?

Background-wakeup has the same potential for spam as the notifications API.  I'm sure there's a way to expose this functionality to the web.  It just requires a bit more thought.

Adam

[Tab Atkins Jr.]

On Wed, Aug 21, 2013 at 1:56 PM, Adam Barth <aba...@chromium.org> wrote:
> Background-wakeup has the same potential for spam as the notifications API.
> I'm sure there's a way to expose this functionality to the web. It just
> requires a bit more thought.

I think we can just lean on the Notifications API security model, no?
Pop a bar when the site first requests to schedule an alarm, and just
expose the same functionality as notifications do. It's basically
identical to Notifications, except the page can be closed, rather than
just somewhere off-screen.

Tangential: "alarm clock" is a pretty weak use-case. A much stronger
one is just pointing to Google Calendar's existing notifications - I
currently have to remember to keep Calendar open somewhere if I want
any notifications (and I definitely want them). This would prevent me
from mistakenly closing the tab and missing something.

~TJ

[Adam Barth]

On Wed, Aug 21, 2013 at 2:24 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

On Wed, Aug 21, 2013 at 1:56 PM, Adam Barth <aba...@chromium.org> wrote:
> Background-wakeup has the same potential for spam as the notifications API.
> I'm sure there's a way to expose this functionality to the web.  It just
> requires a bit more thought.

I think we can just lean on the Notifications API security model, no?
Pop a bar when the site first requests to schedule an alarm, and just
expose the same functionality as notifications do.  It's basically
identical to Notifications, except the page can be closed, rather than
just somewhere off-screen.

Yes, it's also related to features like push messaging:

http://developer.chrome.com/extensions/pushMessaging.html

There's a whole suite of this sort of thing.  As things stand currently, that's all tied into Apps infrastructure, largely because it fits better into an Apps-like security model, but I don't see why we couldn't bring that sort of functionality to the web in some fashion.

Adam

[Robert Kroeger]

Assuming that the Notifications API security model is sufficient for the needs of push messaging (and alarms) is it better to extend the existing notification API for push notifications or create a new API? The latter seems cleaner and could conceivably include both alarms and push notification.

If this sounds reasonable, I'll try to write up a more concrete proposal.

Rob.

 

Adam

--
Robert Kroeger
rjkr...@google.com

[Adam Barth]

The current notification API is a bit of a mess:

http://kenneth.io/blog/2013/07/15/the-messy-state-of-web-notifications-in-chrome-safari-blink-webkit/

If this sounds reasonable, I'll try to write up a more concrete proposal.

Ideally we would clean up the Notifications API mess before piling on more bells and whistles.

Adam

[Ian Hickson]

On Wed, 21 Aug 2013, Robert Kroeger wrote:
>

> FWIW: the problem that prompted me finding this API was wanting to
> answer the following question: how does one implement a drive-by-web
> alarm clock webapp for a mobile web browser.

I don't think you do, currently.

Is that the only use case? I think I would be ok in saying that this is an
app that you have to do natively if it's the only use case (in particular
since it would require other big permissions, like waking up over a lock
screen, going full-screen, overriding the system volume control, etc).

> Speaking of background-wakeup: why is background-wakeup very scary until
> combined with other scary permissions (e.g. microphone).

Because it's a spam vector, a DOS risk, and a griefing risk.

Spam: A site can just register itself to come up every 10 minutes and pop
up another ad or whatever ("Virus detected! Pay us for a fix! You data is
at risk until you pay us!").

DOS: A site can register itself to reopen repeatedly, costing CPU.

Griefing: A site can register itself for years later, at which point it'll
pop up and the user will have _absolutely no idea_ what happened.

The Web security model right now somewhat depends on the invariant that if
you go to a site that you don't like, you can just close it and that's it,
you're done with it. If now the site can come back on its own, it's not
clear how you would close it. (Having two close buttons, or some such, is
not simple enough for many users to understand, IMHO. Open vs Closed is
easy to understand. Open vs Closed vs Closed-but-could-reopen-maybe is a
much more complicated model to reason about, as a user.)

> Navigating to a site automatically gives the site permission to (ab)use
> the computational resource on my machine provided the JS is reasonably
> well behaved (like in a worker).

Only until you close the tab, though. Then, it's _gone_.

On Wed, 21 Aug 2013, Tab Atkins Jr. wrote:
>
> Tangential: "alarm clock" is a pretty weak use-case. A much stronger
> one is just pointing to Google Calendar's existing notifications - I
> currently have to remember to keep Calendar open somewhere if I want any
> notifications (and I definitely want them). This would prevent me from
> mistakenly closing the tab and missing something.

Yeah, I think a more interesting model would be a subscription-style thing
where you can allow a site to push notifications (including scheduled
ones) to your device (or, for setups like Chrome-logged-in users, to a
user's account, all registered devices). It wouldn't bring up the site, it
would bring up a system notification, with the same "disable this domain's
permissions for notifications" as a Web Notification notification.

(There's also been talk of pushing down updates to caches or IndexDB.)

This would need a new spec or new feature in Web Notifications or similar.
I don't think it'd be based on the spec we're discussing here.

[Tab Atkins Jr.]

On Wed, Aug 21, 2013 at 4:29 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Wed, 21 Aug 2013, Tab Atkins Jr. wrote:
>> Tangential: "alarm clock" is a pretty weak use-case. A much stronger
>> one is just pointing to Google Calendar's existing notifications - I
>> currently have to remember to keep Calendar open somewhere if I want any
>> notifications (and I definitely want them). This would prevent me from
>> mistakenly closing the tab and missing something.
>
> Yeah, I think a more interesting model would be a subscription-style thing
> where you can allow a site to push notifications (including scheduled
> ones) to your device (or, for setups like Chrome-logged-in users, to a
> user's account, all registered devices). It wouldn't bring up the site, it
> would bring up a system notification, with the same "disable this domain's
> permissions for notifications" as a Web Notification notification.

Honestly, it seems frankly ridiculous to expect anything else, given
the obvious and terrible implications, of which you spelled out a few.

> (There's also been talk of pushing down updates to caches or IndexDB.)
>
> This would need a new spec or new feature in Web Notifications or similar.
> I don't think it'd be based on the spec we're discussing here.

The API currently defined in the spec has been hashed out on
public-webapps, and is fine. It's just the processing that's bad.

~TJ

[Ian Hickson]

Which one? I haven't seen either /web-alarms or /runtime be discussed on
Web Apps, and I don't see how either would work unmodified as a way to
send subscription-opt-in server-pushed scheduled notifications... Web
Notifications would also need a lot of additional material to support
server-push, as far as I can tell.

[Mounir Lamouri]

On 21/08/13 20:25, Ian Hickson wrote:
> On Wed, 21 Aug 2013, Robert Kroeger wrote:
>>
>> I was wondering what you (or anybody else) would think about attempting
>> to implement the task scheduler api
>> (http://www.w3.org/2012/sysapps/web-alarms/) in blink?
>
> Can't you basically do this with setTimeout()? The only part that you
> can't do that with, the background-wakeup feature, seems like a scary
> security risk and implies a dependency on:
>
> http://www.w3.org/TR/runtime/
>
> ...which looks to not have a Web-compatible security model (looks like an
> app model with up-front permissions grant, manifests, etc).

The background feature is something Mozilla and Google seems to be
interested to push to what some people call the "drive-by" Web via Event
Pages. Last I have heard of it, it would allow a webapp to have a shared
worker that would get resurrected (if needed) when an event will be
fired. The idea is close to the Chrome Apps API:
http://developer.chrome.com/extensions/event_pages.html

Last I checked, the only dependency of Task Scheduler over the runtime
specification is System Messages which I think should be deprecated in
favour of Event Pages. Especially if Event Pages have a security model
that works on the Web.

The only issues that prevents pushing Event Pages to the Web is related
to UX: how to make it clear to the user that a webapp might show up
again or do some work in the background? and how to allow the user to
easily disable this? Those issues are not easy to solve but I think it
is worth giving them a try.

Cheers,
--
Mounir

[Tab Atkins Jr.]

Sorry, it was on public-script-coord:
<http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0424.html>.

Web Alarms has nothing to do with server push; it's about web pages
registering notifications which can be delivered when the app isn't
running. I agree that addressing that would require more work.

~TJ

[Ian Hickson]

On Fri, 23 Aug 2013, Tab Atkins Jr. wrote:
>
> Web Alarms has nothing to do with server push; it's about web pages
> registering notifications which can be delivered when the app isn't
> running.

Right. But that's inadequate for basic use cases (e.g. it wouldn't even
handle Google Calendar).