Google Abandons Open Standards for Instant Messaging
eff.org
eff.org
"In public explanations of its dropping XMPP support, Google has said that it was a difficult decision necessitated by new technical demands. But even if this new protocol responds to different technical requirements, that shouldn't prevent the company from making it public and interoperable. Releasing the specifications for Google Hangouts would be a good first step. Releasing free/open source clients and servers should follow. It's clear that some of Hangouts' video features have been implemented in some very Google-specific ways. But that's no excuse for leading us toward a world where the only practical choices are proprietary chat clients and protocols."
I hope the specs at some point are opened. The Hangouts team probably has good reason at the moment to strictly focus on a core set of functionality and get it working with good UX on all the platforms. People are complaining that stuff like voice calling, and some Talk features are missing, but it's probably due to focus on shipping something that works good first. It's inevitable people will reverse engineer the client, as was done with MSN, Y! Messenger, and AOL. In the late 90s, early 2000s, I remember using reverse engineered Java libraries that could talk to these services.
Google Wave was done in the opposite way, as was Open Social. They came with specs, but they did not focus on core user experience in the beginning. It's hard to win with open specs without getting consumer traction.
They keep seeing very popular apps and messaging products that are completely proprietary and locked in, and that are able to move and innovate fast because they either don't have to conform to an existing standard, or worry about publishing and support whatever internal protocol they do use.
Sure Hangouts could publish their protocol like Wave did, but Wave was a complex mess of different protocol formats and transports and publishing that as a "standard" was way premature. Who knows how good the current Hangout protocols are, or how well they might play with real standards like WebRTC. It's probably too early for them
I remain optimistic that these things can be standardized in the future.
A lot of the features, like group video calling, first need their use cases polished by user trial, then hopefully, they can be implemented on top of either existing standards, provide inputs to change those standards to satisfy the requirements.
OpenID/OAuth is an instructive example. The specs were built very much driven by committee oriented thinking, and the resulting UX implementations out of the gate were much more complicated than the Facebook Connect experience. I think actually focusing on the "design" aspect of how users use it, and then extracting the relevant technical requirements into a spec works better.
Basically, Google is late. And the only thing that would make us switch to Google's alternatives would be an open protocol (not necessarily approved by a standards body, but at the very least with the specs published). That's because we don't trust Skype, but we would trust a protocol that has public specs. Even more than that, we would trust an open P2P protocol that wouldn't drop our connections to our list of contacts if your servers die.
And no, you won't win us by shoving that awful chat box down our throats, like in GMail or in Google+. You have to do more and be more than Skype currently is. Because you're late. And you won't win with consumers either, because consumers are already using Facebook's video chats, which is integrated with Skype. And you're late to the party all over the board, even though putting moustaches on people's faces is kind of cool.
Speaking of Skype and open P2P protocols, since Skype was acquired by Microsoft, want to bet that they'll up-yours on this one?
Free group video chat and Hangouts on Air (free YouTube exporting, basically) are enough for me to seriously consider Hangouts over Skype for most interactions.
Video seems like it could be out of band using WebRTC and initiated by new XMPP data.
Watching the Wave introduction presentation from Google I/O 2009 it's hard to buy that a new protocol was needed.
It is perfectly reasonable to publish the specs of what your doing with no commitment of support, simply for folks to see and possibly use at their own risk.
That said, the reason companies don't do this is often one or two reasons. Reason one is that it results in a 'noisy' side channel as people who read the specs share their opinions, but they also get bent out of shape if something they said, or think they said, appears in the spec later. The other issue is that there is always a sanitization/prep process to take essentially internal information about a service and create an external representation for consumption (even if that consumption is unsupported).
So the 'easy' choice is to not publish.
One of the biggest is that they're just not ready for 3rd party clients in any fashion. The protcol may be _very_ rapidly changing. The auth workflow might be tied to some other system. And, regardless of messaging to use at your own risk, if you publish people will get mad when you break them. Finally, it's just a lot of work to go through if it's truly unsupported.
Once you've published it, you're under pressure to remain backwards compatible. But until you've got experience with it working in the real world, you don't know what really works. And then before publishing it, you need to go through a lot of work to make the published spec clear enough that someone else can reimplement from scratch and it will actually work.
For all of those reasons, there is pressure to not publish a spec until after the technology has matured.
I wrote most of the first version of the wave federation spec (I cannot remember how this happened, but im pretty sure it involved being in Sydney temporarily, alcohol, and Soren being Soren. I'm fairly sure I got the short end of the stick on this one).
It was absolute and complete crap. But it kinda worked. We were clear it was a first draft, and folks understood it would completely and utterly change.
Within an hour of publishing it, the wonderful XMPP folks emailed me and asked me to fix a few things (like accidentally using some reserved namespaces/etc), and asked how they could help, pointing out the XEP process, and pointing out we were doing some things others were working as well.
With their help, it ended up as a "mostly sane" spec.
Realistically, pressure comes from improper messaging. If you tell people "here's our current thoughts, in spec form, this is all gonna change", you can do a lot of work in the open without too much customer pressure.
Now, will this slow adoption? Maybe, it depends on what kind of product it is.
But the argument that you get this pressure out of thin air is wrong. Pressure is mostly caused by self-inflicted wounds where people are not being clear about the state of the world as they see it.
The reason that I'm cautious is that I've suffered through code that has to jump through hoops to remain compatible with something someone thought was a good idea 10 years ago. Things that seem like a good idea now don't always a few years later. When you control both ends, you have a potential upgrade path to fix it. When you don't, you're stuck.
I'm, of course, not suggesting that you should never try to design something that will last 5-10 years, but in most cases, you can only standardize what people want to use now, and hopefully design a way of extending the protocol to be able to standardize what people want to do in the future as well.
As you say, otherwise you have to try to remain compatible with something someone thought was a good idea 10 years ago. That usually means it wasn't a good idea 10 years ago, it was something that 10 years ago, they thought would be good in the future, and they predicted wrong.
Past that, sometimes you have to just accept that the useful design life span of some protocols is not going to be as long as some customers would like.
As a reminder, here's how to send a tiny update to a wave:
<message type="normal" from="wave.initech-corp.com" id="1-1" to="wave.acmewave.com">
<request xmlns="urn:xmpp:receipts"/>
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items>
<item>
<wavelet-update xmlns="http://waveprotocol.org/protocol/0.2/waveserver" wavelet-name="acmewave.com/initech-corp.com!a/b">
<applied-delta><![CDATA[CiIKIAoFCNIJEgASF2ZvenppZUBpbml0ZWNoLWNvcnAuY29tEgUI0gkSABgCINKF2MwE] ]></applied-delta>
</wavelet-update>
</item>
</items>
</event>
</message>
A completely good faith (and perhaps naive) read on the situation is that they need to settle the protocol to the point where they can commit to some level of good faith long term support and giving proper notice of breaking changes, then they'll release it.
A single vendor working in a vacuum is how we end up with horrible kludges like the Public Suffix List. http://publicsuffix.org/
A lot of the failed IETF standards are ones where the IETF was constrained to trying to fix an already-deployed protocol after the fact.
But the only feature that matters in a messaging app is knowing the person you want to contact also uses the app. In this case by choosing to "innovate fast" they are guaranteeing failure.
Reminds of a project posted to HN a while back that had taken someone a month. I replicated it in the evening using all open source, open protocol components instead of being stubborn and falling prey to NIH syndrome.
As a bystander, this comes across as "we aren't smart enough to figure it out", or "we are smart enough, but this is a business decision with ulterior ("evil") motives". Neither of those look positive for Google.
I don't expect multi-person video conferences to work, but plain old textual messages, as already work today, shouldn't be a problem.
The issue isn't even about making hangouts open, but rather about chat messages in hangouts also being able to relay with federated XMPP servers - something GTalk does today just fine and has done so for many years.
| It's inevitable people will reverse
| engineer the client, as was done with MSN,
| Y! Messenger, and AOL
1) Chat windows give me no indication of the presence of the other participant(s) in a conversation. If they sign off, I have no idea they've signed off. They frequently get messages from the tail end of a conversation much later, which is confusing for them.
2) The contact list is in alphabetical order, regardless of their presence. Talk used to separate online contacts from offline ones. This was nice because I have a lot of contacts in my gmail account, and only a dozen or so ever sign in to chat. There's no obvious way to change the sort in Hangouts.
3) The UI is higher latency. If I touch a notification in my tray, I often have to wait upwards of two seconds for the Hangouts app to load. The various screens within the app also take longer to load.
4) I used to have a custom notification set when I received a message. Hangouts replaced it with its own and there's no obvious way to change it back.
I hadn't noticed Hangouts had abandoned XMPP. I find this rather unfortunate. Adium on my Mac still connects fine, but for how long?
I hope you're right, but to my knowledge, this has never been done with Skype, and to this day you can only call a Skype-using friend/colleague if you use the official, closed-source Skype client. So let's not be sanguine.
It was done, but Skype has a rule about this which they apply quickly: Press the cease and desist button.
I've been using IM clients with support for skype, only to see it get dropped. Which makes it doubleplus sad that MSN (which was fairly interoptable) got ditched for Skype and not the other way around.
The only "supported" way for third party IM clients to access Skype's network without risk of lawsuits is piggybacking on its COM API and have the user download and log into the official client, and have that handle all the actual communication.
You probably think "He's gotta be kidding", but sadly I'm not.
TLDR: Skype does not only not care for or provide an open-source implementation, but they are actively fighting it.
In particular, the right test of openness is this: can I build an interoperable client that could participate in a Hangout as a first-class entity?
That way lies madness.
i can now, at least, think positively: 'well, at least it's not XML encapsulated in base64-encoded protobufs shipped over XML.'
The Earth may not be big enough for that to work out. This is before you remove people who aren't in this industry, people who are too young or too old to work there, people who don't want to work there, people who DID work there and left, and so on.
It might explain a lot, particularly when they go on a hiring bender. Where are all of these new people coming from?
I've never heard this. Do you have anything that backs you up? I found a Quora answer that says that the Hangouts API is based on the the Wave API, but that's it.
The spec were largely written by an an intern and a person not part of the wave team helping wave with other things.
Everyone else was focused on Wave.
It seems they'll use open standards only as long as it serves them, but when they've grown big enough to dominate the competition, they'll turn around in a heartbeat and exploit that.
Just look at what they did to the open web with Chrome.
First they said "Web standards are important, so here is a good, fast and web-standards compliant browser. Feel free to try it". After a while that was not enough, and on every single web-page they had they had a big "Use Chrome!" ad for every visitor not using it already.
Once they had gained enough dominance, suddenly Google started using non-W3C HTML in their production web-sites. HTML which had not been fully drafted or ratified and which was only available as they saw fit in web-kit.
And then all the other non-Google browsers were suddenly "slow" on "adopting new HTML standards". Basically through its internet dominance, and now its browser, Google pushed through its own implementation of proprietary HTML features as standards other browsers had to implement, without any discussion, feedback or other input.
Google just decided that they alone should dictate how the HTML-standard is from now on.
After seeing that happen, I lost all belief in Google as a company which I will rely on for anything more than I strictly need to.
I don't see how Google is dominating the competition. Gchat used to be a dominant player, I believe, but that was before mobile existed. I think the dominant players now are:
iMessage. Propriety, only runs on Apple devices, can only communicate with other iMessage users.
Facebook Messenger. Proprietary, only runs in Facebook site and app, can only communicate with other Facebook users.
WhatsApp. I think based on XMPP? Only runs in WhatsApp application, can only communicate with other WhatsApp users.
Notice that every single one of those is a walled garden.
http://www.theverge.com/2013/4/5/4186302/google-chrome-blink...
To be fair, how did XMPP serve them? They weren't really benefitting from it, they did it mostly for the good of the community.
Indeed. If basic XMPP wasn't good enough for whatever reason, (or SIP or whatever other protocol already exists) then the "right thing to do" would have been to work with the respective standards body to extent / modify an existing standard to overcome whatever the restriction was. OR, as a secondary option, Google should at least release detailed specs for their new protocol, along with an open source reference implementation.
Creating more new walled-gardens is not a positive step forward here.
Imagine that you have a small team trying to hit 3 platforms (Web, Android, iOS), in time for Google I/O launch, packaging up an OSS release along with spec document is probably the least priority.
The move is definitely deliberate, they can't have Skype come in and allow people with Skype to make calls to hangout when the hangout client can't make calls into Skype. It would make them look bad.
I don't really see that Google would have anything to gain by blocking interoperability with Skype, Skype is the market leader, it is usually those who are not market leaders in a particular area to push for interop, and usually those who have a hold on the market to resist.
Often if someone is doing something that cries for an interop spec, but they aren't doing it, chances are they have some good reasons that don't involve a corporate master plan to "talk about openness to make people like us, but secretly silo-the-world" Often, it revolves around having a task list of a gazillion things to work on and prioritize, and often open-spec is 'nice to have, but not critical for launch' kind of thing.
Really, when you look at the market, 99% of the folks are shipping closed apps, where more time is spent on cute emoticons than on infrastructure. Google risks becoming "open, but irrelevent" in a market of iMessage/WhatsApp/FaceBook messenger, where a niche audience is supremely happy they can build third party clients, but which becomes a service unused by the great unwashed masses.
The network effect requires other users to increase value, so they've got to double down on things which delight and wow end users first, and developers second.
I look at Search and Ads and Datacenter secrecy being closed as necessary evils to fund everything else, you've got to have a rich uncle who will let you work in his basement if you want to work on open software. Search in particular, represents a challenge, since even if Google were to just ship the source to it's search engine, it would likely devalue the search engine by showing blackhat SEOs exactly how to spam.
Like I said, the natural proclivity of many Googlers is to lobby for open specs and source, to bitch and moan about it internally. Sometimes they win, sometimes they don't. Many googlers don't like secrecy. Google will still have a competitive advantage over most other companies because of the datacenters, so the source availability is often not a threat IMHO. I could give you the source to Gmail, chances are, you won't be able to run it competitively without investing a billion dollars in infrastructure.
That said, Google has published papers on it's crown jewels, like Spanner, Borg, GFS, Map/Reduce/ et al, stuff which makes its services scale very well.
Disallowing third-party clients can even be spun into a move towards openness: since the ultimate goal is to have everything on the open web, the main interface should be the one on Google's website; native clients are a necessary less-open evil on current mobile platforms, not something third parties should waste time on.
It seems that there are any of a number of non-open parts to the Google culture. How many server machines do you all have? How are dirty SEO methods detected and thwarted? What are the details on the influence made by the $18M spent in lobbying D.C. in 2012?
That's not to say they shouldn't be private. It's me asking you what it means to be "open" as part of the culture.
As I wrote, I agree with the view that parts of Google are not disclosed publicly.
My question is, we all know that Google has some closely held secrets. In that case, how do I tell if (public) openness is part of the culture? Can I use that to estimation method if the level of openness has increased or decreased at Google over the last decade?
Sure, anyone else can also implement group video chat relatively easily thanks to WebRTC, but why would people use the new services? All of the people they'd want to call are on Hangouts, not that new service - and thanks to Google killing federation, you can't call Hangouts users from other services.
But just throwing a new protocol over the wall and creating more walled gardens is not cool.
Well, what financial incentive does Google have for creating a completely open and free communication standard?
I still think it's the Right Thing To Do though. I know the old saw about "don't be evil" is probably over quoted and that it's just a tagline and not a binding legal agreement, but for a company like Google, given their history and reputation, this feels wrong.
Now that google are an established giant, there probably isn't much financial incentive for them.
You're right that it's the right thing to do though - it leads to more competition, better services for consumers and faster innovation, enriching humanity.
In the past, google knew that having a healthy web platform was more important to their long term profits than huge numbers of tightly tied in users. That no longer seems to be the way they see things.
If their goal is having users on the network, creating more viable options for getting onto the network can't be a bad thing.
It is hard to say whether Google as an organization is something you can characterize as "nice" or "mean" but the actions taken here have clear implications. They are deleting the open protocol and replacing it with a proprietary one. Whether their heart is in the right place or they just have some rotten circumstances to deal with doesn't matter really. Perhaps Microsoft with Skype might say that they are closed on purpose but Google will say they are closed by accident because, well, you know, of all the things they can do, this is the one that is too hard. But it doesn't matter. It is the exact same effect.
So what. More effort that's required to do things properly. Create a protocol, publish it, start deploying (especially if it breaks what's working now). Doing things the other way around creates a horrible mess.
Being open only helps in that users see it as a feature. Right now, not enough users see it as a feature to make being open as a priority for this product. And those who do prioritize openness are already starting to move away from google because it's gotten too big.
So google gains what, again?
They gain advancing interoperable and connected IM network. If they are OK with creating another walled IM mess for selfish interests (as if we don't have enough of these Skypes, Whatsapps and etc.) then let them be boycotted.
Generally, the way you work with a standards body to extend or modify an existing standard is the same way you work with a standards body to create a new standard, and that is: 1. Build a prototype product, 2. Get some use on it so you can find and knock off the rough edges, 3. Once your comfortable that you've knocked off enough of the rough edges, submit the new or revised protocol to the appropriate.
I've immediately stopped using as many Google products as I can in response to this after trying out the new hangouts a few days ago and finding I couldn't connect with my friends that weren't on Google.
I'm sad - this directly removes choice and is a sort of lockin. I now can't use Google to communicate with people who choose not to participate in Google's ecosystem for whatever reason.
By leaving, I also make it harder to communicate with many friends who are on Google.
Google, you've alienated me.
I think Google+ could be understood better once you realize that Google+ is not a social network in the traditional terms. Google+ is truly a social layer across all Google services.
The average users who are just looking for a chicken recipe (as you mention) would always love to find the particular chicken recipe that their friends have recommended. Even more relevant to me (since I don't cook) is that if a friend finds a todo app useful, I'd definitely want to know.
If Google has this social layer, it'll really unleash more expressive search results that would help the vast majority of users. This is what Google+ is.
Google+ is literally Google Plus More.
Of course, to get these benefits you really have to start using Google+ on different Google services. I guess this is the reason that Google employees who actually use Google+ services continue using it and prefer if their friends do it too.
We just want to search. Or keep using email like we have been for a decade. People switched to Gmail because it was like hotmail with a nicer interface and a large mailbox limit.
Maybe some people do want those other things. That's fine, give them their own corner, let them play with the toy social network or social layer or however you want to pitch it. Stop force-feeding it to the rest of us. I don't want to know what my friends are searching for or what recipes they like. It's just unwanted noise.
And let's call a spade a spade - "sharing" has very little to do with friends and everything to do with advertisers. It's very disingenuous and insulting of Google to pretend that the primary purpose of +1 buttons is to "share with friends".
This is calling a spade a turkey. How did you possibly come to that conclusion?
> I don't want to know what my friends are searching for or what recipes they like. It's just unwanted noise.
On the right-hand side of your search page, there's a button for turning off personalisation.
For now. Maybe not tomorrow. Google has already demonstrated its willing to run roughshod over some of its users in order to advance its agenda for Google+, which clearly is much more in Google's interest than the interest of Google's users.
The information I store with Google is actually quite a bit more valuable than anything I might post on Facebook so their recent willingness to stuff all their other services into a shitty social network with a creepy "real name" policy has me eying alternatives.
Even a few years ago I had no second thoughts about depending on Google for critical web services but their tactics with G+ have me seriously second guessing them.
I don't mind a functionality that I can disable, the real issue is all the stuff I need to go through to have that functionality that turns out... I don't need or want!
So Hangouts will provide some advantages over XMPP, at a cost. It doesn't matter I don't really need/want the improvement if I can't keep using the stuff that was already useful to me.
If I see 50 restaurants nearby, but ten of them have been +1'd by people I know and trust, that's great and helps me. And I'm happy to recommend my favourite places, books, games too. I think it's an important problem that Google (and others) are solving and it actually reduces the need for advertising.
What I really hate though is facebook selling their 'likes' to appear in your feed again and again, long after you liked it. It's a lie, because it gives the impression that you're liking it again, right now, which might not be true. For example let's say you liked tiger woods, that might be news feed worthy at the time. And if someone searched for tiger woods then yes show the like as part of that information, but to put it up again at a later date, say immediately after he's caught being dishonest is misleading people and sending the wrong message. The fact that they're being paid just makes it worse. What's more they don't even show you what likes they're putting on on your behalf in your own news feed which would give you the option to unlike <x> if necessary.
In short not everyone hates G+
Good and fair points. The big issue here is the fact that all of what you said is tied to a persons real life identity. I think people should have the option to choose whether they want to surf the web using a pseudonym, or doing it with their real name. Google forces people to use their real name in order to be able to squeeze out more profits per user.
Socially slanted search is the future, and I agree with that. But not in the way that Google is doing it. Not everything has to be social.
Google+ does support nicknames and pseudonyms now, but yes there is a preference for users to use their real names. Also personally, I don't really think real anonymity truly exists on the web anymore and in such a scenario I trust the bigger companies more than the thousands of tracking companies but I'll write that rant sometime else.
Coming back to real names in Google+, I'm not entirely sure why Google+ prefers it, but I think it ties in with generating better social signals. Facebook really showed the way here. If people use their real names it's easier to find real friends. I also would care about signals/content created by friends with real names.
I'd care more what a particular friend I know has recommended more that what rockstar_spongebob has. Also if I'm rockstar_spongebob on a website, I'd lose the incentive to connect with only people who are my "real" friends and I'll end up adding lots of people at random. I think this is what happened on Digg and these "friendships" had no true affinity (atleast on Digg). I truly would never have cared about restaurants recommended by my Digg friends. Of course these reasons are just my guesses and I really have no research/data to back it up.
I think it would be fair to say that you're trying to compete with google. Yahoo! is a Google competitor, Microsoft is, Apple too. The rest of us, we're just trying. As long as we're not on their radar we've failed to establish any mode of competition that matters. Even DuckDuckGo (for now) does not qualify.
This is what we hear all the time from google executives, when explaining what google+ is. As a user, I dont see any difference between google+ vs facebook. In terms enabling social interaction, google+ is same as facebook. posting picutres, videos, chatting with friends, liking stuff on internet, games, etc. Also dont see why they try to spin this in any other way. Google+ goes a step further by integrating into search,Ads etc.
We have different concerns for how our data is used with respect to different accounts. I certainly don't want my name associated with any public-facing element of my accounts. My name's for close personal friends only - you can do a lot of damage to someone if you know their name and even more if you have a picture of them. The more stuff you stick together into one account, the more control the person loses and the greater your risk across all the elements of the service becomes in all respects - privacy, security and even in terms of google screwing you over for something.
In some ways this manifests as people just not using certain elements of the service - I have to have a google+ account to review apps now. So, I don't review apps anymore. I have to have a google+ account to correct tags on maps. So, I don't correct tags on maps anymore.
In others ways people don't always get the option to opt out though, or don't understand it, the choice having been purposefully obfuscated - and there it's a fairly straightforward attack on their privacy. People are not the same person across all the elements of the service - and for good reason.
It's just a really really aggressive, nasty solution to a problem that no-one seemed to be making much of in the first place. Let's integrate everything, let's force everyone to have an account they don't want on our social network, let's force everyone's names out into the open. Bleh.
And if you ever want to read reviews of an app written by your friends instead of complete strangers, and want your friends to read your reviews, which is a feature many people like, how do you suggest that Google should implement that feature? Having one friend list for every single Google product like before?
Well, there are two strings to that. Decency and effect. For me the first one is the main one.
===============
Decency:
My attitude towards relationships is based on standards of, among others, fairness and decency. There are some things that reliably nice people just don't do except in direst need - and even then they pay a price for doing it, (good people don't kill in line utilitarian ideals and then shrug about it and go home whistling a merry tune for example. Doing bad things should make you feel bad if you desire to see yourself as good.) So, to a large extent, the cost is in how the thing is done. Google could be forcing me into something that I was really going to enjoy and I'd still resent them for it. I hate the feeling of being bullied, of having control taken away from me, and now I'm an adult I don't have to put up with it. The cost to me, a very large part of it, is that I'm encouraging bullying behaviour in society - and that's not something that makes sense if you're against bullying, and it feels bad to violate your standards in the same way that lying to someone you really love feels bad.
I think that's a fairly general feeling in our society; being forced into something/acting against our values being bad that is; and I think it's one that makes a lot of sense when you're playing iterative games. We don't like to be told that there's something for us to do, but we like to be asked if we can lend a hand. We don't like to be obligated but we like to help. We feel bad when we lose our tempers and yell at our kids. We feel good when we make people smile and laugh. Most people want to live in a world where fairness is important, where others respect their reasonable boundaries and where when things change they change to benefit both parties who freely consent to the change. We like to believe lots of things about ourselves, and about each other, and unless we behave as if those things matter to us - why ought they to matter to anyone else?
Consequently, if you treat people like crap, violate accepted standards of socialising, then there's a social cost that you have to pay whenever interacting with anyone who operates with strong standards of behaviour; your presence becomes in a sense disgusting to them.
That's the decency side of things. Maybe that doesn't mean as much to you as it does to me, but it means a lot to me. Your worth in the world, to me, comes down to what sort of person you are inside - what sort of likely ways of thinking give rise to your actions.
===============
Effect:
'I certainly don't want my name associated with any public-facing element of my accounts. My name's for close personal friends only - you can do a lot of damage to someone if you know their name and even more if you have a picture of them. The more stuff you stick together into one account, the more control the person loses and the greater your risk across all the elements of the service becomes in all respects - privacy, security and even in terms of google screwing you over for something.'
Now you could say, and quite reasonably, google has so much information about you, what do you care if they have your name too? Does it really make any difference if they know that computer #1,4357,56 is actually Cassandra? I think it does. I think they're going to publish that that's your name and I think it's going to tie into a lot of your other online activities. It will make you searchable, and vulnerable - even without malice on the part of the other party, in a way that you weren't previously. It will translate real world relationships to a digital realm, and vice versa.
You don't even have to make much use of the account for it to contain information about you. Others in your peer group will find you, and they'll start tagging you in photos and suddenly there are pictures of you on the internet alongside your name and location and the people you associate with. Social accounts represent a point of vulnerability. If you don't manage them, then others will do so for you - and rarely to your benefit. I mean honestly, when's the last time someone actually asked you before they tagged you in a photo?
What are you going to do? Not friend them? Now who looks like the anti-social arsehole... The whole situation is of course avoided by default if you don't have an account.
Even if we put that to one side for a moment there are other problems though.
Even just in terms of account security: What happens if someone makes a complaint against your youtube account if you're linked into all the services as one? People have gone after my account before just because they didn't like a girl doing tech tutorials. You get these sorts of really creepy cave-dwellers who are just out to attack everything vaguely creative and decent in the world and suddenly you've overlaid the part of your risk profile that's vulnerable to them with every aspect of your digital life.
Now my name would be tied to every review I made - what happens if someone takes exception to it? People have been threatened with legal action over reviews that companies don't like before. Now my business 'friends' can search out what I do and review, what happens if I say something they don't like? Am I going to give an honest review of something ever again if someone can see that I thought their product needed more work? No, that's the sort of thing that can come back and bite you in the arse.
What if some random arsehole just decides to see how far they can screw people over? Before, without a name, it wasn't much trouble. Now, I wouldn't be so sure. You can do a lot of damage to someone with their name and a few other details. Especially so outside of Europe where the data-protection laws are either less powerful or just flat-out non-existent. It's noticable easier, for instance, when someone's doing research to find someone specific in the US than it is in the UK....
If it were just a name floating around, unattached to any actions that the person took and impossible for people looking for them to tie back to their real identity, then that would be one thing. Any attack could come up with a whole list of people's names just by randomly hashing common names together - what would really be the point? But it's going to be tied to meaning - that's why Google want it in the first place, after all.
I really don't want random people on the internet to have my name, or for random people in real life to follow me back home and onto my computer via the internet. I like my life to have huge brick walls between its different aspects. My work is my work, my friends are my friends, the internet is the internet. For them to have that sort of integrated weapon to use against me is not desirable. Especially when I'm not going to know, if one of them turns around and screws me, who they are - there's a power asymetry for the first person to act on the internet that combined with anonymity is truly scary.
===============
But maybe all that sounds paranoid to you. I don't know, maybe you don't mind people who you don't know on the internet having your real name - after all, it's not like they can look you up on government registers once they've got your name. Maybe... maybe none of them on their own seem very likely or very significant if you were to assume that they happened to you.
But look at the number of them. And what have we got on the other side of the scale? Correcting map mistakes and reviewing apps is something that I do that adds value to Google's service. It's a favour if you will, I just happen to like helping people. But if they really want to make it difficult, if they think they've got something that can use against me and they're prepared to use it, then ... why should I pay these sorts of risks and social costs?
> And if you ever want to read reviews of an app written by your friends instead of complete strangers, and want your friends to read your reviews, which is a feature many people like, how do you suggest that Google should implement that feature?
Just make it a function of integrating your friends lists. There's no reason you can't have one friends list referenced from multiple places and or read differently by different accounts - or several friends lists with different access settings. Heck you could even have one account that has different access settings that restricts cross-contamination between private spheres and public spheres. It would look more or less the same from the outside bar that the infrastructure to control your disclosure and to limit your risks would be there from the ground up. It's not particularly complicated to integrate or synchronise the parts of your service that customers want integrated and still maintain functional seperation.
But, in any case, my complaint isn't that people have the option of integrating their accounts. Demanding that they not have that option would make me no less of a bully than Google. If you want to, while I might advise against it (Google can't change their mind about disclosing what they don't have), that's really your business. My complaint is that pressure is applied to try to make people do it.
It sounds like you really just need to diversify the providers of the services you use.
I actually know the owner of a business that is using Blogger and Google Apps and at some point freaking YouTube asked for her date of birth, she then selected the wrong year and Google cut her access to GMail, not to mention that it took their blog offline. She then called me desperatly to do something about it. Fortunately they allow validation of birth date by credit card now, but I remember some point not so long ago, where this wasn't the case.
So yeah, who wouldn't want that?
Really? Then they are pretty bad at it. At least short term. They don't seem to be monetising any of their recent projects.
You missed one. I smell a fanboy
Nowadays I only trust services where they profit (aka. anything that includes advertising), and none of the open standards they push forward.
Google Apps doesn't seem especially relevant, but it also has lots of competitors (including, just like chat, very active open source projects), hasn't been left to rot, and they've actually moved to only charging for it, instead of having an ad-supported version.
...so, are you really just talking about Reader?
That's not how I see it at all.
You make it look like they are improving the service and that requires breaking compatibility with XMPP, but it's yet another strategy to force users into Google+ by consolidating Google Talk under the "Hangouts" feature. Commitment to open standards is only skin deep.
Letting a service rot generally means abandonment. I'm certainly not saying that the opposite of letting something rot means improvement, I'm saying that making a major change like this is not at all an example of letting that service rot.
Google hasn't killed competitors. Google chat is losing ground to iMessage, Facebook Messenger, and WhatsApp, all of which are proprietary walled gardens. If XMPP federation was an important feature for end users, why would those products, which are all newer than Google's chat, have been able to supplant it?
Sure, I'm sad that Google is turning off federation too, but I'm happy that it will let the team move faster to make a product that adds value to people's lives.
Standardization is a good thing, but not the only good thing, and it always worries me when people make arguments that effectively demand that new offerings justify themselves (either with time or money) to existing standards groups.
At this point, standardization for video chat is one of the most important steps forward. We already have proprietary video chat services. We already have the likes of Yahoo, Skype and Facebook.
Why do we need another proprietary protocol to throw in the mix? What could possibly be more important than an open standard at this point? And yeah, Hangouts has some cool stuff in it, but not enough to justify the breaking of a promise, but then again, it's not the first time where I feel like Google is disappointing.
IMO, any "progress" in the form of a proprietary service which erects boundaries for communication is not progress at all.
Or at least commit to doing it in the future at some point. Nobody's rushing them into doing it right now, but changes such as these create anxiety. I mean, what next? Are they going to drop POP3/SMTP support from GMail or something?
I can't imagine a standards issue I would care less about (among standards I routinely use) than Google Mail dropping POP3 support, unlikely as that may be. Most mail users are better served by web interfaces. POP3 and IMAP are archaic. People that want those interfaces have plenty of options for maintaining them.
You have never had more freedom in how you can avail yourself of technology than you do in 2013, no matter how many restrictive app stores and giant email providers you choose to concern yourself with. (I don't mean that to sound snide.)
As an alternative, of course, we can do better than POP3 or IMAP. Sure, lets burn them, but name an alternative first and it has to be a standard supported by Google, no?
I can't believe that you think this. You're basically arguing for the sake of arguing.
Btw, you're mentioning "web interfaces". How would you have liked it if everybody had their own browser-like app, communicating through their own http-like protocol, speaking their own language for hyper-linked documents?
As an XMPP Council member I can say that general consensus within the XMPP Standards Foundation is that we will just move forward, no longer constrained by things, like network security, Google never got around to implement.
People sometimes lose sight of the real goal, which is interoperability. Interoperability is harmed not just by deliberately idiosyncratic implementations of old ideas, but by refusal to adapt to new ones.
Well said. Google made a bad move with breaking things before enabling interoperability by publishing their protocol. It's not the proper way of doing things. Firstly, they could extend XMPP, Jingle etc. instead of creating something from scratch.
If they can't (though they didn't explain why), they need first to develop a protocol, publish it, and then start deploying it. Not other way around! Right now they are moving towards cutting the connection between Google users and users of other XMPP servers. Connection which works already now. I can understand that they might envision new communication patterns, but it doesn't mean one has to break what already works before enabling others to interoperate. It's completely immature on Google's part. Going the right way might take more time - but it will not increase the horrible mess that the IM scene is today. What Google does now is creating only more mess.
Google is getting clobbered in the messaging space by these apps. If Google thinks they can move faster by dropping XMPP support, I'm fine with it.
Imagine if Google sticks with XMPP and continue to lose market share in messaging. They might have to shut down Talk. We know what happens when Google sunsets a product, lots of angry people.
Lose-lose situation for Google here.
That's not to say I wouldn't like to see them improve their support for all of XMPP though.
Really, I can only think of laziness and trying to build a walled garden as reasons to support c2s but not s2s connections.
Both of which are not exactly good explanations for one of the largest companies in software engineering.
Perhaps I may still buy their hardware, but they want to isolate my data from every company but them. They are no longer reliable.
> To be clear, even the earlier [off-the-record] setting was far from perfect from a privacy perspective: disabling chat history only kept the logged messages out of your Gmail account, and didn't prevent other users, or Google itself, from keeping a record of the conversation.
How on earth would you expect an open protocol to prevent the other keeping a record of a conversation? It's like asking for perfect DRM with open clients.
[0] In theory with infinite resources and time. Maybe.
[1] Or any other sort of encryption.
Beyond that, we see a "don't be evil" comment every time a Google-related post comes along.
[1] http://blog.vidyo.com/technology/the-new-google-hangouts/
Sales of animated gif skyrocket, solving financial crisis.
XMPP has sort of been designed with extensibility and innovation in mind.
Doing it browser-based also seems problematic, for all the usual javascript/encryption reasons. I've never heard of people using it in regular Gtalk, though. How does that work? Browser extension?
I've only ever seen things like using Pidgin with OTR, which should still work as long as you have a Google account (aka you don't need XMPP federation to talk to people on google's network).
http://beforeitsnews.com/libertarian/2013/01/how-to-do-encry...
Edit: Actually, I don't know that "turn history off" does the same thing as that option, they just seem the same.
Why do you think the ads you see in a search just happen to contain items you were just emailing your mother about a day prior?
It really bugs me to see people claiming "Google is in bed with the US government," but fail to acknowledge the transparency report:
http://www.google.com/transparencyreport/userdatarequests/
Or how about when Google gave a range of NSLs they received? Does Microsoft do this?
All individuals who seek to silence others with a take-it-or-leave-it are people who do not want to suffer the mental dissonance of being frustrated with a provider they themselves use.
With WebRTC, a proper signaling protocol (they're probably using Jingle anyway, give the RTC history and the fact that RTC relies and builds on Jingle), and a relay server, there's not much to need to do to interoperate if they wanted to enable it.
This whole notion that they "can't" make it interoperable or that it will "slow them down", is complete and utter shit. Slow them down on what? All I've seen so far is more merging of GoogleTalk+GooglePlus and a rebranding effort. Basically no new feature, no integration with Google Voice, no seamless integration with SMS.
Better if they are decentralized. You wouldn't have to move everything at once. But this will also increase costs.