Review: browser use case; e-mail compatibility? (Re: Message API Status)

I had taken ACTION-222 to review the security considerations.

I took the opportunity to do a more general review of the overall API, and noticed a few things along the way:

1. EMail address syntax is a fairly complex beast.  Please refer to specific productions from RFC 5822 when talking about things like e-mail addresses.  (You could either mean an address, a mailbox, or an addr-spec. Note that an address may include a list of mailboxes.) 

2. We currently model a message as a (text) "body" and an array of blobs that we call "attachments."

Please use the terminology from RFC 2045 section 2 in order to model MIME.  Also note that the model we use might very well be sane for composing e-mails (we have a choice about the complexity of the messages that we permit to be constructed through this API), but that it won't work on the receiving end. A message can have a multipart as its body, any of whose parts can be a multipart or a message by itself. That's not properly modeled in the current API.

Also, if we use the Blob interface, then we need to normatively reference the File API spec, which is where it is defined.

Finally, I don't know why we would use Blob to store the "list of paths to attachments that will be sent together with the" message.


About the security properties section:

1. The current text says: "Apart from billing implications, there are also privacy considerations due to the capability to access message contents." In fact, in many jurisdictions, the fact that a message is sent between certain parties is considered highly private, and possibly protected by specific legal rights and obligations.  I suggest to instead say: "The ability to subscribe to incoming messages reveals the parties to a communication, and possibly the content of the message, to the subscriber."

2. The privacy considerations are fairly generic. I would suggest separate and specific considerations for sending and receiving messages.

The effect of sending messages is largely a nuisance from a privacy perspective, and a possibly significant cost consideration for SMS and MMS (and e-mail during data roaming). The considerations should focus on that point.

There are probably distinct considerations for Web and widget use cases here. E.g., I wouldn't want a Web page to be able to send messages using my device's capabilities without giving me a chance to review and approve the message every single time -- much like what happens with mailto: URIs, i.e., typically through handing off the message to a native messaging application. However, if I have a local app that is my mobile device's main messaging application, then I wouldn't want to have that happen.

The effect of message notification, on the other hand, is significantly more nefarious from a privacy perspective, since it enables monitoring of my message in-flow. I don't know that a simple authorization as envisioned by the current security considerations will be appropriate.




Several of the observations here beg a more general question:  To what extent do we expect this API to be ever taken up outside of widget environments?

To enable message sending outside those environments, we have the mailto and sms URI schemes. And I don't know that we have a firm enough handle of the security and privacy considerations of the monitoring part that we'd want to see those implemented.

Thoughts, anybody?

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)







On 3 Aug 2010, at 10:30, María Ángeles Oteo wrote:

> Hi Frederick
> 
> I did the split and created the simplified version which already includes a
> more detailed security section so the action-221 can be closed. Dom already
> sent the FPWD Cfc [1].
> 
> Now we are working in the new specs for MessageFinder and Folder Management
> API.
> 
> Best regards
> María
> 
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0111.html
> 
> -----Original Message-----
> From: public-device-apis-request@w3.org
> [mailto:public-device-apis-request@w3.org] On Behalf Of
> Frederick.Hirsch@nokia.com
> Sent: lunes, 02 de agosto de 2010 23:56
> To: public-device-apis@w3.org
> Cc: Frederick.Hirsch@nokia.com
> Subject: Message API Status
> 
> Is the following accurate and complete? Do the editors or WG have any
> updates or corrections?
> 
> (1) Messaging API status (as of DAP F2F) [1]
> 
> The Messaging API editors draft was updated in advance of the F2F to split
> the APIs for different messaging technologies. APIs were added  for listing
> messages, methods added for folder management and moving messages between
> folders. The following resolution was reached during the F2F: RESOLUTION:
> Split Messaging, try to reach FPWD with just create/send/receive ASAP; have
> a separate MessageFinder API mirroring Contacts and Gallery; build folder
> management on top of that.
> 
> (2) Open Actions
> 
> This means there is an editorial action to perform this split, to simplify
> the Messaging API draft and move material into a new MessageFinder API draft
> (as well as removing folder functionality from the Messaging API draft).
> There was no explicit editorial action assigned, perhaps there should be.
> 
> The WG also agreed to add a security section before publishing, with the
> following related actions:
> 
> ACTION-221 -- Maria Angeles Oteo to draft a security section for Messaging
> 
> ACTION-222 -- Thomas Roessler to review the Messaging security section
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia
> Co-Chair, W3C DAP Working Group
> 
> [1] http://dev.w3.org/2009/dap/messaging/
> 
> 
> 
> 
> 
> 
>

Received on Thursday, 5 August 2010 09:06:14 UTC