Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Security Discussion: Push Notifications API

70 views
Skip to first unread message

Lucas Adamski

unread,
Aug 8, 2012, 8:45:27 PM8/8/12
to dev-w...@lists.mozilla.org, Doug Turner
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__

Doug Turner

unread,
Aug 9, 2012, 12:32:56 AM8/9/12
to Lucas Adamski, dev-w...@lists.mozilla.org
Hey Lucas,

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.

Thanks!

Guillermo López

unread,
Aug 9, 2012, 3:46:08 AM8/9/12
to Doug Turner, dev-w...@lists.mozilla.org, Lucas Adamski
2012/8/9 Doug Turner <do...@mozilla.com>

> Hey Lucas,
>
> 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.
>

Hey!

Thinker is working on the gecko part:

https://bugzilla.mozilla.org/show_bug.cgi?id=763198

Cheers,
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps
>



--
Guillermo López [willyaranda]. Mozilla Reps Mentor.
http://mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano
Certified Mozillian: https://mozillians.org/willyaranda

ptheriault

unread,
Sep 4, 2012, 12:40:40 PM9/4/12
to Lucas Adamski, dev-w...@lists.mozilla.org, Doug Turner
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.

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

Lucas Adamski

unread,
Sep 4, 2012, 4:25:44 PM9/4/12
to ptheriault, dev-w...@lists.mozilla.org, Doug Turner

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.

ptheriault

unread,
Sep 5, 2012, 10:30:45 PM9/5/12
to Lucas Adamski, dev-w...@lists.mozilla.org, Doug Turner
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.

Jonas Sicking

unread,
Sep 6, 2012, 1:04:16 AM9/6/12
to ptheriault, dev-w...@lists.mozilla.org, Doug Turner, Lucas Adamski
On Wed, Sep 5, 2012 at 7:30 PM, ptheriault <pther...@mozilla.com> wrote:
> 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.

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.

/ Jonas

Guillermo López

unread,
Sep 7, 2012, 7:14:55 AM9/7/12
to ptheriault, dev-w...@lists.mozilla.org, Doug Turner, Lucas Adamski, FERNANDO RODRIGUEZ SELA
2012/9/6 ptheriault <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.
>

Hi!

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
test it).

Cheers,

Fernando Rodrí­guez Sela

unread,
Sep 7, 2012, 7:37:42 AM9/7/12
to Guillermo López, dev-w...@lists.mozilla.org, Doug Turner, ptheriault, Lucas Adamski
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.

Hi!

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 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.

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 test it).


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.

Cheers,

--
Guillermo López [willyaranda]. Mozilla Reps Mentor.
http://mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano
Certified Mozillian: https://mozillians.org/willyaranda


________________________________

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:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
0 new messages