On 9/4/2012 9:40 AM, ptheriault wrote: > Now that we have more details of this API, I think we need to revisit the > permission model. I think the user should be asked before an app is allowed > to receive push notifications (inline with the transparency/no surpises > privacy principle). The user should also be able to see what push channels > are registered and turn them off. This could be achieved by requiring an > explicit permission installed, privileged and certified web apps. > The only issue I see with this is that a user might not understand what > "Push Notification" actually is.
I don't think they will understand. How is this worse than using alarm API to poll a server? We don't provide UX anywhere to manage per-channel network access. For consumption purposes we might want to have the ability to turn off push on a per-device or per-app basis, but that's not a permission IMHO. Lucas. > On Aug 8, 2012, at 5:45 PM, Lucas Adamski wrote: > >> Initial draft. One of the trickier APIs to reason through as it really >> depends on the intended use cases. Thoughts? >> >> ==Push Notifications API== >> >> References: >> *https://wiki.mozilla.org/WebAPI/PushAPI >> *https://bugzilla.mozilla.org/show_bug.cgi?id=747907 >> *https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/doBebGwUTNE >> >> Brief purpose of API: Asynchronous notification mechanism for apps with >> store and forward capabilities. >> >> General Use Cases: Provide an mechanism for websites to push small >> notifications to subscribed applications on the client, even when they >> aren't currently running. >> *IM messaging apps. >> *Website activity notifications (auctions, online price alerts, travel >> advisories and flight status, banking activity, etc). >> >> Inherent threats: >> *Spoofing notifications could lead user to disclosing sensitive information >> *Spoofing messages could trick an app into disclosing sensitive information >> (i.e. submit info to URL..) or otherwise take action on behalf of the >> attacker. >> *Spoofing of notifications to system-critical applications could result in a >> variety of attacks, from information disclosure to device compromise. >> >> Threat severity: High, possibly Critical depending on usage >> >> == Regular web content (unauthenticated) == >> Use cases for unauthenticated code: Same >> >> Authorization model for normal content: None? >> >> Authorization model for installed content: Implicit >> >> Potential mitigations: Airplane mode? >> >> == Privileged (approved by app store) == >> Use cases for privileged code: Same >> >> Authorization model: Implicit >> >> Potential mitigations: Same >> >> == Certified (system-critical apps) == >> Use cases for certified code: Do we use this API for any system-sensitive >> operations, like app updates, payments, etc? >> >> Authorization model: Implicit >> >> Potential mitigations: Same >> >> __NOTOC__ >> >> _______________________________________________ >> dev-webapps mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
