Suqashing Facebook (WAS: Conducting GNHLUG business on Facebook (was Stop! Unix Time))

Thomas Charron twaffle at gmail.com
Tue Feb 3 09:35:04 EST 2009


On Tue, Feb 3, 2009 at 1:56 AM, Arc Riley <arcriley at gmail.com> wrote:
> The beauty in this is you don't even need a XMPP client running on your
> machine to access this data.  If you have a client that understands the
> required extensions in a way that makes it useful to you, you can use your
> own client, or you can use a website that implements it - ie, just as you
> have a wiki account for gnhlug.org, you could have a
> ThomasCharron at gnhlug.org JID used only for the website gateway.  To you, a
> user of the website, XMPP support doesn't matter regardless if the XMPP is
> being run on the website backend or in your browser via a javascript client.
> Client support for extensions follow demand, so as such services come into
> mainstream the mainstream clients will support them.  At that point you can
> use a single JID for everything.

  As the original example showed, it can even control a toaster.  :-D
But there's no paradigm shift there.  JSON could also control a
toaster, given a specification.  But I digress.

  Your example is slightly counter to your argument.  The thought put
forth is that everyone can run a server of their own, with their own
web sites, etc.  So I'd be ThomasCharron at kilomonkies.com.  And how is
gnhlug.org going to know I'm me when I say, visit the web site?

>>  The crux of the complain is, however, that you have to authenticate
>> with facebook.
> No you don't.  There are many facebook apps that exist solely to provide
> facebook users access to offsite data (and vice versa).

  I'll be totally honest, I'm totally ignorant of it.  As others have
said, ANYTIME I see ANYTHING to do with facebook it stares at me with
a big phat login page.  And I press that big phat 'X' close the page
button.

> Take for example the roommate searching app.  It's actually being run by a
> 3rd party website that's been running that service for awhile - all the
> facebook app does is provide access to that data via facebook.  They could
> have taken it a lot further, such as when you post a "looking for apt" ad on
> their site, it could show "Thomas Charron is looking for a new apt on
> RoommateSearchPlus!".

  Show me an example.  I've never seen one that didn't eventually try
to suck me into facebook.  I'm not saying they aren't there, I just
haven't seen any.

> Similarly, if you wanted to run a Meetup-type site targetting free software
> oriented groups, you would host the site on your own, expose an XMPP service
> to it (or even run the whole site's backend via XMPP - better than RPC!),
> and tie it into Facebook via their API so people who post events or RVSP to
> them have that status showing up on their Facebook pages as well.  This
> doesn't force your entire member base to sign up for Facebook accounts in
> order to RVSP, just provides a way for Facebook users to help publicize the
> event to other Facebook users.

  Nice solution.  There does seem to be that side effect that most of
these social networking sites tend to take to take those sort of
things that are successful, embrace them, and squash them for their
own means.  Anyhoooooo..

  So, how is this facebook applet going to authenticate with an
external server?  After all, I may want to schedule some private
events I don't want everyone to see.

> Most of the libraries for Facebook API is free software.  There is no reason
> not to write and implement Facebook apps on the basis of software freedom
> ethics.  If you want to boycott Facebook based on them being a business that
> derives profit from advertising, that's your choice, but many of us find
> it's a useful tool.

  Facebook tie ins to other sites require an inferred level of trust
of facebook themselves.  But your right, I choose not to use it as a
tool, no use in arguing the merits of the company.

>>  Nothing in XMPP forces anyone or anything to actually share data
>> over the wire.  And many would suggest it's actually a bad idea to
>> open it all up to external, potentially untrustworthy, JIDs.  In the
>> world of federation, you have to trust the remote servers.  With wide
>> scale adoption of XMPP federated servers, you potentially run the same
>> risks as MySpace, but with no central lockdown point any longer.
> Server federation isn't unauthenticated.  There's a process requiring signed
> certs free, via xmpp.org, requiring verification of domain ownership only.

  Which only currently functions for free due to limited demand.
xmpp.org will not scale that high.  They have an extremely limited
amount of resources.  Additionally, they aren't really doing anything
at all.  http://www.startssl.com/ is.  It's technically part of
startssl.org and their 'web of trust' notary concept.  It remains to
be seen if it gained a much wider audience if it would remain free.
Your trust in the federation is now being placed on startssl.com.

>>  Think I'm wrong?  Example.  Suuuuuure, you can disallow any traffic
>> from anyone NOT on your contact list.  However, how do they get there?
>>  They request to be there.  Guess what's added to that?  A message!
>> Hrm..  Sounds like Spam 2.0 to me!  :-D
> Except given domain certs, unlike email spam, you cannot mask your source
> domain.  If some dude in China federated his own server and started spamming
> everyone, poof, there goes his federation status.

  And if Joe and Jane Users computers get compromised, and they start
bouncing off, say, gnhlug.org, then gnhlug.org can ALSO have a 'poof,
there goes his federation status'.

  There is also the slight issue with the fact that the existing
concept of a federation isn't.  There is no real way currently to
handle the revocation of the xmpp cert.  Go ahead and find the process
which will handle the actual complaint of a rouge server spamming, for
instance.

  The concept of the XMPP federation is vastly overblown.  It's just a
server with a cert.

> Moreso, your argument reads akin to "we shouldn't have a mailing list,
> because if it becomes popular, spammers will use it".  I'm of course not
> arguing that GNHLUG needs a mailing list, I'm only pointing out that SMTP
> exists and is used for doing so, vs building a one-shot forum site that
> don't use existing standards in their exchange of data.

  I'm really not an opponent of XMPP.  Perhaps you are
misunderstanding my arguement.  Here's an enumeration of how I look at
XMPP:

  1) XMPP is not the magic bullet.

    XMPP is a simple, easy to use mechanism to exchange snippets of
