Messaging API, Security and Permissions (ACTION-291)

Hi,

 Sorry for this long e-mail, but I have preferred to summarize in a unique
place the outcome of the discussions about the messaging API and
permissions.

1) Firstly, based on the current approach followed by the permissions
document [1], and in the content of the FPWD of the Messaging API [2], I
would suggest the following text for the messaging section in [1]:

"The sms.send identifier corresponds to the access to the SMSMessage::send
method defined in Messaging API.

The mms.send identifier corresponds to the access to the MMSMessage::send
method defined in Messaging API.

The email.send identifier corresponds to the access to the
EmailMessage::send method defined in Messaging API.

The sms.subscribe identifier corresponds to the access to the
MessagingManager::onSMS method defined in Messaging API.

The mms.subscribe identifier corresponds to the access to the
MessagingManager::onMMS method defined in Messaging API.

The email.subscribe identifier corresponds to the access to the
MessagingManager::onEmail method defined in Messaging API.

In the Web browser environment, this permissions are usually granted through
explicit user content for each call to the related methods."

 2) Apart from that, we have been thinking about the comments sent to the
mailing lists [3] and we are still not sure about the use cases for having
different permissions for subscription depending on the origin of the
message. 

However, what is clear to us, is that in some situations, the user may allow
some of the *.send permissions depending on the message destination,
specially for the SMS/MMS types, in which the billing implications depend a
lot on the destination (e.g. national, international, premium, special rates
for friends...). 

With the current solution, in a trusted environment, if the user is
concerned about these situations about sending, he should select a
"prompt-oneshot" for the *.send permissions, because that is the only
mechanism through which he can decide if a message can be sent depending on
the destination. This may end-up in a user experience full of prompts.
Furthermore, we need to ensure that the prompt includes all the relevant
information such as the destination and the messaging technology to be used
so that the user can take an informed decision.  

An alternative to the current permission solution, would be allowing
permissions to have parameters, so that a user could, for instance, define a
policy in which SMSs to numbers starting with 3 (premium numbers in Spain)
are not allowed. Such a mechanism can reduce the number of prompts and hence
improve usability. The caveat is that security policies could become very
complex and that security checking cannot be done at installation time as
the destination number may be selected during runtime (please note that such
a solution would also work in the case we want also to allow origin based
distinction in the subscribe permission).

I am not sure if adding parameters to permissions is the only option for
enabling this use case, but I think we should try to explore this or any
other alternative to make the most of trusted environments and improve
usability. 

And related with the discussion about whether messaging is a "trusted
environment"-only specification or not [4], I think the key aspect is the
use cases for the "browser environment". If those use cases are important
enough we need to find a security solution for that scenario.

 3) Based on these comments and previous feedback [5], we suggest to update
the current text in the section 4 (Security Considerations) of the Messaging
API [2] with the following:

The API defined in this specification can be used to create and subscribe
for incoming messages through different technologies. Sending messages
usually have a cost associated to them, especially SMSs and MMSs.
Furthermore this cost may depend on the message attributes (e.g. destination
address) or external conditions (e.g. roaming status). The ability to
subscribe to incoming messages reveals the parties to a communication, and
possibly the content of the message, to the subscriber. A conforming
implementation of this specification must provide a mechanism that protects
the user's privacy and this mechanism should ensure that no message is sent
or no subscription is establisehd without the user's express permission.

4.1 Privacy considerations for implementors of the Messaging API

4.1.1 Message Sending

A user agent must not send messages without the express permission of the
user. A user agent must acquire permission through a user interface, unless
they have prearranged trust relationships with users, as described below.
The user interface must include the URI of the document origin, as defined
in [HTML5], the type of message to be sent and its destination (i.e. the
"to" attribute of the message). Obtaining permission through the user
interface for one invocation of the method MUST NOT imply consent for future
invocations of the same method, i.e. user interface authorization must be
one every time the send method is invoked.

The methods for sending messages that require user's express permission to
be accessed are:

SMSMessage.send(), MMSMessage.send() and EmailMessage.send().

4.1.2 Message Subscription

A user agent must not subscribe to incoming messages without the express
permission of the user. A user agent must acquire permission through a user
interface, unless they have prearranged trust relationships with users, as
described below. The user interface must include the URI of the document
origin, as defined in [HTML5] and the type of message of the subscription.
Obtaining permission through the user interface for one invocation of the
method MUST NOT imply consent for future invocations of the same method,
i.e. user interface authorization must be one every time the subscription
method is invoked.

The methods for message subscription that require user's express permission
to be accessed are:

MessagingManager.onSMS(), MessagingManager.onMMS() and
MessagingManager.onEmail().

A user agent may have prearranged trust relationships that do not require
such user interfaces for granting permission for message sending and
subscription. For example, while a Web browser will present a user interface
when a Web site request an SMS subscription, a Widget Runtime may have a
prearranged, delegated security relationship with the user and, as such, a
suitable alternative security and privacy mechanism with which to authorize
that operation.

4) Due to these differences between messaging sending and receiving, and
also some comments [6] about the need of handling multipart content for
message receiving, a good alternative for the API design would splitting the
current one: We could create a very basic messaging API with only the
sending part and move the subscription part to the already planned API for
accessing message folders as, at the end of the day, they will have similar
security considerations and requirements for handling messages content.

Any feedback will be extremely welcome
Best Regards

[1] http://www.w3.org/TR/api-perms/
[2] http://www.w3.org/TR/messaging-api/
[3] http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0053.html
[4] http://lists.w3.org/Archives/Public/public-device-apis/2010Oct/0047.html
[5] http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0019.html
[6] http://lists.w3.org/Archives/Public/public-device-apis/2010Aug/0021.html

Received on Tuesday, 2 November 2010 08:53:14 UTC