On Thursday, January 24, 2013 5:06:25 AM UTC-8, Kazuho Oku 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). > > > > 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
Firefox for Android is also looking to implement this right now (although the work is in a pretty early state). - Wes _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
