A link sharing protocol enables a better user experience for copying a link
from viewed Web content to a Web service. For example, a link sharing protocol
improves the user experience of adding a link to a user's published comment
stream. The content Publisher that offers a link to be
shared, and the Service that receives the shared link,
are also stakeholders whose interests can be enhanced by a link sharing
protocol. Here we list the features that improve link sharing and compare
proposed protocols.
In the Status Quo protocol for link sharing, a <script>
element is used to import Service script
into a Publisher's page. The content and
behavior of the imported script is specific to the particular Service. Integrating with multiple Services requires importing multiple scripts, each of
which will create its own user interface.
A Publisher can connect to Services that do not support a common link sharing
data format without resorting to a NASCAR user interface. Link sharing is a
relatively new application and so we must expect new and better protocols and
interaction patterns to be created. A Publisher should be able to initiate an
interaction with any of these different Services without needing a custom sharing initiation
UI for each of them.
During a sharing action, each presented Service option is prevented from immitating the
others. A malicious Service might engage in
this immitation in order to steal a sharing action the user intended to complete
with the immitated Service.
The user can tell which Publisher is
initiating a sharing action. A malicious Publisher might try to broadcast their own content
by making it look like the sharing action is being initiated by a trusted
Publisher.
Completing a sharing action does not leave behind any permissions usable by
the Publisher and so that must be later
reviewed and possibly revoked by the user. For example, this constraint would be
violated if completing a sharing action required granting a Publisher permission to send many items over time
to the Service.
A Service can safely complete a link
sharing action initiated from the Publisher's Web content without presenting
a user confirmation dialog. This constraint cannot be satisifed if the link
sharing protocol does not protect the sharing initiation action against UI
redress or clickjacking attacks.
During a sharing action, the Service can
present an arbitrary user interface of limited size within the Publisher's Web content. For example, the Service might collect a short text comment from the
user to accompany the shared link.
During a sharing action, the Service can
also open a top-level browsing context so as to present a user interface that
cannot be manipulated by the Publisher. To provide a trusted path, the opened
window must be a full size window and not a smaller popup window, since a
malicious Publisher can perfectly immitate
a popup window using a <div> element and so capture user
interaction intended for the immitated Service.
A sharing action can be completed even when the user-agent is offline. The
selected Service receives the shared link
while the user-agent is offline and can later upload the link to its site when
Internet connectivity is restored.
Both a Publisher and the Service selected for a sharing action can send the
other an arbitrary number of messages. Normally the Publisher simply sends a link to the Service; however, the Service should be able to respond back after an
arbitrary delay and the Publisher can in
turn respond to this response and so on.
Both the Publisher and the Service can be put into a zero power sleep state
while waiting for an event from the other. This feature is important when full duplex messaging is supported.
A Service only receives information
when it is selected for a particular link sharing action and the received
information is limited to that explicitly provided by the Publisher. If a protocol does not support clickstream privacy, it necessarily does not
support sharing privacy.
→ features