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

Hi Thomas,
Thanks for your feedback, see below my comments/questions.

Today I start my Holidays so I am afraid I won't be able to update the spec
until late August. Maybe any of the other editors can do it in the meantime.

Best regards
Mar燰 

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Thomas Roessler
> Sent: jueves, 05 de agosto de 2010 11:06
> To: Mar燰 聲geles Oteo
> Cc: Thomas Roessler; Frederick.Hirsch@nokia.com; public-device-
> apis@w3.org
> Subject: 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.)
> 

OK, so are you suggesting that when the spec speaks about e-mail address we
include a reference to RFC 5322? I agree with that proposal.

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

OK, I was assuming that the implementation should be the responsible for
creating the multipart message (obviously with the current version with only
1 part). We could add support for multipart for MMS/Email. The question is
whether it should be just an alternative or the only way to create an
MMS/Email (i.e. body cannot be a DOMString anymore)? 


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

Ok

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

This is a mistake in the spec inherited from the previous version in which
paths were used instead of Blobs.


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

Fine with me, shall add it.

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

I'll try to split the considerations and be more specific.

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


 I agree that depending on whether the API is used from Web Pages or Widgets
the security considerations may be different, I can stress it in the spec.
We hope the security framework defined in DAP WG is capable of handling this
scenario (different policies depending on the origin).


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

What other kind of authorization you have in mind? I think that a
single-shot prompt as suggested is already very restrictive.

By the way, it looks like we should remove the second sentence on the
following paragraph:

"Obtaining once the user's express permission to access those methods does
not imply the user has granted permission for later invocations of the same
method or any other method provided by this API. This is especially
important in the case of message sending, as every method invocation may
lead to extra charges to the user."


> 
> 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燰 聲geles 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燰
> >
> > [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 Friday, 6 August 2010 09:03:57 UTC