Push Notifications feedback

[Jeff Balogh]

I posted about making push notifications for the web last week:
http://jbalogh.me/2012/01/30/push-notifications/. It's been getting a
surprising amount of press. I didn't offer a place to give feedback,
so gerv asked me to start a thread here.

The idea: let websites/apps send small messages to users when they're
not connected to the website. I think this will be most useful for
telling users about events: "You broke the build", "Bret wants to
party tonight", "Your mom joined Farmville", etc. Push notifications
are already in iOS and Android.

Current status: I made a prototype server
(https://github.com/jbalogh/push/watchers) and some prototype patches
for fennec (https://github.com/jbalogh/mozilla-central/compare/master...c2dm).
Neither of those are ready to ship; I just wanted to understand the
problem better. I've talked to dougt and the WebAPI team, and that
blog was the start of bringing in a wider audience.

How I'm expecting it to work in Firefox:
1. A website calls the DOM API to request push permission.
2. If the user consents, Firefox talks to the Notification Service and
gets a new URL for the user.
3. Firefox responds to the API success callback with that URL.
4. The site sends that URL to its backend for storage.
5. The website backend sends a message to the saved URL.
6. The Notification Service sends the message to that user's Firefox.

I want this to work wherever you have a Firefox agent, using Android's
push API for Fennec, Apple's service for Firefox Home, and whatever
scales best for B2G and desktop. To identify you across devices, I'm
looking to use https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser.

The Notification Service is a backend app Mozilla would run to proxy
messages from apps to users. The DOM API passes around URLs so that
users can run their own Notification Service, and so that other
browsers can set up their own.

Right now there's no way for sites to interact with notifications they
send. We could fire an event if the page is open, but we don't have a
way to run an event handler if the website isn't open.

Inline responses to questions from
https://wiki.mozilla.org/Services/Notifications/Push/API#Feedback:

Gerv wrote:
> Is the "body" plain text or HTML, or something else?

Plain text. Existing systems (Growl, Android, Apple, Ubuntu) don't
support HTML, and I think that's a good constraint. It limits the
security space, the bandwidth usage, and keeps the system simple.

The Desktop Notification spec (http://www.w3.org/TR/notifications/)
takes a less emphatic stance, saying "The user agent may ignore any
markup in this string and treat it as plain text."

> Are clients forced to support actionURL (the notification system currently used in Ubuntu, for example, specifically removed support for clicking on a notification to take an action)?

No. I'd really like to say yes, but I think all I can do is strongly
suggest that clients implement this.

I had a discussion with an engineer for Ubuntu (@sil) and it seems the
Ubuntu Messaging Menu would be a better fit for push notifications.

> What are the rules, if any, about cookie-sending and Referer and Origin when the actionURL is accessed?

I had not considered specifying any special rules. I would treat it
like opening a new tab, so cookies would be sent normally and there
would be no Referer.

> Are there maximum lengths for any of the fields?

Yes, but I don't know the numbers yet. Apple limits messages to 256
bytes and Android limits it to 1024. The limits are important for
mobile efficiency.

> What about icons of multiple sizes?

That's a good idea, but it may be impractical. Do you have an idea how
to specify that so it's easy for developers and efficient on the
network? Which sizes will we allow?

> Does iconURL lead to a privacy issue because the site can see if the user has read the notification? Can we allow, or require, inline icons?

Yes, it leaks data that the user agent opened the notification, like a
beacon image in emails. However, I don't think we could get inline
icons while maintaining the small messages size.


> Are there rules or guidelines to avoid accidentally clashing replaceIDs, such as a "org.mozilla.notification-somerandomstring" convention?

Each website would have a private replaceID namespace, so there's no
possibility of collision.

> How can we mitigate the problem of one (authorized) site spoofing notifications that look like those from another site? Will the in-browser UI show the origin of the notification?

We may need to show the origin, as Chrome's desktop notifications
currently do. I think we would also want a same-origin restriction on
the iconUrl and actionUrl.

Hixie wrote:
> How does this handle a user who uses two different Web browsers? (e.g. IE at work and Firefox at home)

I don't know a good way to handle this. It may be up to the website
developers to say "I already have a URL for you, should I replace it?"
I don't feel good about this.

Ben Bucksch wrote:
> How is the privacy impact of following the user (IP addresses, usage times) reduced to the absolute minimum possible?

The Notification service won't be talking to Firefox unless you give a
website permission to send you messages, so it won't be on without
your assent.

> Why the middle man Mozilla? Decentralization is a core principle of the Internet.

If we didn't have a proxy, would each of your favorite sites keep a
connection open to your device so they could send you their messages?

Our proxy won't be the only one; it'll be the default for Firefox users.

Ryan Schipper wrote:
> From a security viewpoint, the obvious choice to prevent spoofing is digital signatures. However, client-side (in this case the notifying website) developers who aren't familiar with PKI often find it too complex, resulting in a lack of third-party API implementations (see OAuth!). If Mozilla intends to develop, distribute and support the client API themselves, this is less of an issue. If this is not the case, OAuth 2.0 has some non-PKI options. Implementing all of the OAuth 2.0 protocol may be too heavyweight, but it would at least offer some inspiration.

I've been struggling with a way for the Notification Service to trust
the site that is sending messages. Currently, we rely on a long,
random sequence of characters in the URL that should only be known to
Firefox and the third-party site.

I don't want to require that sites set up some sort of API key with
each notification service they want to talk to, since that would limit
the ability to decentralize and would be a large hurdle for
developers. Any ideas here would be fantastic.

> The designers should also consider verifying the integrity and source of notifications received by the browser.

All of the communication between Firefox and the Notification Service
will be over https.


Sorry about the length. I'm excited to hear feedback, on this list or
directly to me.

Thanks,
jeff

[Justin Lebar]

This is great stuff!

>> Does iconURL lead to a privacy issue because the site can see if the user
>> has read the notification? Can we allow, or require, inline icons?
>
> Yes, it leaks data that the user agent opened the notification, like a
> beacon image in emails. However, I don't think we could get inline
> icons while maintaining the small messages size.

We could handle the icon during registration of the push notification.
That would solve the privacy issue at the cost of limiting each
site/app to one icon. (In practice, this seems to be what happens on
my Android phone, anyway.)

-Justin

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Patrick McManus]

On 2/6/2012 10:56 PM, Jeff Balogh wrote:

you've got a lot of hurdles until you get to my point below, but let me
suggest:

>> The designers should also consider verifying the integrity and source of notifications received by the browser.
> All of the communication between Firefox and the Notification Service
> will be over https.

it seems that websockets was more or less created for the notification
delivery use case where the client initiates connection but the server
pushes data on its schedule. Otherwise you're looking at HTTP polling or
a hanging transaction, right? Both are fraught with delay and overhead.
Websockets runs over SSL as wss://

good luck with the idea!

-Patrick

[Jeff Balogh]

You're right. I'm actually planning on using websockets for the
desktop (if we can scale it). My shortcut for saying "secure
connection" is still "https".

[Jeff Balogh]

On Mon, Feb 6, 2012 at 8:22 PM, Justin Lebar <justin...@gmail.com> wrote:
> This is great stuff!
>
>>> Does iconURL lead to a privacy issue because the site can see if the user
>>> has read the notification? Can we allow, or require, inline icons?
>>
>> Yes, it leaks data that the user agent opened the notification, like a
>> beacon image in emails. However, I don't think we could get inline
>> icons while maintaining the small messages size.
>
> We could handle the icon during registration of the push notification.
>  That would solve the privacy issue at the cost of limiting each
> site/app to one icon.  (In practice, this seems to be what happens on
> my Android phone, anyway.)

That's a good idea. It creates a problem of deciding when to refresh
the icon, but it may be a good balance between usability and privacy.

If we lock down the icon I would add a "count" field to the
notification payload so we can add number badges to the icons (e.g. 47
new messages). That's an existing feature in Apple's service and
Ubuntu's Messaging Menu.

[Gervase Markham]

On 07/02/12 05:11, Jeff Balogh wrote:
>> We could handle the icon during registration of the push notification.
>> That would solve the privacy issue at the cost of limiting each
>> site/app to one icon. (In practice, this seems to be what happens on
>> my Android phone, anyway.)
>
> That's a good idea. It creates a problem of deciding when to refresh
> the icon, but it may be a good balance between usability and privacy.

Can we do this while avoiding limiting the site/app to one icon? I can
imagine that being a bit of a pain as a restriction. Even a choice of 3,
all registered at registration time, would be more flexible.

> If we lock down the icon I would add a "count" field to the
> notification payload so we can add number badges to the icons (e.g. 47
> new messages). That's an existing feature in Apple's service and
> Ubuntu's Messaging Menu.

Good idea.

Gerv

[Gervase Markham]

Another thought: say my website's database of push URLs is compromised.
Is there a way I can tell all my site's visitors: "please start
dis-trusting any previous URLs you gave me a while ago, and use this one
instead"? Can I tell a particular notification service, "please
invalidate all URLs on my domain"?

> Gerv wrote:
>> Is the "body" plain text or HTML, or something else?
>
> Plain text.

Fair enough. Can we at least have carriage returns, and thereby
paragraphing?

>> Are there maximum lengths for any of the fields?
>
> Yes, but I don't know the numbers yet. Apple limits messages to 256
> bytes and Android limits it to 1024. The limits are important for
> mobile efficiency.

We could go for the seemingly-standard 140 characters. Although it seems
like this is a bit different to a tweet or an SMS, particularly if
notifications can be replaced. And the SMS limit is getting less
relevant these days, as most mobile systems will stitch SMSes together,
at least up to a certain limit.

Is Apple's limit 256 bytes, or 256 characters? Same question for Android.

>> What about icons of multiple sizes?
>
> That's a good idea, but it may be impractical. Do you have an idea how
> to specify that so it's easy for developers and efficient on the
> network? Which sizes will we allow?

Well, one option would be allowing or requiring SVG icons :-) There are
also image standards which allow multiple icons in a single container,
although perhaps none of the popular ones do. Another would be a
filename hacking convention of some sort, but that's a bit kludgy and
would lead to random 404 errors in logs, which isn't nice. The fourth
option is just to have a slightly more complex JSON data structure which
gives both image size and URL, and the client can pick the best one.

Whatever happens, clients should be required to scale the icon.

> Yes, it leaks data that the user agent opened the notification, like a
> beacon image in emails. However, I don't think we could get inline
> icons while maintaining the small messages size.

I think we should look into requiring support for data: URLs.

> We may need to show the origin, as Chrome's desktop notifications
> currently do. I think we would also want a same-origin restriction on
> the iconUrl and actionUrl.

More certainly on the iconURL, but I think we should evaluate the two
cases separately. I don't think the case is as strong for actionUrl,
partly because it's fetched on user request rather than automatically.

>> Why the middle man Mozilla? Decentralization is a core principle of the Internet.
>
> If we didn't have a proxy, would each of your favorite sites keep a
> connection open to your device so they could send you their messages?
>
> Our proxy won't be the only one; it'll be the default for Firefox users.

Can we make it so our implementation supports keeping open connections
to multiple proxies, or to the same proxy with multiple identities? This
flexibility is IMO important in enabling both consumer choice and
migration from one provider to another.

> I've been struggling with a way for the Notification Service to trust
> the site that is sending messages. Currently, we rely on a long,
> random sequence of characters in the URL that should only be known to
> Firefox and the third-party site.

This is effectively a shared secret. As long as there is some way of
"revoking" rights, both from the website side and the user side, I think
this may well prove sufficient.

However, you should define the shared secret in a way which allows it to
be delineated, so that it can take meaning (e.g. "hash of a key" or
something) for v2 clients later, if necessary.

Gerv

[Sasha Mace]

On Feb 7, 4:10 am, Gervase Markham <g...@mozilla.org> wrote:
> >> Are there maximum lengths for any of the fields?
>
> > Yes, but I don't know the numbers yet. Apple limits messages to 256
> > bytes and Android limits it to 1024. The limits are important for
> > mobile efficiency.
>
> We could go for the seemingly-standard 140 characters. Although it seems
> like this is a bit different to a tweet or an SMS, particularly if
> notifications can be replaced. And the SMS limit is getting less
> relevant these days, as most mobile systems will stitch SMSes together,
> at least up to a certain limit.
>
> Is Apple's limit 256 bytes, or 256 characters? Same question for Android.

The limit is indeed bytes, for both platforms.

S

[Jeff Balogh]

On Tue, Feb 7, 2012 at 4:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Another thought: say my website's database of push URLs is compromised. Is
> there a way I can tell all my site's visitors: "please start dis-trusting
> any previous URLs you gave me a while ago, and use this one instead"? Can I
> tell a particular notification service, "please invalidate all URLs on my
> domain"?

That's something I need to figure out. The server knows what domain a
URL belongs to, but there's no way to communicate that the URL should
be deleted.

>>> What about icons of multiple sizes?
>>
>>
>> That's a good idea, but it may be impractical. Do you have an idea how
>> to specify that so it's easy for developers and efficient on the
>> network? Which sizes will we allow?
>
>
> Well, one option would be allowing or requiring SVG icons :-) There are also
> image standards which allow multiple icons in a single container, although
> perhaps none of the popular ones do. Another would be a filename hacking
> convention of some sort, but that's a bit kludgy and would lead to random
> 404 errors in logs, which isn't nice. The fourth option is just to have a
> slightly more complex JSON data structure which gives both image size and
> URL, and the client can pick the best one.
>
> Whatever happens, clients should be required to scale the icon.

