User:Dantman/Post to social media feeds
Some notes after reading strategy:Product Whitepaper#Red link: Post to social media feeds.
Option: Static links
[edit]A simple option of keeping privacy is to only implement sharing features with static links, perhaps with locally stored images for services.
- Pros
- Simplest implementation
- Complete opt-in
- Cons
- Very non-interactive
- Relies on window/tab popups which aren't the nicest thing
- Some services might be missing a simple share link (+1/G+ has no static share right now that I know of, Facebook only supports Share, not like)
Option: Click to enable
[edit]One option to retain privacy till explicitly opting in would be to implement the sharing box such that nothing is loaded until the user clicks on the box, after which services are able to load.
- Pros
- Simple implementation.
- Works with existing service providers.
- Cons
- User sees very little until after they have opted in.
- It may be fairly easy for a user to "opt-in" and lose privacy when they did not intend to.
- For some services after opt-in it may be necessary for us to permit them to have a 3rd party script running in our page. Frankly even after opt-in this is not a very good thing to allow.
Option: Safe Sharing implementation
[edit]Based on things currently out in the wild we could implement a protocol and code that allows us to provide the user with interactive buttons to share a page on different services. The counters that some services use can be implemented privately by having the MW server do the fetching of this information and relaying it to the user instead of the browser directly fetching it. We will also be able to implement a clean consistent and intuitive ui for sharing while maintaining complete privacy for the user up to the point they actually start entering info for sharing.
One idea to allow the implementing of inline sharing (no pop up window) while keeping 3rd party scripts off the page would be to have a bubble like the one that Google's +1 button has and inside of it embed an iframe to a url which the service provides to input and share. This could be made fairly interactive by using html5's window.postMessage where available but falling back to a usable but somewhat less interactive interface when postMessage is not available. eg: When postMessage is available the bubble could auto-close when the iframe sends a message to the parent page. Without it the iframe will have to display a simple message to the user when finished, and the user will have to dismiss the window themselves. Likewise resizing of the bubble area to a different size than the initial definition might not be possible without a postMessage and the sharing provider might need to define something good enough, and avoid features that need to expand that region. (Would need to double check that postMessage is the only option, there might have been some potential hacks to work around it for some features)
- Pros
- We can control the whole thing and give the user privacy up to the point they actually try to start sharing something.
- We can provide the user a clean and consistent sharing interface.
- Since we output everything on our end we can make good use of resource loader and don't need to slow down WP with extra requests for images. (I think)
- Cons
- We must get every provider we wish to add to add support for the protocol themselves. Some may not be very open to implementing an open standard which would leave us with little use to our users. (That said, it's possible "This is likely the only way you will get a sharing feature on Wikipedia" may carry some weight)
- May be a moderately large development effort.
- Some types of extensibility may need to be written in as part of the protocol and implementation as we will not allow services to just inject scripts into our pages.
- Still likely to be near impossible to implement in a way where we know early if the user has already shared something (ie: a like button will look the same whether they already liked something or not, at least until they try to like it again)
Current art for reference
[edit]- http://www.oexchange.org/ - Open protocol for sharing links.
- Relies on a page-open model, we may want to create an alternative protocol based on oexchange that would allow tighter and simpler ui integration that current share/like/+1 buttons provide but still in a safe way. Making this an extension of oexchange would let us support existing oexchange providers but also allow them to add support for a better way.
- http://xauth.org/ - Useful to provide lists of share links in a vendor neutral but sane way.
- We may want to contribute development to their service based code.
- Needs to be checked to see if it can be made private enough ie: Made such that even xauth.org can't track a user's use of Wikipedia.
External links
[edit]- http://www.javascriptkit.com/javatutors/domstorage2.shtml - A proprietary IE technology that could be used to emulate localStorage pre-IE8 and make the xauth idea work more widely.
- http://www.onlineaspect.com/2010/01/15/backwards-compatible-postmessage/ - An idea how to implement a postMessage alternate in browsers that don't support it.
Notes
[edit]- Can XAuth's postMessage technique be done in a way that keeps say the xauth.org from being able to see the url the user is visiting.
- Does wrapping the xauth.org iframe inside of a proxy iframe change anything?