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: > 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
