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.
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.
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.
>> 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.)
On Mon, Feb 6, 2012 at 10:56 PM, Jeff Balogh <jbal...@mozilla.com> wrote:
> 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.
> 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.
> 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.
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://
On Mon, Feb 6, 2012 at 8:31 PM, Patrick McManus <mcma...@ducksong.com> wrote:
> 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://
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".
On Mon, Feb 6, 2012 at 8:22 PM, Justin Lebar <justin.le...@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.
>> 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.
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.
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.
On Tue, Feb 7, 2012 at 4:15 AM, Gervase Markham <g...@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.
>> 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.
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.
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.
> 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?
On Sat, Feb 25, 2012 at 11:44 PM, Caspy7 <cas...@gmail.com> wrote:
> 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.
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-...).
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.
On Mon, Mar 19, 2012 at 5:35 AM, TelegramSam <telegram...@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.
