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 ...")
 
 
(11 intermediate revisions by 2 users not shown)
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 12: Line 15:
Brief: E wants to share I (image, URL, ...) from S (The New Yorker, xkcd, ...) on D (Twitter, Facebook, Pocket ...)
Brief: E wants to share I (image, URL, ...) from S (The New Yorker, xkcd, ...) on D (Twitter, Facebook, Pocket ...)


Longer:  
Longer: End users want to share http://www.boston.com/bigpicture/2014/07/conflict_continues_in_gaza.html from The Big Picture with their preferred social network or private database.
 
== Ideas ==
 
* Provide UI to share the current URL
* Provide API to add share destination
* Provide new "overlay browsing context" to display share destinations when sharing is initiated (ideally using limited space so the share source remains functionally useful on desktop)
* Expose sharing to service workers?
 
=== Share UI ===
 
Revamp user agent bookmarks. Bookmarks are about sharing the current URL with yourself. We could generalize that concept to share that URL with Twitter, Pocket, or any other service that gets itself added as share destination.


* The Boston Globe wants to allow users to share http://www.boston.com/bigpicture/2014/07/conflict_continues_in_gaza.html with their preferred social network or private database.
=== Overlay browsing context ===
* And the converse: Pocket would like to allow end users to share items around the web with it.


Note that The Boston Globe needs no knowledge about the share destinations. And Pocket does not need to be known by all share origins.
* Displays e.g. Twitter's compose tweet dialog loaded from https://twitter.com/share (conceptual URL)
* Protects against spoofing so other sites cannot imitate Twitter's login dialog there
* Ideally provides some way to do transparent backgrounds to enable the kind of UI Pocket would like, without compromising on security
** To expand on that, sharing UIs will typically involve accepting the user's authentication info, one risk here is to overlay a UI on top of the page in a way that doesn't make it obvious to the user that the UI is not part of the page itself. Once a user is trained to accept these types of subtle overlays, evil.com may try a phishing attack by rendering the Pocket UI inside its own frame and asking for the user's auth info.


== UI speculation ==
=== Service workers ===


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.
When the user wants to share with a share destination, dispatch an event in share destination's service worker and allow it to chose whether to display an overlay browsing context, or perhaps show a notification, or show nothing at all.


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


== Requirements ==
* 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.
* Share nothing other than the share item and the origin of the share source with the share destination (e.g. no DOM access).


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


Requiring a secure origin for a share source seems like too much of a burden.
* 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


== TODO ==
== TODO ==


* Analyze registerProtocolHandler()
* Scope of share items: restrict to URL of the share origin for now?
** (ehsan) I think we may need to handle more than just the URL, for example if the user wants to share an embedded image/video on a site.
* Share destination registration UI
* Share UI: user-agent-initiated or share-source-initiated?
** (ehsan) the web has pretty much settled on the latter at this point.
** (ehsan) are we talking about telling the share source about the user's preferred search service or get them to call an API which does this opaquely?
* (ehsan) Should we integrate [http://opengraphprotocol.org/ OGP annotations]?
* (ehsan) Sharing providers typically want to be able to show their UI *before* the sharing happens too.


== Resources ==
== Resources ==
Line 42: Line 68:
* https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
* https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities
* http://www.imore.com/sharing-ios-8-explained
* http://www.imore.com/sharing-ios-8-explained
* https://wiki.gnome.org/Design/OS/Sharing

Latest revision as of 14:10, 2 July 2015

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: End users want to share http://www.boston.com/bigpicture/2014/07/conflict_continues_in_gaza.html from The Big Picture with their preferred social network or private database.

Ideas

  • Provide UI to share the current URL
  • Provide API to add share destination
  • Provide new "overlay browsing context" to display share destinations when sharing is initiated (ideally using limited space so the share source remains functionally useful on desktop)
  • Expose sharing to service workers?

Share UI

Revamp user agent bookmarks. Bookmarks are about sharing the current URL with yourself. We could generalize that concept to share that URL with Twitter, Pocket, or any other service that gets itself added as share destination.

Overlay browsing context

  • Displays e.g. Twitter's compose tweet dialog loaded from https://twitter.com/share (conceptual URL)
  • Protects against spoofing so other sites cannot imitate Twitter's login dialog there
  • Ideally provides some way to do transparent backgrounds to enable the kind of UI Pocket would like, without compromising on security
    • To expand on that, sharing UIs will typically involve accepting the user's authentication info, one risk here is to overlay a UI on top of the page in a way that doesn't make it obvious to the user that the UI is not part of the page itself. Once a user is trained to accept these types of subtle overlays, evil.com may try a phishing attack by rendering the Pocket UI inside its own frame and asking for the user's auth info.

Service workers

When the user wants to share with a share destination, dispatch an event in share destination's service worker and allow it to chose whether to display an overlay browsing context, or perhaps show a notification, or show nothing at all.

Constraints

  • 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.
  • Share nothing other than the share item and the origin of the share source with the share destination (e.g. no DOM access).

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

TODO

  • Scope of share items: restrict to URL of the share origin for now?
    • (ehsan) I think we may need to handle more than just the URL, for example if the user wants to share an embedded image/video on a site.
  • Share destination registration UI
  • Share UI: user-agent-initiated or share-source-initiated?
    • (ehsan) the web has pretty much settled on the latter at this point.
    • (ehsan) are we talking about telling the share source about the user's preferred search service or get them to call an API which does this opaquely?
  • (ehsan) Should we integrate OGP annotations?
  • (ehsan) Sharing providers typically want to be able to show their UI *before* the sharing happens too.

Resources

Retrieved from "https://wiki.whatwg.org/index.php?title=Sharing&oldid=9957"