data.  Built into it is several concepts which have been rolled into
it, such as presence.  XMPP is, in reality, and XML snippet router.
The original design actually was broken up between etherx and
jabberwockey.  The sole job of etherx was interdomain XML snippet
routing.  Jabberwockey was the logical tags which encompased instant
messaging.  XMPP combined both together.

    However, it should be noted, it is simply an easy to use tool.
The same thing could be implemented using any number of existing
technologies.  XMPP is only easier due to its reuse of technologies
(namely, XML) which have been widely adopted, providing a wide variety
of tools which already understand how to utilize.  We'll ignore the
slight issue that XMPP XML can't really be parsed by a DOM parser.
That issue has come up SOO many times over the years, but the comment
made, I believe by Jeremie like 12 years ago, was..  'Who the Frack
cares?  Big deal, use a SAX parser'.

  2) XMPP server federation extends trust to untrustworthy sources

    Anyone can get certs.  And for $1.95 anyone can get a domain.  And
that's all that's required.  Additionally, there is no existing
infrastructure to deal with rogue servers.  There is the process,
currently, of complaining to xmpp.org (Aka, stpeter), and he may yank
the cert.  I suppose you could petition the XMPP council, however,
they have no actual control of the data itself.  The point is, there
is no method to police it currently.  And to put it into perspective,
most of the members of the board itself are (*TaDa!*) the software
guys who write the clients, like Psi.

  As an example, livejournal is the 'original' social networking site.
 It's still there.  And a long, long time ago, it added XMPP support.
What problems did it solve?  Nada.  Was it cool, and neat?  Yup.
Could it be used to integrate livejournal into MY site?  Yup.  Did
people WANT that?  Nope.

  The type of integeration where XMPP *does* provide power is for
portals. Portals are the places where you can see everything, and be
directed to where the data is.  And that IS where the power in the
language is.  Ironically enough, that is what many of the social
networking sites are attempting to be.  The all-in-wonder
buddy-portals.  But opening that power up to *any* site provides a
false sense of security to the end user.  And yes, that IS bad.

   If Joe and Jane user see, and potentially interact, with data at
'Portal Ubah', and they trust that site (they're using it, making the
assumption that they would).  Portal Ubah is presenting them with data
from unknown sources.  gnhlug could very well send information to
portal ubah with a headline of, "Windows Vista has a backdoor placed
by terrorist".  How trustworthy IS that data?  To Joe and Jane user,
pretty trustworthy.

    Now, what are Joe and Jane to do?  Well, they complain to ubah
portal, right?  Ok, so the portal blacklists gnhlug.  Perhaps they
request their certificate by revoked (I'm not so sure this has *EVER*
occured thus far).  Now, 'Linux Portal' knows nothing of this problem.
 Data begins to be segmented.  And we end up with the ugliness.

    What gets me *IS* the entire arguement of the XMPP federation.

    IT..  DOESN'T.. EXIST..

-- 
-- Thomas


More information about the gnhlug-discuss mailing list