This is getting complicated. :)

>> Yes, it leaks data that the user agent opened the notification, like a
>> beacon image in emails. However, I don't think we could get inline
>> icons while maintaining the small messages size.
>
>
> I think we should look into requiring support for data: URLs.
>
>
>> We may need to show the origin, as Chrome's desktop notifications
>> currently do. I think we would also want a same-origin restriction on
>> the iconUrl and actionUrl.
>
>
> More certainly on the iconURL, but I think we should evaluate the two cases
> separately. I don't think the case is as strong for actionUrl, partly
> because it's fetched on user request rather than automatically.
>
>
>>> Why the middle man Mozilla? Decentralization is a core principle of the
>>> Internet.
>>
>>
>> If we didn't have a proxy, would each of your favorite sites keep a
>> connection open to your device so they could send you their messages?
>>
>> Our proxy won't be the only one; it'll be the default for Firefox users.
>
>
> Can we make it so our implementation supports keeping open connections to
> multiple proxies, or to the same proxy with multiple identities? This
> flexibility is IMO important in enabling both consumer choice and migration
> from one provider to another.

Supporting multiple identities would depend on how the browsers
sign-in is implemented. Reading the feature page, it seems that
signing in under another name would be a separate profile, so we
wouldn't want those to share notifications.

I don't see the benefit of connecting to multiple proxies. If you
decide to switch backends, you presumably don't want your messages
going through the old backend.

