I was concerned that Push Notifications may have a privacy impact, and a user might want to make a choice not to enable them. Apart from anything, Push notifications disclose to the carrier that the user has installed a specific app. Implicit permissions & a setting to enable/disable push notifications might suffice though to begin with, especially if this UI showed you which applications were registered to send & receive push APIs.
On Sep 4, 2012, at 1:25 PM, Lucas Adamski wrote: > > 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
