A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Sharing: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Created page with "Figuring out sharing for the web. == Actors == * End user * Items that can be shared (share item) * Place that has items to share (share source) * Place items can be shared ...")
 
No edit summary
Line 4: Line 4:


* End user
* End user
* User agent
* Items that can be shared (share item)
* Items that can be shared (share item)
* Place that has items to share (share source)
* Place that has items to share (share source)
* Place items can be shared with (share destination)
* Place items can be shared with (share destination)
(Could potentially merge share source and share item.)


== Use cases ==
== Use cases ==
Line 23: Line 26:
Share destination could be displayed on top of share source. In case of  Twitter this might require almost the entire screen (on mobile). In case of Pocket this would not require much UI at all in the simple case.
Share destination could be displayed on top of share source. In case of  Twitter this might require almost the entire screen (on mobile). In case of Pocket this would not require much UI at all in the simple case.


Thus, an inline overlay of which the security properties are somehow still clear to the end user.
Thus, an overlay browsing context of which the security properties are somehow still clear to the end user.


== Requirements ==
== Requirements ==
Line 31: Line 34:
Requiring a secure origin for a share source seems like too much of a burden.
Requiring a secure origin for a share source seems like too much of a burden.


== TODO ==
== registerProtocolHandler() ==


* Analyze registerProtocolHandler()
* Open-ended scheme names does not work when UI requires knowledge about its scheme name. ("Can Gmail handle 'mailto'?" vs "Can Gmail handle email links?")  
* Replaces the current browsing contexts or spawns a new one. No overlay
* Limited to sharing things that can be expressed through a URL


== Resources ==
== Resources ==

Revision as of 16:49, 4 August 2014

Figuring out sharing for the web.

Actors

  • End user
  • User agent
  • Items that can be shared (share item)
  • Place that has items to share (share source)
  • Place items can be shared with (share destination)

(Could potentially merge share source and share item.)

Use cases

Brief: E wants to share I (image, URL, ...) from S (The New Yorker, xkcd, ...) on D (Twitter, Facebook, Pocket ...)

Longer:

Note that The Boston Globe needs no knowledge about the share destinations. And Pocket does not need to be known by all share origins.

UI speculation

Share destination could be displayed on top of share source. In case of Twitter this might require almost the entire screen (on mobile). In case of Pocket this would not require much UI at all in the simple case.

Thus, an overlay browsing context of which the security properties are somehow still clear to the end user.

Requirements

As this is a new API, a secure origin (TLS) is required to be a share destination.

Requiring a secure origin for a share source seems like too much of a burden.

registerProtocolHandler()

  • Open-ended scheme names does not work when UI requires knowledge about its scheme name. ("Can Gmail handle 'mailto'?" vs "Can Gmail handle email links?")
  • Replaces the current browsing contexts or spawns a new one. No overlay
  • Limited to sharing things that can be expressed through a URL

Resources