RE: Permissions for receiving messages

OK, that interpretation was makes it more in line with my thinking (I based my observation on the suggestion from Marco Marengo[1] and the notes from the meeting). Looking at the BONDI specs [2] the filters seems to be used only to reduce event flow, not for any "permission-like" activity, btw. 

I'm not quite sure that I as a user would be less confused by having to configure the filters after accepting the permissions in the first place, isn't the idea with permissions to put all these "may the app do this" requests up front to avoid (in "trusted" environment) security dialogs?

On the other hand (perhaps shooting my argument in the foot), maybe there is a real strong use case for allowing a user to manipulate their subsciptions from inside the application. 

I'll try to put together some proposal text for the security chapter in the messaging spec.

Best regards,

-----Original Message-----
From: Dominique Hazael-Massieux [] 
Sent: Wednesday, October 20, 2010 6:40 PM
To: Niklas Widell
Cc: ''
Subject: RE: Permissions for receiving messages

Le mercredi 20 octobre 2010 à 17:38 +0200, Niklas Widell a écrit :
> Looking at the Prague minutes I think the discussion in Prague which 
> resulted in ACTION-132 had a subtle difference to the "proposal" here.
> ACTION-132 is about looking into assisting developers with event 
> filtering, while the "proposal" here is to filter which messages the 
> app is actually is allowed to see.

To clarify, one of the things that were mentioned in Prague was that the subscription to events should require a filtering argument, e.g.:
        var myEmailListener =

If left empty, the app would receive nothing. Of course, there should probably be some form of wildcards available, but the idea is that in an interactive context, the user would be able to accept or refuse that filtering, and maybe even tweak it (e.g. the app requests access to everything, but the user only allows access to message from a specific address).

I can see why it would be interesting to bring that to installation time rather than execution time, but as a user, I'm not sure I would necessarily find the experience adequate (also, it wouldn't be mappable in most existing systems). But I'm certainly not opposed to explore that path either.

In any case, I think the first step is to try to capture these discussions (and the others that we have had on the scope of messaging in trusted/untrusted environments) as part of the security considerations of the draft spec...


Received on Friday, 22 October 2010 09:56:18 UTC