On 27/09/2012, at 00:59, "Justin Lebar" <[email protected]> wrote:
>> Yeah, that was my understanding too, but then I was told that >> notifications actually launched the app if it wasn't running in the >> first place. > > I would be curious to learn when this switch was made. The protocol > implemented by Telefonica in the bug forces us to wake up the app on > every notification, but everyone I've spoken with has said that they > thought we were doing this differently. So I wonder at what point a > decision was made to switch, and why. Actually I've seen the protocol since it was in draft and I had still assumed that the way it would work would be as Paul said, and as iOS does: when a notification is received, if the app is running it goes to the app, and otherwise it goes on the notification panel until the user chooses to activate the app. The protocol is quite similar to iOS one... and if in iOS it doesn't force us to launch/wake up the app, I don't know why here it does. I'm fact it wasn't until I read your messages on the bug talking about the applications polling when I started thinking that something was amiss since on my view of the world :P applications couldn't poll since they probably wouldn't be running in the first place. Then I asked around and I was told that apps were going to be awoken on notification reception. But I still think that's a client implementation decision, not something that's forced by the way the protocol works. > > Personally, I don't think that waking up the app is so bad; it allows > us to make the API simpler in many respects. But that's a separate > question from wanting to know why we changed. Waking up the app on notification reception isn't a bad idea. Is an awful one, specially if the permission is implicit. Doing it so means that you've actually give up all control about what's running on your device. Any application could use the notification API and then the developer (and not you anymore) would choose when the app was going to run on your device. Even for "good" applications that wouldn't be cool. For malicious apps it's a heaven's gift: an attacker can choose when and how his code is going to run. Makes all the attacks that require a malicious app actually running on the deceive so much easier. To keep it this way (and again, I think this should be a separate issue from the ones that have risen on the patch review, since it isn't or should not be protocol related) the permission would have to be at least explicit for installed (and I would say even privileged). It would be even better if we could have two different permissions: one that lets the apps use an iOS like notification system (user must launch the app) and other, more restricted, that allows some apps to be launched remotely. I can't think on any use case for the second one to be honest, but I'm pretty sure that someone someplace will have a perfect use case for that. And yes, I know the date we're on ;). Un saludo, Antonio > > On Wed, Sep 26, 2012 at 6:08 PM, Antonio Manuel Amaya Calvo <[email protected]> > wrote: >> On 26/09/2012 23:09, ptheriault wrote: >>> >>> Antonio, >>> >>> I was surprised to see that too - my guess is that it was a guess from >>> long ago before push API was defined. On monday I created a version 1.0 of >>> the matrix with many updates and corrections (including this) and sent it to >>> the b2g list. Below are links to the new matrix, and the change log/question >>> list: >>> >>> Permissions Matrix 1.0: >>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdHNlbDBDUGMzUzJSdFYyNEZjcngtUWc >>> 1.0 version changes: https://etherpad.mozilla.org/permissionmatrixupdates >> >> >> Thanks for the new version, somehow I missed that update. >> >> >>> >>> (for reference, the change I made was to update permissions to match the >>> wiki. Also I wasnt sure if there is a Mgmt API which allows the system to >>> know what push notifications are registered?) >>> >>> Now to your concern about apps launching - is your fear that apps can keep >>> themselves running by sending push notifications? >>> My understanding of the way Push Notifications were handled was that there >>> was user interaction in the process - i.e. they show up in the notifications >>> tray, and then, only after the user has tapped on the notification the app >>> is relaunched. >> >> >> Yeah, that was my understanding too, but then I was told that >> notifications actually launched the app if it wasn't running in the >> first place. Which if finally is what sees the light, makes it an >> explicit permission (at least) in my book :) >> >> Best regards, >> >> Antonio >> >> >>> >>> Regards, >>> Paul >>> >>> >>> On Sep 26, 2012, at 8:34 PM, Antonio Manuel Amaya Calvo wrote: >>> >>>> Hey Paul. >>>> >>>> I've seen that on the permission matrix at >>>> >>>> https://docs.google.com/spreadsheet/ccc?key=0Akyz_Bqjgf5pdENVekxYRjBTX0dCXzItMnRyUU1RQ0E&pli=1#gid=0 >>>> the PushAPI is reserved to certified apps only, when it used to be a >>>> Public API (according to >>>> https://wiki.mozilla.org/WebAPI/Security/pushNotificationsAPI at least). >>>> >>>> Do you know why and when was that changed? >>>> >>>> I was in fact going to suggest either changing the way the system treats >>>> notification currently (from what I've been told, the system *launches* >>>> the app if it isn't running, which isn't good) or at least making it an >>>> explicit permission for anything less than privileged, but just removing >>>> the permission completely for anything less than certified seems a >>>> little bit extreme. >>>> >>>> Best regards, >>>> >>>> Antonio >>>> >>>> >>>> -- >>>> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S >>>> email: [email protected] / _ _/ ( / Telefonica I+D >>>> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ramón de la Cruz 82 >>>> Fax : 28006 Madrid, SPAIN >>>> >>>> ________________________________ >>>> >>>> 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 >>> >>> testResults['bluetooth'] >>> >> >> -- >> Antonio Manuel Amaya Calvo_/ / _ /Security&Trust on N&S >> email: [email protected] / _ _/ ( / Telefonica I+D >> Tlf.: +34-91.312.98.95 _/ _/ \__/ D. Ramón de la Cruz 82 >> Fax : 28006 Madrid, SPAIN >> >> ________________________________ >> >> 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 >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g ________________________________ 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
