Figuring out sharing for the web.
- 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.)
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.
- 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?
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.
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.
- 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).
- 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
- 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.
- Paul Kinlan on Web Intents: http://lists.w3.org/Archives/Public/public-device-apis/2014Jul/0023.html
- Jonas Sicking on Web Activities: https://wiki.mozilla.org/WebAPI/WebActivities/LessonsLearned