[Caspy7]

I've been reading bug 594543 "Implement Desktop Notifications in
Firefox" (which would allows a site to send growl-like notifications)
and was wondering how this might interact with that?
https://bugzilla.mozilla.org/show_bug.cgi?id=594543
Chrome implements a version of this for use with Gmail & other sites.
There are suggestions that the W3C spec & Chrome's version is
suboptimal. (There is no current owner of the aforementioned bug.)
Will Firefox ever implement anything like that or expect that all
sites/apps who desire notification will implement this push
notification. It seems like overkill to use push in this manner when
you've got the tab or the app open - along with the unnecessary
delay.
I don't know if there's something already filling this space, but do
offline apps currently have a means for desktop notification? If not,
perhaps these two efforts need to be combined or considered side-by-
side.

[TelegramSam]

> Our proxy won't be the only one; it'll be the default for Firefox users.

To clarify: Users can configure Firefox to use a different
notification service (conforming to the same interface standard)
instead of the default provided by Mozilla?

Is this a preference, or could it be modified by having an extension
installed?

-Sam

[Jeff Balogh]

I'm hoping that Desktop Notifications will get picked up along with
Push Notifications. Desktop Notifications died in that bug because
there was no one to champion the UX, but we have some interaction
design in the works for Push
(http://habber.tumblr.com/post/19572771640/ive-been-working-with-jeff-balogh-at-mozilla).

I see Desktop and Push working side by side, as they do on Android and
iOS devices. I don't want to block Push waiting for Desktop, but I
don't think it will be too hard to finish Desktop Notifications once
the user experience is resolved.

[Jeff Balogh]

On Mon, Mar 19, 2012 at 5:35 AM, TelegramSam <teleg...@gmail.com> wrote:
>> Our proxy won't be the only one; it'll be the default for Firefox users.
>
> To clarify: Users can configure Firefox to use a different
> notification service (conforming to the same interface standard)
> instead of the default provided by Mozilla?

Yes.

> Is this a preference, or could it be modified by having an extension
> installed?

It will be in about:config preferences, which can be modified by extensions.

[kazu...@gmail.com]

Hi,

Are you people still working on this at mozilla.org? I noticed that the Wiki now redirects to https://wiki.mozilla.org/WebAPI/PushAPI which seems specific to FirefoxOS.

I am interested in implementing the feature for other web browsers as extensions (+ helper javascript).

[DigDug]

Firefox for Android is also looking to implement this right now (although the work is in a pretty early state).

- Wes

[kazu...@gmail.com]

Hi,

Are you people still working on this at mozilla.org? I noticed that the Wiki now redirects to https://wiki.mozilla.org/WebAPI/PushAPI which seems specific to FirefoxOS.

I am interested in implementing the feature for other web browsers as extensions (+ helper javascript).

On Tuesday, February 7, 2012 12:56:50 PM UTC+9, Jeff Balogh wrote:

[Nikhil Marathe]

On Thu, Jan 24, 2013 at 5:06 AM, <kazu...@gmail.com> wrote:
> Hi,
>
> Are you people still working on this at mozilla.org? I noticed that the Wiki now redirects to https://wiki.mozilla.org/WebAPI/PushAPI which seems specific to FirefoxOS.
>
> I am interested in implementing the feature for other web browsers as extensions (+ helper javascript).

Its now this: https://bugzil.la/822712
We're working on making sure this runs on all platforms natively.

NOTE: This push notification system is not for informing the user via
badges or similar,
but to inform a running/installed webapp about updates. the webapp can
then use desktop-notifications
or similar to inform the user.

Nikhil

[Kazuho Oku]

Thank you for the link and thank you for the clarification. The spec (https://wiki.mozilla.org/WebAPI/SimplePush) linked from the bugzilla is very informative and easy to understand!

The sad thing for me is that the spec does not cover ordinary webapps for now, as noted on the wiki. I more of hoped for something like sending badges or similar, since if it had been such, it would not be difficult to implement on other web browsers (as extensions) to receive and display notifications from ordinary webapps.

I am looking forward to seeing the spec cover webapps as well.

Thank you again for your help and clarification.

> Nikhil

[Kazuho Oku]

On Friday, January 25, 2013 1:00:24 AM UTC+9, Nikhil Marathe wrote: