Firefox3/ContentManagement:Scenarios

Background

A feature targeted for Firefox 3 is to allow web services to act as "content handlers" in basically the same way that desktop applications do today. During the development of this feature, however, there's been a growing debate about whether the current GET-only specification from the WHAT WG will work well for all the basic use cases.

See: http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers

Specifically, the biggest issue is that the current spec only allows information to be passed to the web services via a URI. This can pose challenges in at least a few scenarios:

• The data cannot be referenced by a URI (e.g., microformats)
• The URI is not publicly accessible (e.g., behind a login)

Use Cases

I believe the following set of use cases are both common (what we're trying to enable) and relatively complete (cover all major code paths):

1. click a mailto: link
   • data used by web app = URI parameters for To:, Subject:, etc.
   • GET = yes ; POST = no (at least not easily)
2. subscribe to a feed
   • data needed by web app = feed URL
   • GET = yes ; POST = no (unless feed has rel="self" URI... still inefficient)
3. open a word attachment from Yahoo! Mail in Google Docs & Spreadsheets
   • data needed by web app = .doc file
   • GET = no ; POST = yes (though perhaps slow)
4. add an event on a web page to Google Calendar
   • data needed by web app = hCal microformat
   • GET = no ; POST = yes

Considerations

In the discussion so far, the debate about introducing POST has centered around the user experinece and security/privacy.

User Experience

• Success -- What is the likelikhood that it will actually work?
• Performance -- How well does it perform?

Going out on a limb here... but I'll say that something having a reasonable chance of working trumps how fast it will work. In the case of files and microformats, a GET-based approach will often not work (in the case of files) or never work (in the case of microformats). POST-based approach does introduce the problem that uploading the file to a web app could take considerable time.

  Would likely need control UI for uploading to web service  ("Upload Manager" :-)

Security Privacy

Since the mechanisms are largely the same, it seems the biggest potential differences between GET vs. POST as far as security and privacy are concerned is precisely what data can be "leaked" to a third party. Each has it's pro's and cons

• GET
  • "Origin" -- The recipient web may know where the data originated from
  • File Name -- In some cases, the URI could give some indicaiton of the contents of the document, e.g, "http://witehouse.gov/Bin_Laden_Determined_to_Attack_Inside_US.doc"
  • 'Credentials-- In some cases, a username and password may be embedded within a URI.
• POST
  • File Contents -- The user may set a default handler for a file type, thinking it was fine for most cases, and then click to open a sensitive document, forgetting that it will get sent to a web app.

 Both GET & POST need some strategy for communicating potential data leakage to user

Implementation Approaches

Am I missing any?

1. GET-only -- The current WHAT WG approach.
2. POST-only -- Wouldn't make any sense for protocol handlers.
3. User Chooses -- User would choose how the data would be passed. Obviously, very few users are technically sophisticated enough to make this decision.
4. Web App Chooses -- Each web app would choose whether it wanted data sent via GET or POST at registration time and per protocol, MIME-type, etc.
5. Per Use Case -- Update the standard to segment by use case which use GET and which use POST. For example, it could be something like:
   • Protocols use GET
   • Feeds use GET -- A special case of Files where the user intent is not for the app to process the data in the file, but to store it's URI for future updates. It's also a special case in that it can be triggered both by either a protocol (feed:/) or a MIME-type (application/rss+xml).
   • Files use POST
   • Microformats use POST

Proposal

The last option seems by far the most natural. Perhaps it could look something like this:

• registerProtocolHandler(protocol, uri, title)
  • where "uri" includes a "%s" for substituting the escaped protocol URI
• registerFeedHandler(feed-type, uri, title)
  • where uri includes a %s for substituting the feed URL
  • where feed type specify "text", "audio", "video", "image"??
• registerFileHandler(mime-type, uri, title)
  • "uri" doesn't need "%s", instead content will be POST'ed
• registerMicroformatHandler(name,uri,title)
  • where "name" is the name of the microformat type

This differs from the current WHAT WG spec in the following ways:

• registerProtocolHandler is unchanged
• registerContentHandler would be a deprecated alias to registerFeedHandler (since that's all it's used for today)
• registerFileHandler and registerMicroformatHandler would be new POST-based registrations