Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
On 2/22/11 5:02 PM, Matthew A. Miller wrote: > On Feb 22, 2011, at 13:04 , Hannes Tschofenig wrote: > >> I wonder what your strategy is to get native XMPP code into the browser (not >> just as a plugin). >> In case you have a strategy there are probably a few other things that would >> deserve attention. Examples: security, and privacy features. >> To some extend the recently created woes mailing list also touches on these >> problems. > > There's been a mostly unspoken agreement to continue this conversation at > j...@jabber.org. Please feel free to repost this there; some of this has > been addressed already, so you'll want to check the list archives. As I learned a few months ago, never forward something to more than the intended discussion list. :) The jdev list is here: http://mail.jabber.org/mailman/listinfo/jdev Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
On Feb 22, 2011, at 13:04 , Hannes Tschofenig wrote: > I wonder what your strategy is to get native XMPP code into the browser (not > just as a plugin). > In case you have a strategy there are probably a few other things that would > deserve attention. Examples: security, and privacy features. > To some extend the recently created woes mailing list also touches on these > problems. There's been a mostly unspoken agreement to continue this conversation at j...@jabber.org. Please feel free to repost this there; some of this has been addressed already, so you'll want to check the list archives. - m&m > > On Feb 22, 2011, at 9:14 PM, Peter Saint-Andre wrote: > >> On 2/22/11 12:03 PM, Joe Hildebrand wrote: >>> On 2/22/11 5:09 AM, "Hannes Tschofenig" wrote: >>> Aren't there XMPP implementations in the browser already out there? Example: Strophe http://code.stanziq.com/strophe/ So, what are you guys planning to do on top of it? >>> >>> Those implementations use BOSH (XEP-124 and XEP-206) to tunnel XMPP over >>> HTTP. Having a full XMPP stream on a single TCP socket can be more >>> efficient, secure, and easier to deploy. The nice thing is that >>> implementations could choose to fall back on BOSH if XMPP-in-browser didn't >>> work. >> >> Right. This "XMPP in the browser" meme is about native XMPP-Over-TCP >> support in browsers, not XMPP-Over-BOSH support. >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> > smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
I wonder what your strategy is to get native XMPP code into the browser (not just as a plugin). In case you have a strategy there are probably a few other things that would deserve attention. Examples: security, and privacy features. To some extend the recently created woes mailing list also touches on these problems. On Feb 22, 2011, at 9:14 PM, Peter Saint-Andre wrote: > On 2/22/11 12:03 PM, Joe Hildebrand wrote: >> On 2/22/11 5:09 AM, "Hannes Tschofenig" wrote: >> >>> Aren't there XMPP implementations in the browser already out there? >>> Example: Strophe http://code.stanziq.com/strophe/ >>> >>> So, what are you guys planning to do on top of it? >> >> Those implementations use BOSH (XEP-124 and XEP-206) to tunnel XMPP over >> HTTP. Having a full XMPP stream on a single TCP socket can be more >> efficient, secure, and easier to deploy. The nice thing is that >> implementations could choose to fall back on BOSH if XMPP-in-browser didn't >> work. > > Right. This "XMPP in the browser" meme is about native XMPP-Over-TCP > support in browsers, not XMPP-Over-BOSH support. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > >
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
On 2/22/11 12:03 PM, Joe Hildebrand wrote: > On 2/22/11 5:09 AM, "Hannes Tschofenig" wrote: > >> Aren't there XMPP implementations in the browser already out there? >> Example: Strophe http://code.stanziq.com/strophe/ >> >> So, what are you guys planning to do on top of it? > > Those implementations use BOSH (XEP-124 and XEP-206) to tunnel XMPP over > HTTP. Having a full XMPP stream on a single TCP socket can be more > efficient, secure, and easier to deploy. The nice thing is that > implementations could choose to fall back on BOSH if XMPP-in-browser didn't > work. Right. This "XMPP in the browser" meme is about native XMPP-Over-TCP support in browsers, not XMPP-Over-BOSH support. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
On 2/22/11 5:09 AM, "Hannes Tschofenig" wrote: > Aren't there XMPP implementations in the browser already out there? > Example: Strophe http://code.stanziq.com/strophe/ > > So, what are you guys planning to do on top of it? Those implementations use BOSH (XEP-124 and XEP-206) to tunnel XMPP over HTTP. Having a full XMPP stream on a single TCP socket can be more efficient, secure, and easier to deploy. The nice thing is that implementations could choose to fall back on BOSH if XMPP-in-browser didn't work. -- Joe Hildebrand
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
Aren't there XMPP implementations in the browser already out there? Example: Strophe http://code.stanziq.com/strophe/ So, what are you guys planning to do on top of it?
Re: [Standards] [jdev] Fwd: XMPP in the browser -- your thoughts?
On Mon Feb 21 19:11:09 2011, Matthew A. Miller wrote: One of the guerilla conversations at the XSF Summit was about XMPP usage in the browser. Below is the first documented follow-on. Most of the rest of the responses were about general acceptance of the concept, hence they're omission. I'll try to forward the more substantive comments soon (and/or urge the original participants to respond again here). I'd note that "here" seems to be jdev. I've copied my response in to both standards and social - the latter because I think that's the community most likely to be interested, and it'll prod them into joining the conversation - but for now at least responses to jdev. I do think we should work on a solid, thought-through proposal, ideally with some degree of implementation experience. > Websockets are a terrific idea that suddenly got put on hold this year. But perhaps Websockets' stumble sets us up to take a closer look at something else. > WebSockets appear to be moving again, to my eye - however this is largely because several people - including myself - who thought the entire thing had gone to pot have all but quit making any comments. > A few things that browser-based XMPP would help make possible: I don't think any of these will be contentious to this community. :-) > I believe the critical opposing arguments that will be voiced fall into one of several categories: However, these were all, I think, way off the mark, based on my experience with the delights of HyBi. The criticism will centre on two aspects, and we should ensure we have a compelling story for both. Firstly, security. What we need to understand is that the web browser vendors feel that security starts and ends at the browser. So WebSockets got derailed into insanity essentially due to a vulnerability that isn't even proven to exist, hence the reason that it's now encrypted on the outflow from the browser. So we need to ensure that for Web integration, we have suitable hooks into the Web authorization model, which is basically the SOP and CORS. So we'll need Origin controls for allowing connections from a browser. Now you're forgiven for thinking that since we can't retrofit these as a mandatory portion of the server, then therefore we also cannot do anything useful in this regard, but it's important to note that the browser vendors believe that their products will suitably sandbox the protocols; in other words, if we mandate that the first thing an XMPP client in a browser does when setting up a session, or prior to handing over control to the Javascript, is query the server and/or service as to whether the Origin is allowed to work its magic, then we can actually rely on this happening. This is largely because we won't be allowing unmediated access to XMPP, instead we'll be providing some kind of Javascript layer onto an XMPP session entirely under the browser's control. So, *before* we approach the browser vendors, we need a compelling story on Origin-based security. Next, deployability. There's this myth of the amateur programmer floating about, and many flocks of ideas have been shot down with that particular cannon. In practical terms, this means we need to get strong anecdotal evidence that setting up an XMPP server, and having users provisioned with XMPP accounts as required, are both simple and straightforward things to do. I see this as a task for the communications teams of the XSF, involving interviewing people building services on XMPP and stressing how easy it all is to do. I can't imagine that there'll be much resistence from such people to talk about their services, and it'd be interesting content for the blog anyway. So, again before approaching the browser vendors, we need a compelling story on ease of deployment. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
