Review of the Messaging API

Hi all,

here's the review I proposed to do of Messaging.


# Abstract

    • "This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and e-mail." That's misleading. We should say something like "The specification provides a method to send messages based on URIs (e.g. email, MMS, SMS) with optional attachments."


# Conformance

    • "Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail) there is a need to indicate that conformant implementations need only expose available functionality." This Note is longer than the sentence that would replace it. How about "Since not all devices have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail), conformant implementations need only expose available functionality."

    • "Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification's terminology." -> "Implementations that use ECMAScript to expose the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL]."


# Introduction

    • "The Messaging API defines a high-level interface to messaging functionality, including SMS, MMS and e-mail. It includes APIs to create and send messages." See Abstract.

    • "a callback on success / error when a message is sent." Actually, given the implementation strategies we discussed, the callback will never indicate that a message has been sent or failed to — simply that it's been passed on to the platform's application that handles sending such messages (or that that has failed).

    • "The following code extracts illustrate how to create and send messages.\n\nSending an MMS with an attached picture, if device supports it." -> "The following code shows how to send a message with an attachment." The example itself should probably be rewritten to be more complete and realistic (e.g. triggered from some user interaction since it fetches a file from a form that needs to be populated first).


# Security Considerations

    • "In general, user’s consent is expected to be confirmed for each invocation of the sendMessage methods." I think that this is confusing because it gives the impression that there should be some form of in-browser UI prompt for permission, when in fact what is meant is that whatever is used for permission (typically, bringing up the platform MUA) should happen every time. I think the section could be reworded to clarify the expectation that invoking the applicable platform agent is probably the expected implementation, and derive the security implications from that).


# Supported messaging types

    • "Using a single method to send message across many protocols make it impossible to detect whether a given user agent supports a specific messaging protocol." Should we add a canSendMessage() method which would return unknown/yes/probably?


# SMS specific concerns

    • "depends on language encoding the content" -> "depends on the encoding of the content"
    • Personally, I would drop this section. It touches on underlying issues that are not concerns at the API level.


# DeviceMessaging

    • "The DeviceMessaging object is exposed on the navigator.device" I think we agreed to drop navigator.device and expose everything on navigator (or on whatever else — I don't care).

    • I don't think that we should call the first parameter "to", it should be "uri" otherwise there will be confusion.

    • I always get mixed up with these: should it be sequence<Blob> or Blob[]?

    • I really think that we need a success callback. You may have a UI that depends on the successful transmission of the message (if only to the MUA) and since it's async you can't know what's going on otherwise. Granted, it won't provide much useful information but it's still something.


# MessagingError

    • "Adds Messaging API specific error codes." I think we can drop this note.

    • The following errors are unlikely to ever be triggered: IO_ERROR, MESSAGE_SIZE_EXCEEDED, PERMISSION_DENIED_ERROR, TIMEOUT_ERROR

    • NOT_SUPPORTED_ERROR should clearly be used to represent unsupported schemes.

    • PENDING_OPERATION_ERROR is the error that other specs use to prevent running two tasks at once. I don't think that it's applicable here.

    • One attack vector (which should be documented in the security section) is that you could just keep calling sendMessage to flood the user's device with a zillion message prompts. There should be a TOO_MANY_MESSAGES error for when a UA-dependent rate of messages per minute (I'd put it very low) is reached. Note that we're not introducing a new security issues, just load the following HTML in your browser (at least in Firefox):

    <body onload='while (true) window.location = "mailto:robin@berjon.com"'>

Or, maybe don't do it.


That's all my feedback. If the above changes are made, it probably justifies a new release.

With this, ACTION-398 has met its minute taker.

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 25 May 2011 13:33:23 UTC