|Security Discussion: Push Notifications API||Lucas Adamski||8/8/12 5:45 PM|
Initial draft. One of the trickier APIs to reason through as it really depends on the intended use cases. Thoughts?
==Push Notifications API==
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).
*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
|Re: Security Discussion: Push Notifications API||Doug Turner||8/8/12 9:32 PM|
The bug listed was filed 4 months ago. Has any one begun working on this, if so -- where's the code? I'd like to see the approach that was taken. Specifically how permissions are granted/check.
|Re: Security Discussion: Push Notifications API||Guillermo López||8/9/12 12:46 AM|
2012/8/9 Doug Turner <do...@mozilla.com>
Thinker is working on the gecko part:
> dev-webapps mailing list
Guillermo López [willyaranda]. Mozilla Reps Mentor.
Certified Mozillian: https://mozillians.org/willyaranda
|Re: Security Discussion: Push Notifications API||pther...@mozilla.com||9/4/12 9:40 AM|
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.
|Re: Security Discussion: Push Notifications API||Lucas Adamski||9/4/12 1:25 PM|
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.
|Re: Security Discussion: Push Notifications API||pther...@mozilla.com||9/5/12 7:30 PM|
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.
|Re: Security Discussion: Push Notifications API||Jonas Sicking||9/5/12 10:04 PM|
On Wed, Sep 5, 2012 at 7:30 PM, ptheriault <pther...@mozilla.com> wrote:Before we make security decisions assuming we have such UI, we should
verify that the UI team is actually planning on building that, *and*
will have the time to do so.
|Re: Security Discussion: Push Notifications API||Guillermo López||9/7/12 4:14 AM|
2012/9/6 ptheriault <pther...@mozilla.com>
Yes, they disclose to the server a pair of PbK and WAtoken. The WAtoken
could be unique or shared, but the PbK should be the same for each
installation of the app. So, yes, we know which users share the same PbK
(that could eventually be mapped to a app).
I totally agree (and I think that Thinker's patch has this) that we _must_
ask the user to allow push notifications, but maybe he does not know what
that means. (and also: "Yes", "Not now", "Never").
And I was talking with FernandoR that we should have a good UI to show the
mapping of app<->URL to list every app that has a push URL, and add a
method to revoke them (it's mostly implemented in our server, we need to
|Re: Security Discussion: Push Notifications API||Fernando Rodríguez Sela||9/7/12 4:37 AM|
El 07/09/12 13:14, Guillermo López escribió:
2012/9/6 ptheriault <pther...@mozilla.com<mailto:pther...@mozilla.com>>
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.I want to add: the Push server only moves raw data from one side to another, so if the app wants to encrypt the data end-to-end is perfectly allowed (and recomended) so on the server you only can see crypto data... so no privacy user data is exposed.
Also, on our side of course, the server will be on a controlled CPD with all the privacy and security required by law to this kind of servers.
Yes, it has been implemented this week so would be fantastic to have a way on gaia settings to revoke push permissions to one app.
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: