Everybody knows that SMTP is old, inefficient (hey, it’s nearly plain-text!), insecure, diversified (so many different servers to choose from!) and generally just bad.
Clearly a closed web interface that only runs in Chrome would be much better for everyone! Then people could always be sure with whom they communicate, nobody could hack or social-engineer their way into other accounts, and everyone would have to follow The Rules or they’ll have their account closed for good.
Arrgh. Title is total link bait. There is no news about SMTP here. The linked blog post is whining about XMPP, which is not being disabled. Apparently the author is a user of "XMPP Federation" (the ability to link XMPP servers together a-la IRC), which is also not being disabled. But apparently it might be someday, as the new Hangouts stuff won't support it.
So how did we get form "can't talk to your Hangout via an XMPP client" to "Google will disable SMTP"? Really folks, this site used to be better about this stuff...
1. Looking at the other threads I can't quite get a straight answer on XMPP, but it seems to be entirely disabled for the "new communications product called Hangouts" (new??), but this is not just about federation.
2. claudius is very clearly explaining why google SHOULD disable SMTP. Nobody has seriously suggested they would; you might need to recalibrate your satire detector. Also claudius gave several reasons that apply equally to XMPP and SMTP to be extra helpful. :)
Given that Google was, essentially, the only meaningful provider of either a public federated XMPP service or a RSS feed reader[1], that seems like a pretty weak argument. If there's no community, was it ever really open?
[1] Calling Google's 100% proprietary (albeit publicly documented) reader protocol an "open standard" is a bit of a stretch, FWIW. Google certainly isn't refusing to support RSS on its blog offerings.
Google Reader killed the RSS reader market by offering a solid product for free. You can't use the lack of other options as proof of anything except the depth of Google's pockets.
I'm not the original poster, so I can't say what he might mean by that.
But in my view, Reader's arc is a sign of their growing indifference to open standards and a love of walled gardens. Well, their walled garden.
My impression is that Reader was launched back in the days when they were just doing things for the fun of it. If a 20% time project does well, then you push it out. And then they cared about open standards, which is why you can OPML-export your reader subscriptions.
But even at the time they didn't think much about crushing the nascent RSS-reader market. The programmers wanted to build things, so they did. And they liked them to be open, so that's how they ended up.
In the last few years, though, they've shifted. Google Plus was a sign that the power shifted from the nerds to the suits. The suits see what Facebook has and want the same. In that period, they just neglected Reader to death. I doubt it was intentional, but they it suited their walled garden urges just fine.
Now they've killed it, because it doesn't even do that anymore. As many people have noted, RSS has lost a lot of ground to proprietary sharing. Will it make it back? Would it have lost it anyhow? Hard to say. But a big part of why it's hard to say is Google's dominance.
So trying to answer your last question as framed, I guess I'd say that the harm to open standards happened at launch and up until when they killed it. The announcement kicked off a bunch of innovation and interest in newsreaders, and I'm looking forward to seeing how that plays out.
There are lots of RSS desktop clients. It's unfortunate that web apps are appearing more vulnerable to Google's monopolistic practices than desktop apps were to Microsoft's.
Gmail sucks too now (to give an example) but it's much harder to provide a viable alternative if you're an open source project or a startup. There will never be a Firefox of web mail, much less a Firefox of search engines.
Well TBH I hate SMTP and would love to see it replaced.... however, the features I want (native user-to-user encryption preventing Google from reading my mail) Google would not want to add, and unless Google makes it an open standard it's a waste of time.
> So how did we get form "can't talk to your Hangout via an XMPP client" to "Google will disable SMTP"? Really folks, this site used to be better about this stuff...
SMTP is worse than plain text. It's plain text and base64 (which increases file sizes by ~30%). It's a horrid protocol, but sadly it's what we're currently stuck with.
But this is all moot as the article is about XMPP, WebDav and RSS. The SMTP headline is nothing more than clickbait.
People keep banging on about "plain text, plain text" what is wrong with plain text? And what is wrong with SMTP?
Also email attachments can be binary encoded, base64 is just one option.
People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case. And "there are multiple different implementations" is a pretty poor justification, as a SMTP replacement would likely have the same issue (or worse).
Multiple implementations are a strength. In fact, you won't see a good replacement for SMTP without multiple independent implementations.
(What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers. Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.)
I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well.
I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on.
The problem isn't so much that we have multiple implementations (I agree that can potentially be a strength). The problem is that there's very little that's consistent across the platforms.
I'd like to see the HTML that is supported in e-mails standardised
Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads. </sarcasm>
We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already).
At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)
That doesn't fix anything either. Many clients make URLs clickable (even with text-only emails) and even if those clients didn't do that, someone will just copy and paste a URL into the address bar without looking. Given that the average user isn't an expert on domain names, it's not actually that hard to trick them into thinking that face.book.com isn't the same as facebook.com (and even those that are savvy enough to know the difference might misread the link and get fooled occasionally).
So like I said before, it's impossible to prevent social engineering.
It's impossible to prevent all cases of social engineering with a purely technical solution, this is true. But that doesn't mean that we should disregard how much easier phishing attacks are with the advent of HTML mail. The goal here is not so much to stop social engineering dead in its tracks as to prevent some of the low-effort attacks that do happen.
But again, I refer you to my HTML5 example. Should we dumb down what websites are capable of rendering to prevent social engineering via the web?
What you're proposing is making things harder to work in the hope that human intelligence will prevail. But the problem is that these cases are where human intelligence has failed, so making things harder is just counter productive. And this is why you can't prevent social engineering from happening and why crippling technology and creating a worse user experience just to try catch a few fringe cases is just a backwards approach to handling the issue.
Instead what we need is methods in place to verify the authenticity of senders and better education to users so that don't make silly mistakes like installing random "virus scanners" from web ads or clicking strange URLs in e-mails (and the URLs themselves could be standardised. eg no sub-domains become clickable, to prevent people falling for face.book.com).
No, we're talking about social engineering and the principle is the same regardless of whether it's e-mail or websites. You take a page -be that of an e-mail or website- make it look legitimate, and get people to follow dodgy links or download dodgy programs. You see the same thing with Facebook malware as well (which spreads by social engineering). So maybe we should close Facebook apps down.....actually, I'd be in favour of that last point hehehe.
Claiming this is a straw man argument only demonstrates how unwilling you are to view this from another's perspective. At least I've listened to your arguments and come up with potential workarounds.
The very fact that in HTML, a URL can look like a totally legitimate URL (the part between the > and the <), and yet the "a href=" could be anything, makes HTML a bad idea for email, where headers can be easily forged. Sure people can (and do) copy and paste, but having it in HTML just makes it that much harder to check a URL. Don't even get me started about the "onmouseover" events that can further obscure the true href.
I'd already addressed the hypertext argument in this discussion somewhere. And that point is one of the reasons why I want HTML standardised in e-mails, so we can remove the potentially harmful things like that from the e-mail spec and make it simpler for developers to create formated content (that's also safe for the end users) which will be rendered correctly across the various clients.
So yes, I do agree with you that anchor tags are misused in phishing mail, but let's make that a reason to fix the specification rather than just ignoring the issues completely (or worse yet, officially removing HTML and then letting 3rd party developers invent their own broken specs and us ending back exactly where were are now).
As for your comment about mouse over events, you can't have Javascript in HTML e-mails so that point is completely irrelevant.
You can't put the genie back in the bottle, unfortunately. Most people use clients that support HTML right now, and a new format that doesn't support some sort of rich text decoration (like HTML) isn't going to become popular enough to matter.
A ridiculously cheap and powerful alternative to HTML (or any other static format for that matter), would be a bytecode format intended to be executed in a sandboxed virtual machine. Possibly something like Flash. That should give you all the bells and whistles you could possibly want with a document format.
Now, there still are some loose ends about various screen sizes, preferred font family and size, and of course allowing textual searches, but those parameters should be few enough to be less problematic that HTML is right now.
Really? Flash is more secure than HTML? Maybe we should just embed Java applets in emails? This still doesn't solve the "click a link that takes them elsewhere" issue that was brought up.
I did say "sandboxed", did I not? Just have your VM refuse to download anything before you click somewhere, and let it compute the relevant URL so it can show it to you the way Firefox does. If this is too harsh, then relax the restriction to only download to, say, the domain name of the current main URL. If this is still too harsh, then have a NoScript like button to relax restrictions manually, on a case by case basis.
It would disable any form of cross scripting by default, which in my opinion is a better state of affairs than HTML alone is right now (now, you can embed an external image in a web page, and bam, Facebook knows what you read).
I wonder if this could be fixed by displaying SSL certificate status next to email titles. Much like browsers do for websites. This way before you open or at least before you click anything in the email you can see the validity of the sender.
I'd like to see it standardized that HTML is not supported in e-mails. Email worked fine before HTML came along and all the good email is still HTML-free... in my experience, only robots use HTML.
Plain text works fine in ASCII world. But if you ever need to read bi-directional emails like I did(e.g. Arabic text with some English words) you will understand the necessity of using HTML in email. Without proper formatting and markup that HTML offers, English words seem to fly around the text and end up at semi-random places.
I wish to see better support for non-ASCII plain text in email clients and web browsers, but until the HTML is all I have.
While the vast majority of my correspondence is plain text formatted. I do think there's a place for markup. Something that can embed images, provide different formatting styling (bold, italics, underline, colours and perhaps even sizes). It's also nice having an option between serif, sans serif and monospaced typefaces.
Then there's hyperlinks. If not like HTML anchor tags were the hypertext is independent to the destination, but still some method to follow links in e-mails as a lot of online registration requires email activation that way.
So do think there is a benefit for some level of markup in e-mails.
> Then there's hyperlinks. If not like HTML anchor tags were the hypertext is independent to the destination, but still some method to follow links in e-mails as a lot of online registration requires email activation that way.
Well, there's the (IIRC) RFC-specified way to write URLs within '<URL:' and '>' pairs, e.g. <URL:https://news.ycombinator.com/>; (interestingly, the HN URL-finder doesn't support that).
>What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers.
So SMTP and POP3/IMAP?
>Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.
I think that the 'clients to talk to servers' part is referring to sending email, unless you think the webmail is the only way to send email. POP/IMAP are for reading email from the receiving server, not for sending out new emails.
| So NNTP?
I was under the impression that most Usenet networks used UUCP.
| No, NNTP. UUCP hasn't been used seriously for
| over a decade.
Looked it up and it seems you are mostly[1] right. Some time ago, I picked up the notion that most large Usenet networks synced articles between each other using UUCP, but clients used NNTP to pull down articles for reading. Not being a very avid Usenet user, I just took this at face value (also not knowing much about UUCP, like the fact that it used Layer 1 or Layer 2 protocol prior to TCP/IP).
[1] According to Wikipedia, UUCP was still in use in 2006 for at least one software product.
Some people apparently use UUCP-over-SSH to get mails from their remote mailservers to their local ones, because, you know, fetchmail is evil or something.
Or because it allows them to have a disconnected SMTP server that receives mail. It would be the solution that I would use if I had a multi-user mail server on a network that only occasionally dialed up to the Internet to send/receive mail but was otherwise disconnected.
I'm interested in djb's IM2000 [1] proposal. Change the underlying model from a postal service one; adapt the infrastructure to the use cases. "Plain text" is not the problem with SMTP.
- Base64 thing is nonsense. As already stated SMTP supports binary and has for a long time.
- SMTPS is fairly well supported. In fact I currently connect to nothing which lacks it, and my email client auto-selects it when setting up new connections. Most of the hosts as far as I know support SMTPS out-of-the-box.
It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Most of the SMTP servers I've dealt with have archived and transmitted binary content over base64.
> Your list is full of misinformation.
Please don't be rude. And to address your bullet points:
- already addressed the binary / base64 remark
- already addressed the SMTPS remark
- yes, but those response codes are rarely transmitted back up the stack (and when they are, with a horribly garbled error). I'm talking about rebuilding the entire stack - from client to server - so that users get meaningful responses.
- of course HTTP is standardised. I never said it wasn't. So please don't turn this into a dumb trolling match where you make shit up to win an argument.
- I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Simply citing IM's as an argument misses the point. IM's are for conversations. Emails are for memos. There's no reason why memo's shouldn't be sent real time. In fact, Android's Gmail notifications are real time. Exchange pushes mail to Outlook clients in real time. There's no reason why real-time shouldn't be the standard for all e-mails. (note: we're not talking about real time character update. Just a standard system for pushing messages instead of the client periodically polling for updates).
> HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So in this instance SMTPS is less secure than HTTPS.
Sorry, not following you. HTTPS and SMTPS are both end to end encryption schemes. In fact they both use SSL in a similar way to secure traffic.
> It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience.
Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it.
Which mail server and version in particular are you having issues with?
In general almost all of the "big names" in mail servers support more than just base64 as standard.
> yes, but those response codes are rarely transmitted back up the stack
I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT).
> I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world.
Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).
> Sorry, not following you. HTTPS and SMTPS are both end to end encryption schemes. In fact they both use SSL in a similar way to secure traffic.
Yeah sorry, I explained my point abysmally there. What I meant was e-mails are only encrypted on a node-to-node basis but obviously a proportion of that transport isn't over SMTP. (My complaints are about the entire e-mail stack where as you're focusing on just SMTP, so there may have been a degree of us talking past each other).
> I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT).
We're definitely talking past each here. I'm on about client side not server side. (I should have been more clear from the outset that my complaints are about the entire email stack rather than specifically against SMTP)
> Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).
None of that is really an issue though. 1) we already have mail servers that retry for hours 2) we already have instant push mechanisms for e-mails on phones 3) you're actually reducing the network overhead by eliminating the POP3/IMAP handshakes every n minutes in favor of an idle TCP/IP connection with periodic pings.
> Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it. Which mail server and version in particular are you having issues with?
Maybe the base64 conversion is happening at my end then. It's never caused an issue as such (we have the capacity to cope with base64), it was just one of many niggles with the mismatch of the whole ecosystem. But I'll happily concede that I was wrong about the binary point :) (I don't particularly want to announce to the world what software and versions we're running at work for reasons that I hope you appreciate)
Totally, but that's not standardised across the clients either (plus there's a few different competing solutions for e-mail encryption). This is why I want to redesign the entire stack - to ensure that such solutions are standard across the ecosystem and available by default.
> But there's absolutely no reason why e-mails shouldn't be real time in the modern world.
You should look at SIP. It's combination of HTTP,SMTP,... and is really great protocol for hackers and creative people. Bad side of SIP is that it's friking huge, but this is because there are lot of extensions (btw even IM is SIP extension).
Plain text means anyone can read your message while it's going over the wire. That person sitting next to you in the coffee shop? He's running a packet sniffer and is reading everything you send, because it's plain text.
-- edit: In information security, plaintext means unencrypted. That's true for SMTP, and that's what I'm referring to. Am I wrong?
That's true for SMTP, and that's what I'm referring to. Am I wrong?
You are making the same mistake other posters were making, confusing two different definitions of "plain text". The one we're talking about is ASCII versus some binary obfuscated format (such as MS Word). Both can be encrypted and made equally as secure. Plain text formats are much more amenable to grepping, grokking and manipulation; they make locking out competing implementations harder. See "Keep Knowledge in Plain Text": http://pragmatictips.com/20
In addition, most arguments about "space savings" are rendered moot by compression (which usually works better on plain text), the fact that binary formats in practice almost always take up more space for the same content (even when uncompressed), and most importantly, storage and bandwidth have rendered the size argument totally irrelevant.
Plaintext is also a way of saying unencrypted, which SMTP is. By default, SMTP is plain text and plaintext, but you can send SMTP over SSL to make it plain text and encrypted.
It's my understanding that people often use "plaintext" in contrast to "ciphertext", so it's not unreasonable for someone to read "plaintext" and think "unencrypted".
Except in a discussion such as this one, where we're explicitly talking about Google locking out competitors by replacing plain (ASCII) text protocols with proprietary binary ones.
I've been trying to force myself to use "cleartext" instead of "plaintext" to alleviate this ambiguity. It's remarkably hard to do after so long, though.
ASCII also increases "file size" by about 30% (using 8 bits per character where 6 would suffice).
A better optimization than diligent bit-packing is a stateful compression system such as deflate. In addition to doing real compression, it will take care of any wasted bits in ASCII andd Base64 (latter being a MIME feature btw, not SMTP).
I don't know if people usually run SMTP with TLS compression enabled - if not they probably aren't too worried about the wasted bits.
> But this is all moot as the article is about XMPP, WebDav and RSS. The SMTP headline is nothing more than clickbait.
Not really. SMTP derives most of its utility from federation, and XMPP could have done the same.
Of course, this is nothing new: NNTP was replaced by a million forums, XMPP federation never really took hold, and no doubt someday mail federation will die too.
1. Google creates a service and gives it away for free.
2. Most alternative providers of the service die. The only ones that still provide the service must also give it away for free and leverage the service in some other way.
3. Google kills service.
Someone might try to fill the void, but why would they? Google might just provide the service again for free.
I wonder how much of the economy has been lost by giving away services for free. There's something wrong with the model where you can give something away for free so you can learn more about them to serve ads.
I remember a time when a certain government would buy a factory in another country, decrease prices to destroy all of the local competition and then lay off all of the factory workers and shut the factory down.
There's something wrong with the model where you can give something away for free so you can learn more about them to serve ads
There's nothing wrong with the model while Google or another corp do it for their own money (unlike gov.).
People are freely and willingly agree to see the ads in exchange to using free services. If you think they all wrong, that's just your personal opinion.
> If you think [X], that's just your personal opinion.
<meta> You're saying "I don't trust your opinion" without any justification beyond asserting that personal opinions have low status. If you suspect Markus can't back his claims up, then ask him to. Also remember that if you hold a contrary opinion, then one of you two (possibly both) is necessarily wrong as a simple matter of fact. </meta>
When Markus said "there's something wrong with X", I guess he's actually saying "X does harm". In the case of Gmail, I'm inclined to believe that it does harm: better brain hacking (ads) through breaches of privacy —Google is effectively reading your mail. Also the "destroying the economy" effect may be quite real, though I think it's probably limited to short term damages.
> People are freely and willingly agree to […].
You're assuming people are rational. They're not. People freely and willingly agree to bamboozle themselves all the time, sometimes creating a network effect that will make it easier for more people to bamboozle themselves. Some people gamble too much and owe money to a Mafioso. Others join the Scientology. Or start doing drugs in a moment of weakness. Or use proprietary software, and eventually lose data. Etc, etc.
About the specific case of "cloud" centralized services (web mail, video streaming, blogs, social networks…), the main harm is a progressive loss of privacy, and increased dependence. I think it all stemmed from the thought that people are consumers, not creators. Technically this got translated by "people hardly need to upload". Hence the 'A' in "ADSL". Symmetry was sacrificed at the altar of download rate. Since then, any hope to have a decent server at home was basically crushed. Some providers even prevent you to host a server, or to send e-mail (they typically force you to go through their crappy, rate-limited relays).
Anyway, people did create. They wrote. They made videos. They shared their life with friends. And they continued to send e-mail. Well, the only practical solution to do all that was to use convenient centralized services. No way any given person would have enough bandwidth to host one's popular video. So it all goes to YouTube, creating a serious imbalance in the data transfer rates that makes some network operators uneasy.
Oh, there's an exception: Bit-torrent. It is an incredibly convenient and scalable way to share big files on the internet. And it's quite popular. Alas, because of asymmetric bandwidth, it doesn't work nearly as well as it should. Which is basically why we used MegaUpload —until "Big IP" shut it down. With symmetric bandwidth, it would have had no use, and Big IP couldn't have annoyed so many people.
We could have had symmetric bandwidth, convenient servers at home and all the privacy and independence that they can give us. However the market, people's preference for short term convenience, and network effects conspired against it. And the worse is, it works even if each individual choice is rational. Take the web mails: it could be rational for you to use it, but then, you participate in a network effect that get people to only accept email from the big players. This has already started: mails sent from home are often dismissed as spam right away. Most such mail is spam, but the (possibly rational) rejection is hurting the legitimate users.
I'm pretty disappointed by the recent dropping of standards that Google has been doing.
I'm quite a sceptical person and I've never been a fan of any big corp, but Google has been the one that I've trusted my data in the most and that I've been happiest with.
I still trust them with some of my data, but I'm rapidly losing faith in them and in fact I'm starting to think that Microsoft are a more "open" company... and I'd consider myself a one-time Microsoft hater, but I think they've turned things around.
The only reason I'm still with them for email/calendars is that they're just so very very good. But they're privacy policies for GDrive scare me, so I don't use that.
Frankly though, I'm starting to think that my data and services would be better off with Microsoft now...
>I'm starting to think that Microsoft are a more "open" company...
I am disappointed too. But why is Microsoft more open? Does Microsoft have an open messaging protocol that I don't know of? Or an open source operating system? Or an open source browser? The last I checked, they were forcing manufacturers to ship computers with locked down bootloaders so you can't install your own operating system.
>But they're privacy policies for GDrive scare me, so I don't use that.
Can you clarify exactly what point in the privacy policy you are talking about?
Locked down boot loaders? The spec says you must be able to change it. And you can. Same with Chromebooks (dev switches) and Macs (rEFIt or boot camp). This is about security of the boot process for those who desire it. TPM is a feature just like Chrome's default support for DRM now. Necessary evils or useful security, all depends on who is in control. What makes service lockdown worse is you're not in control if you let someone else run it. Google should have at least given a replacement protocol. Make XMPP better: push the web forward!
This is true for x86, ARM has the opposite requirement. Presumably esolyt was referring to the Windows 8 Hardware Certification Requirements: Client and Server Systems[1] which state "On an ARM system, it is forbidden to enable Custom Mode." and "Disabling Secure Boot must not be possible on ARM systems." (page 122) which prevents booting to an OS not signed by Microsoft.
I thought I'd read somewhere previously that Google claimed rights to be able to do whatever they wanted with your data... I'm looking at that now and it's not clear to me but I may have been wrong about that.
I was a Microsoft hater when I was 15, too, but at least Microsoft makes their money by selling Windows, Office and the like rather than by selling my data. So even if their ‘cloud services’ such as Outlook.com are ad-supported in some way, at least they don’t completely rely on that, and I still have the choice whether to use Windows or not – all their services run just fine in Opera on Debian, too.
No, but they monetize that data in other ways. Some say it's not the same thing, I disagree. Ultimately, it's at your discretion, but they could very easily change that policy.
Google never had SMTP support. They run services that look like and advertise themselves as SMTP but violate the parts of the relevant RFPs that they don't find convenient:
http://lee-phillips.org/gmailRewriting/
They are even worse when it comes to IMAP. So if you have a sizable gmail account it is virtually impossible to switch to another client because gmail's labels doesn't at all match how IMAP folders behave. But it is hard to complain about a free service and it's quite possible that they couldn't have implemented all gmails features the way they did if they stuck to the IMAP standard.
I think the App Store does well on ios because it's the only way to load apps onto those devices, but I don't think it works as well on OS X. (I've found that most apps I install on my mbp aren't from the App Store).
I suppose, for everyday consumers (ie: less tech savvy), the experience may be different.
Anyway, I think developers will go where they think it's cool. And also, they'll go where they can get the most market share (and hence higher ROI potential). If that were to be an open platform, then so be it. In this case, it's not so open.
Wave was never federated. They announced plans to federate, and released a (severely limited) version of Wave as open source, but they never federated the reference implementation at wave.google.com.
The open source code doesn't include one of my favorite features, too... inline private messaging. If we want that back now we have to code it from scratch.
I have been trying to move away from Google services for a long time, unfortunately it is very tightly integrated in my life (Gmail, Android etc.) and I am both lazy and loath to spend money. Google is fine for now but I won't hesitate to jump ship if I find myself looking at better options.
You don't have to spend very _much_ money. I pay Fastmail $40 a year for 10GB ad-free IMAP+webmail (+2GB file storage that I never use, but I guess that's nice too), I find that very reasonable. It works great with K9-mail on Android (and any IMAP mail client I should think).
I have OwnCloud on my home server with a free SSL cert from StartSSL (you need a domain though if you want to use StartSSL, but that shouldn't cost you much). This gives me contacts and a calendar, which I sync to my Android phone (I also sync the owncloud calendar to my Emacs orgmode files over caldav, giving me two-way sync between Emacs and Android; it's also possible to sync carddav contacts into Emacs, but I haven't tried that yet).
OwnCloud also has a code editor with syntax highlighting, but it's no Google Docs killer yet (but then, I prefer writing TeX with Emacs anyway).
Once it's up and running, it's just as featureful as the Gmail+Google Contacts+Google Calendar combo. If you have android, you do need a Google account for downloading from the Play store, but 1) you can use a throwaway account for that 2) there's also f-droid and other alternative stores.
I switched to Gnus+Gwene for RSS feeds, but I wouldn't recommend that unless you really like Emacs. In any case, Google Reader is dead and new alternatives are showing up everywhere.
I use Firefox sync instead of Chromium. Apparantly owncloud can work as an FF sync server, but I haven't tried that yet.
DuckDuckGo fills most of my search needs better than Google ever did, though I do use its !scholar and !i keywords which redirect me back to Google's Scholar, Image searches.
It is possible to wean yourself off Google, and even third-party control of your data in general, but it takes a bit of effort. I find it rewarding though :)
Well, the quote from The Verge is the following: "Singhal says Google had to make the difficult decision to drop the very 'open' XMPP standard that it helped pioneer."
That's for the new Hangouts service. If you can keep using XMPP with your Gmail account, then it's not that terrible. I don't know if it's a forced replacement.
"Not federated support, but supports interop with XMPP clients. Meaning you can continue to use XMPP clients to log in to Google Talk and those messages will interop with folks on Hangouts."
So Google Talk will continue to live on (which allows them to implement some sort of server side functionality which converts a Gtalk message to a Hangout message when both members have activated Hangouts), it's just not actively being worked on.
So really the only effective change is the Chrome extension and Android apps have been replaced so you have to use a 3rd party Jabber client if you do want to use GTalk on those platforms.
Being forced to use a third party client will hopefully improve the quality of the third party clients. I hate how the current gtalk android app forces you to see/use all Google accounts configured on your phone and there is no way to reliably turn off never logging into one (say, an account you are trying to deprecate). Unfortunately, every other XMPP client for android has some serious deficiency (often a terrible UI).
They clearly announced that Talk is deprecated and will be replaced by Hangout. See this statement on their developer site: https://developers.google.com/talk/
The idea that Google has limited resources, in any practical manner, is laughable.
Google already does some kind of charity work, it would be interesting to see them support the continued development of open protocols as side projects to their main offering. This would be the cost of a handful of developers per project/protocol. But they didn't want to support even the small group that was working on Reader, which used to be a core business offering.
It would be interesting if it happened. I wouldn't hold my breath.
It doesn't matter if their resources are huge, which they are. They are finite and they have shown, lately quite often, that they don't want to spend them even on things which are relatively popular if they don't see strategic value in them.
Are you really arguing that keeping GTalk around as a competitor to their G+ messenger/hangout/whatever client will help them long term?
"Our users do not feel the need for SMTP so much as to make it profitable, we are pursuing other options, hence our SMTP servers will be closed down in 3 months' time. You can continue communicating using Google+ or Gmail."
Honestly, they look very much like losing some real-world perspective. I mean real as in 'the table holding my keyboard'.
If that was "Our users do not feel the need for Gmail so much as to make it profitable, we are pursuing other options, hence our GMail servers will be closed down in 3 months' time. You can continue communicating using Google+." I'd say yeah, they are losing some real-world perspective.
I'm using Google apps for my business account and i am really annoyed that they are still not able to provide a sync tool (or a direct exchange access) for Outlook 2013. I know I could use SMTP or IMAP, but I also want to sync calendar and contacts (that is, in fact, the reason I upgraded to the pro version of apps in the first place).
Don't get me wrong, it is completely ok for Google to disable free stuff as they want. I would, however, prefer that they support their paying customers better. Or, at least, offer an option to got premium and pay for the stuff we would like to use.
This is a good summary of a sad trend at Google. They fall from high, so we feel it unusually strongly. I still hope these are defensive moves as Google reacts to perceived threats from Facebook and others. I still hope they will eventually open up Google+ for interoperability.
It is good that people keep the pressure on Google regarding openness, it gives weight to the voice of the many employees there who want to do the right thing.
I'm not seeing in the link about them dropping XMPP support, not in the source link the author links to. I see them not building XMPP support into hangouts, but its not the same thing, hangouts are not an IM thing, they are a web conferencing thing.
I am not 100% certain I understand the difference between XMPP support and XMPP federation support. I assume though if they are dropping the support to route between chat providers than my websites' Zopim chat widget that I use for live support will no longer be able to talk with my Google Talk and thus I will no longer be able to text chat with customers on my websites through my Android-based smart phone. If so, that's a real bummer.
This is the slippery slope fallacy. Don't fall into actually arguing for or against it. The NRA does the same thing when it claims all gun rules lead to a gun ban.
Wait, so Google is dropping XMPP support because Outlook.com is supporting it to allow Gtalk users to chat on Outlook.com, so in order to perpetuate the GMail/GTalk lock-in by caging the Gtalk chat users to GMail, they're dropping standards support and killing access to all XMPP clients in existence including non-Microsoft ones? And they announce this right when Microsoft spent all the time and effort to allow Outlook.com users to chat with Gtalk friends and is rolling out that feature? Am I right? Someone tell me I am wrong!
That sounds unbelievable, coming from the supposedly open company even though it's coming on the heels of them trying lock out millions of Windows Phone users from Youtube by sending a C&D takedown on the app.
I guess open standards don't work when you're the guy trying to lock in users. If Google had a lock-in on Office products, looks like they will ditch "open data" and "open standards" in a heartbeat. They should change their policy to "open when it's convenient for us to flog it for PR purposes, else closed, oh and please store all your office documents on our cloud, we make it really convenient.".
This is not Open vs. Closed anymore, this is Corporations vs. Individuals, except for Mozilla which is becoming less powerful because Google uses its ad dollars to bundle Chrome with Flash, Acrobat and Java updates by default thereby reducing Firefox's share and has the nice side effect of reducing Google's payments to Mozilla for searches.
And Web DRM? Of course it's coming because IE, Chrome and Safari are going to be supporting it fully with 80% marketshare and people will blame Firefox if Netflix doesn't work in it and recommend you switch to Chrome to see movies! iOS, Android and Windows Phone, BBOS will add support for 100% tablet and phone support for the DRM. Firefox and Opera are powerless to stop it. We have already seen this play out with th h.264 HTML5 video support in Chrome fiasco when Google said it would drop H.264 from Chrome but did not and Mozilla was left holding the short end of the stick and had to recently had to eat crow and add support for H264. The web is owned by the corporates, not individuals anymore, there was some hope when Firefox was at 40%, not anymore. And we all willingly gave them the power by believing in "open" and "do no evil" and switching in droves.
I can picture Microsoft, Apple, Facebook, Google, Twitter, Amazon, Netflix etc executives sitting at a bar and giving toast to each other and laughing while we whine and debate fruitlessly with vitriol on these forums. All their stock valuations are up recently!
It's unbelievable because it's not true. They're dropping XMPP federation, which outlook.com never used anyway.
What outlook.com has done is they've added an XMPP client that lets you connect to Google's servers in order to send chat messages to GTalk users. That's still going to work.
Also note that what Microsoft have done is allow outlook.com users to communicate with GTalk users, but not the other way around.
It's sourced. That's a reply to a thread based here, which starts by quoting email from Google which says point blank that "the new [hangouts] service will not support XMPP".
But not with the new Hangouts service, which was announced to great ballyhoo in the Google I/O keynote yesterday as their new, general-use chat system for the vast bulk of their userbase. Which is what this whole conversation is about.
Ugh, and someone else states that XMPP will be disabled for users who chose to upgrade to hangouts.
Why this utter confusion over a simple thing after a whole three hour keynote yesterday and today no one seems to have a clue? Communication fail, if you ask me.
Color me skeptical, but there was similar confusion when SMS search stopped working suddenly,and then people realized Google killed it. XMPP support may stay, but I am not going to bet more than 2 bucks on it.
trying to lock out millions of Windows Phone users from Youtube by sending a C&D takedown on the app
Open browser → type youtube.com. How exactly are they "locked out"? Please stop throwing FUD; whether they should provide API access is a fair discussion, but let's not make stuff up.
So, to be clear, Google is supposed to make video chat with groups of people, recording to YouTube, desktop sharing, and Google Docs live editing work with XMPP? Or else they're evil?
I don't care too much about video chat, YouTube, etc, etc… Just about the plain old XMPP/Jabber user-to-user that was the base for Google Talk and that has been around for many years. The ability to talk with users from different providers.
That is being open. Without XMPP federation, we're effectively locked into Google. And it's just a matter of time that they drop XMPP altogether and we have to use their own protocol for chatting.
The company with half the top Phds and best engineers in the world and billions in profit every quarter is unable to create an open extension to XMPP to accomplish those and fallback gracefully if it's not supported? You really believe that?
You could assemble a team of 30 random HN posters and they would be able to do that.
So, I think they could do it, if and only if they wanted to. But they didn't and they themselves said it was because they didn't want to be open.
The hypothesized "video chat" protocol extension to XMPP already exists and it's called Jingle. FOSS client support isn't great, but it is progressing. So if this service isn't open to FOSS clients, that's more an issue of strategy than resources. (And indeed, the decision might change in future and be attributed to improved FOSS client performance.) If the service is indeed closed, however, they probably ought to update this page:
> I guess open standards don't work when you're the guy trying to lock in users.
That's obvious for Google too. They don't open source their search engine (or even Google Reader!). They open source a browser and an operating system to sell other stuff. For Google open source is a weapon.
Uh, no. None of them existed before Google. What did exist were two pieces of infrastructure (Webkit and the Linux kernel), and Google could've used both without open-sourcing the rest of the application, since the licenses allow it:
- Webkit is LGPL/BSD, so it can be linked to proprietary code without forcing its redistribution.
- The Linux kernel is GPL, but the license has never applied to userspace code, and everything "above" is either written by Google or non-copyleft open source code.
I think it's only reasonably for Google to contribute some after getting so much from open source projects, but that doesn't mean they didn't have the legal choice to do otherwise.
Oh, I was actually thinking of ChromeOS. But the point still stands, since they owned the copyright, and therefore they did have a choice to keep the userspace closed.
thats a silly thing to say. BSD licensed Unix already exists. if they wanted to build a proprietary OS on top of it (as Apple did) they would have. the fact that they already decided not to is the entire point here. Google chose GPL Licensed Linux over BSD Licensed Unix. From a technical perspective there's not a whole lot of difference. The license is the more important difference and we already know which they chose.
Apple didn’t build a proprietary OS on top of BSD licensed UNIX. They used the core of NEXTSTEP, which in turn used parts of several different BSD distros (though not its kernel or driver system).
Really? Why not use a BSD kernel then? And don't say because Linux is so much more advanced: for what Google would use it for, FreeBSD would do just fine.
It got us windows without media player (which nobody used), the browser ballot (which everyone endured) and a requirement that all their server protocols be documented sufficiently for competitors to implement the same service (which we all benefited from to a large degree). http://europa.eu/rapid/press-release_MEMO-04-70_en.htm?local...
But they were only required to incorporate support for ODF in office[1], and it seems like they have complied[2]. is there any relationship between ODF and DOC?
The EU pressured Microsoft into documenting various parts relevant for interoperability. One of them is the whole stack revolving around AD, which resulted in Samba 4. I don't know if this includes Office formats.
As for YouTube it is and always have been available on the web for windows phone.
Microsoft in clear violation of Google's TOS used undocumented APIs and stripped ads from YouTube and now they have the audacity to say that they would have complied by the TOS if it suited them better.
Please take your anti-Google (probably Microsoft sponsored astroturf) elsewhere:
Except, Microsoft did not strip ads from the videos. They said yesterday that they will be happy to serve ads if Google lets them access. And please, let the legal departments decide if it is a clear violation or not. Do not take a decision on your own.
I think you are the one who is astro-turfing here, if i apply the finger pointing criteria to you too. It is better if you reply to the argument leaving your personal preferences neatly tucked in.
Microsoft is flagrantly violating YouTube's terms of service. Saying they would serve ads if YouTube had an API for it is like me using your obviously not public WiFi and saying I would pay for it if you let me.
What Google's been saying from 3 years while dragging it's feet is that Windows Phone does not have enough users to make an app for, but now their claim is that so many people are using the Microsoft Youtube App for Windows Phone that it's hurting the content creators. Huh? Why can't they monetize them by making an app and show twice as many ads in it just to spite WP users? No, they won't. They want to disadvantage Windows Phone compared to Android. Vimeo has had a Windows Phone app from a long time, and Google' can't afford to make one? And you believe them?
Why don't they come out with the real reason then, like Apple, Facebook, Twitter, Microsoft, Skype, do about closing down things and eat up the bad press? Why beat around the bush and play delay tactics and hide behind facts? Oh, they want to protect their clean image of being "open" and "do no evil". This is a ploy by Microsoft to force Google to tell the public exactly why they refuse to make a Youtube app and even ban Microsoft from doing so.
How can Windows Phone have so few users that use YouTube that it's not worth monetizing and have so many users that use Microsoft's new app that it's hurting Google and content creator revenue? Why not agree to allow MS to show Google ads and make money since they don't have to spend the money to create the app but can take the profits?
I am happy that the customers are getting access to the most widely used video site. I will let the companies dunk it out as to what is unauthorized or what is not. MS responded to it already, and said they are will be happy to work towards betterment of mutual customers on a day where Larry page loathed negativity among companies. Or something to that effect.
They're abusing the patent system to extort money from Android device manufacturers and they have to gall to completely ignore requirements in a ToS.
I'm looking forward to the day when Microsoft is completely irrelevant. They should just shut down everything except for the research and Xbox departments now.
You know, saying that anyone who disagrees with your opinion is "probably Microsoft sponsored astroturf" just makes me picture you with a tin foil hat on your head.
Sometimes the truth is a lot simpler than you're thinking it is. You write a lot of posts that are pro-Google. Are you sponsored by Google?!?!?
'Are you sponsored by Google?' I think so. I've been accused of being an 'anti-google astroturfer' before. 'Gosh that's odd', I thought. Then I read the posts written by my accuser. Pro-google, down the line - echoing PR talking points. Normal people don't do this. I do think Google hires PR flacks to post here on HN.
Seems more likely he is just a regular Google employee who supports what they are doing, albeit a bit aggressively. There are many of them on HN. Not sure why either of you are assuming malice here.
And I don't work for Microsoft, never worked for them or any affiliates nor own their stock or ever owned it and the closest that I know I was ever to any MS employee was when I was interviewing in Seattle at Amazon for a C++/Linux position.
Now, can we get on with the discussion instead of trying to derail it by ad hominem attacks?
You don't think it's relevant? Microsoft is paying millions to run anti-Google attack ads and smear campaigns everywhere, it's not unthinkable that they would hire astroturf to roam sites like HN, so for the sake of the health of this community they ought to be pointed out.
Just because you are paranoid, does not give you the right to label anyone as paid for roaming a site and attacking your favourite company. This feels like the "either you are with us or them" mentality". Please, if you do not have the proof, do not go down this path. It is dangerous, and lets anyone label anyone as being a shill and paid commentator.
There's up and down voting for that, and probably HN's spam filtering matters too. Making comments expressly meant to derail the conversation isn't necessary or useful.
If Microsoft is paying recoiledsnake a billion dollars to make that post, does it change any of the facts in it? No? Then why whinge about possible or probably astroturfing instead of just addressing the facts in their post?
Unless you want HN to do a full background check on every poster here, it's hard to identify Google/Apple/Microsoft fans/haters/employees/shareholders. You have the option to remain silent, vote and move on if you're not interested in a post.
Hyperbole aside (they won’t drop SMTP) that is a very narrow and unfair view on the situation, they at least tried for years to make it work with these standards and failed.
They were obviously the last ones doing so, and this new approach is mainly about modernising their infrastructure.
Is there anyone else of any consequence out there who is building these sorts of messaging apps on top of XMPP?
Google was the last one standing, and it just didn't work out.
And why cherry pick “standards”? how about web standard? Chromium is a very big commitment to them.
Edit: I should be more specific as I meant a federated implementation of XMPP.
Lync's native protocol is SIP, a standard that Google could also have adopted years ago, but they went with the more modern and 'better' competing XMPP standard.
Microsoft went through a lot of problems implementing SIP it for Lync and its predecessors LCS and OCS, but they remained within the standard and worked on interoperability and improving the standard around security, even if it took more time than going it alone.
The roles of Microsoft and Google have certainly switched around.
To be fair, while the Office suite itself is pretty decent these days, Office 365 is terrible. Microsoft is still very much a software company and not a services company.
Coincidentally, only yesterday I installed an XMPP daemon on one of my servers and configured it as a message relay so I can send and receive SMS from my PC via my phone.
Facebook chat also uses XMPP.
So in answer to your question: yes, there are people still building new stuff on top of XMPP.
However I will concede that I'm also a bit IRC advocate - so I'm probably the wrong person to comment on the best newest social protocols.
No one is taking xmpp away from your server or the applications that are using it; but take Facebook: did they do any effort of integrating their chat with the Gmail one?
You're missing my point. The previous poster stated that nobody was using XMPP and I was simply stating that wasn't true.
I'm not worried that Google might someone how hack into my server and kill XMPP on that, nor am I commenting on the level of the Facebook Chat integration with the wider XMPP community (in fact the reason I run my own XMPP server was to have a private channel, so I can completely understand why Facebook have chosen to do so as well).
My comment was just stating that XMPP is still widely used - despite other peoples claims that Google were it's only supporters.
The SMS thing? It's basically just an Android app (gtalksms [1]). But I wanted a private encrypted network to control it from (I actually go further and then hook the XMPP server into bitlbee which is an IRC server for IM clients. So now I can control my phone, Twitter, Facebook Chat and Windows Messenger all from Irssi.
> Is there anyone else of any consequence out there who is building these sorts of messaging apps on top of XMPP?
I use XMPP to talk with Google Talk users from an XMPP account hosted on my own server. I will be annoyed if Google users are driven away from Google Talk to something that I cannot interact with unless I use a Google account.
Same here; and it's not like it's hard. If you're running a web server and/or DNS, it's as easy as 'apt-get install ejabberd', tweak some well documented settings in the config file, add a few lines to the DNS config, and bam! I'm talking to my friends on GTalk via my own private XMPP server.
Other than a basic understanding of what it is, I don't know anything about XMPP. What's wrong with it? Or, more specifically, what does it do poorly that other things have eclipsed?
It is federated in such a way that it is sometimes difficult to establish new features, as there are a multitude of servers and clients, which would all have to support said new features for them to stick.
Some see that as an advantage, but it definitely doesn’t help ‘innovate’ and re-invent the wheel every other month. GPG encryption, for example, while standardised in XEP-something, is still not really supported in widely available clients. OTR encryption is more of a layer atop the actual protocol and hence somewhat inelegant (and also not that widely available).
Also it’s XML-based, which could be argued is even worse than base64, but that should be a rather small concern given how popular JSON and the likes are nowadays.
But Google, as a wealthy company and the controller of such a big chunk of the XMPP user base, was (maybe uniquely) in a good position to overcome these problems. It could have established a de facto standard set of supported features, and maybe pushed out some code to help clients implement awkward bits of it.
Stop relying on Google for everything. Stop building things on Google. No company should have such a big impact on your life and society as a whole.
Several months ago I moved everything to the Microsoft ecosystem. In some ways its trading one taskmaster for another, but if we don't exercise our freedom of choice in the marketplace we soon won't have a choice.
Clearly not, since SMTP and IMAP are still in far greater use than RSS and XMPP ever were. But do you think that question will never be legitimate? Will we still be using SMTP in 2113?
Google is planning to be around for a long time. What percentage of the resources of your organization do you devote to supporting old technologies in limited use?
Of course, IMAP and SMTP might be replaced by better protocols in the future (as POP3 was). However, my point was that the fact that the search trend for a protocol is downhill does not mean it is no longer used and should be scrapped. I argue that XMPP is in wider use than it has ever been. And that RSS has not been replaced by anything yet. Hence stopping their support in favour of a locked proprietary platform is bad and explaining this move by google trends is absurd.
Clearly a closed web interface that only runs in Chrome would be much better for everyone! Then people could always be sure with whom they communicate, nobody could hack or social-engineer their way into other accounts, and everyone would have to follow The Rules or they’ll have their account closed for good.