A short thread on G+ has prompted this longer sharing of my vision for XMPP on the web.
For XMPP use on a website we currently have BOSH and, in an extreme-alpha state, XMPP over websockets. The advantage of websockets is obvious, BOSH is a high overhead protocol that we'd all rather not have to use, however both have the same problem: you either must share your login credentials (and thus access to your account) with every website you use a single account with, or must create a new account (JID) for every XMPP-based website you use.
Oauth2 for XMPP might be a partial solution to this by requiring your authorization through a central identity site and using the resulting token for logging in, however, you're still opening yourself up to the 3rd party website accessing your roster, sending spam messages on your behalf, and potentially worse. All this really gives you is the ability to later disable access to websites who misuse your account.
This is the crux of the issue: when using an Javascript library provided by a website and using a proxy provided by that website, whether BOSH, websockets, or otherwise, you're giving that website unlimited access to your account. I have not seen a workable proposal to solve this and until this is solved XMPP cannot see widespread use on the web.
I'm proposing that we solve this by putting XMPP in the browser, either directly or through a plugin. Expose a standard javascript API for allowing websites to use an XMPP connection along with a security model which gives users control as to what a website is allowed to use their connection for. Ie, if a script on a website wants access to their roster the user will be prompted for it, if they want to join a MUC room display a standard prompt for that. Browsers can have multiple XMPP sessions at once and allow the user to select which account they'd like to use with an XMPP-enabled site.
This is just some early ideas, I'm nowhere near implementing this though I think the conversation would be useful to get started.
2 comments:
Very interesting, I can actually see something like this being implemented in Chrome (first as an extension via NPAPI, and then perhaps as Chrome itself).
NPAPI would cover Firefox, Chrome, Opera, and Webkit-based browsers all at once - basically everyone but MSIE.
That's the relatively easy part, the hard part is working out the security details. This needs an XEP and a lot of thought into how to separate the functions by permission; which functions can safely be open, which functions can safely be open by "same-domain" only, and which functions the user should have to authorize.
What does "same-domain" mean crossing between HTTP-delivered javascript and XMPP services, or must we use a cross-site access control mechanism in XMPP which specifically whitelists HTTP domains?
Can javascript be used when its delivered over XMPP (eg, via PubSub embedded in XML) and what should its scope be?
Post a Comment