postMessage was chosen for having a familiar API and already
designed for potentially untrusted collaboration sources. (See the
README section "Comparison with similar WebAPI work" for other possibilities.)
Before discovering the command line handling, I originally sought to have the executable create a temp file containing an ID and path and mode info while supplying that to the add-on via a URL which would in turn check the temp file (this approach might work for other browsers if they do not allow add-ons to check command line arguments).
A direct visit to the protocol (including through XSRF) should provide no side effects. However, it is possible that a malicious handler opened by the user in "edit" mode could provide immediate side effects by saving back data to overwrite the supplied file. This might be mitigated by a configurable option to require the user's consent upon each save and/or to inform the user of the proposed diffs before saving. But again this will only be possible upon user initiation, only for the specific file or files approved in a given session.
The allowance for custom modes in addition to fundamental modes helps the user avoid the need to swap handlers whenever they wish to go directly to an app (or a part of an app) which brings the precise functionality they are seeking at the moment. It allows niche apps (such as HTML source viewers) to avoid registering themselves as handlers in a manner that would conflict with other normally more useful apps that would act on the same file type (e.g., a WYSIWYG HTML viewer). Fundamental modes are limited to those which genuinely require a distinct mode of transmission or privileges (e.g., editing vs. viewing or normal vs. binary) whereas custom modes imply no difference at the file processing level; the information is only meaningful to apps.