IUSEA and U Should too’a
I want to share a new architectural pattern for web applications and services that Mozilla has been using to empower the user and put them back in control of their data and their web.
An Example
I use’a the Gmail,
I use’a the LinkedIn,
Why they no’a work’a together? — Mario
Well Mario, if Google and LinkedIn used the IUSEA pattern, they would!
- Mario’s browser requests
https://gmail.com/email/compose - That page includes a script tag to
https://linkedin.com/contacts_include.js - Mario starts typing ‘Al’ in the To: field
- Gmail’s JavaScript calls
LinkedIn.autocompleteContact('Al') - If Mario’s session with LinkedIn.com has timed out, he is prompted to login in a new window. This is the same login screen as he sees everyday
- LinkedIn asks Mario if he wants to expose his contacts
- Mario clicks yes
- Gmail receives rich contact data for Al and Alice, including a picture, degrees of seperation from Mario, etc
- Gmail uses this rich data to improve their contact picker
- Mario clicks Alice and finishes writing his email
IUSEA – Intentional User Service Exposure Architecture
If your building a web application or service, you should continue to provide REST APIs for public data, but user data should be exposed via IUSEA where possible.
Technical Details
LinkedIn’s contacts_include.js defined a autocompleteContact function. How is it implemented?
It opens a hidden br to https://linkedin.com and uses a postMessage based protocol to ask for contacts that have a first, last name, or email that start with ‘Al’.
LinkedIn.com hosts a page that is the br’s target. It authenticates the user, makes sure the user wants to expose this information, and delivers the data back Gmail via postMessage.
This pattern is ready today and works across Browsers, OS, Desktop, and Mobile. Mozilla’s jschannels library is an easy way to rock this, even on IE.
Isn’t this just OAuth?
As a developer, your thinking “Congrats, you’ve re-invented the OAuth wheel.”
OAuth is about server to server data sharing:
Value in this diagram means value for the user and the service provider, such as a user’s contacts.
IUSEA puts the user back into the center. Value resides in each server but also is controlled by the user and flows through the user at their discretion.
Business Details
Did you notice that all happened in the browser? Technically, Gmail doesn’t need to upload this new LinkedIn data to their servers, since all the user benefit was provided directly in the Gmail web UI.
Going one step further, LinkedIn could provide this API with a TOS that forbids Gmail from importing this user data… wow.
Google can fulfill it’s mission to to organize the world’s information and make it universally accessible and useful. LinkedIn can fulfill it’s mission of connecting the world’s professionals to make them more productive and successful. The user wins as they gain more control of their data, while being able to reap the benefits across the web.
IUSEA (a term I made up to help explain this concept) is the secret sauce we’re applying liberally, and you can start using this pattern in your products.
IUSEA and U should too’a.
Disclaimers, Image Credits
- Nintendo, Google, and LinkedIn don’t have anything to do with each other and the example is hypothetical.
- Male User Icon
- Mario image is copyright Nintendo, Gmail for Google, and LinkedIn to LinkedIn.
- Gmail Fluid Icon
- LinkedIn Fluid Icon
4 Responses to “IUSEA and U Should too’a”
Nice idea, but a ToS doesn't actually protect the user's data. Ideally, I'd suggest using this together with something like OAuth (not necessarily OAuth, but something equivalent) to explicitly let the user grant or deny fine-grained permissions on a site-by-site basis.
While I like the pattern, I wonder about the performance and privacy impacts of using a bunch of these Apis.
How do we do the UX so the user opts-in to sharing their LinkedIn contacts with gmail?
Does LinkedIn now know every time I start to compose an email on gmail?
Do I now need to connect to a bunch of different servers when I open a compose window? Doesn't that lose us the benefits of SPDY?
While webintents are an over designed, unwebby mess, I think we do need some additional bits to allow this kind of sharing without these downsides.
Agree with Anon; TOS simply won't suffice. Imagine I'm Luigi and I've been using Linkedin for years and then suddenly my data becomes party to something like this without my consent. Immediately I start becoming exposed to all sorts of data leakage to unknown entities without me having a say in it.
@David - Great points! This pattern is a very small and low level pattern that needs to be combined with higher level patterns. It is in use today, but we have a hard time discussing it, so I wanted to capture it without all of the related concerns that are brought in at a higher level.
@Anonymous - "ToS doesn't actually protect the user's data. " - IANAL and probably should have left that out of the post. When I use OAuth to let Gmail mine all of my contacts, doesn't LinkedIn depend on their API TOS to keep Gmail from reselling or sharing that data to third parties? OAuth flows are great for asynchronous features the user needs (notifications, payment charge backs, etc) but for disclosing the least amount of information and keeping the user as an active party in an interaction, I don't see how OAuth (as it's commonly used in the wild, long lived access tokens) can give more user control.
@Anonmous 2 - The point of this pattern is explicit user consent.