What's next Google? Dropping SMTP support?
eschnou.com
eschnou.com
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.
But this is all moot as the article is about XMPP, WebDav and RSS. The SMTP headline is nothing more than clickbait.
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).
Well it's not exactly secure, for one thing.
> Also email attachments can be binary encoded, base64 is just one option.
base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP.
> People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case.
Actually I have given a long list of reasons every time I've complained about SMTP[1][2]
[1] https://news.ycombinator.com/item?id=5510910 [2] https://news.ycombinator.com/item?id=5297472
No more or less secure than HTTP/HTTPS. In fact exactly as secure as...
>base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP.
http://tools.ietf.org/html/rfc3030
http://tools.ietf.org/html/rfc2045
http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding
>Actually I have given a long list of reasons every time I've complained about SMTP >https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5297472
Your list is full of misinformation.
- 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.
- SMTP reply codes are standardised (http://www.ietf.org/rfc/rfc1893.txt)
- HTML is standardised.
- SMTP is not designed to be real-time. That is what IM is designed to provide.
HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So SMTPS is less secure than HTTPS.
> http://tools.ietf.org/html/rfc3030
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).
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).
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)
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).
(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'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.
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.
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)
So like I said before, it's impossible to prevent social engineering.
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).
Strawman; we're talking about email, where the combination of header forging and HTML mis-labeling are what's really dangerous, not web pages.
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.
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.
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.
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).
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.
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).
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.
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.
So NNTP?
| So SMTP and POP3/IMAP?
| So NNTP?
They probably shouldn't be, though, there's an IMAP extension for submission.
> I was under the impression that most Usenet networks used UUCP.
No, NNTP. UUCP hasn't been used seriously for over a decade.
Yours, news.ycombinator.com!ethomson
| No, NNTP. UUCP hasn't been used seriously for
| over a decade.
[1] According to Wikipedia, UUCP was still in use in 2006 for at least one software product.
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?
Plain text is a style of encoding information (e.g. binary, XML, JSON, plain text, etc). Encryption determines if someone can intercept your message.
Something can be both plain text and secure, like HTTPS for one example.
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.
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.
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.
It's a crying shame, it really is.
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...
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. :)
[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.
If anything, your logic would argue that the harm to open standards happened when Reader was introduced, not when it was killed, no?
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.
Google is already Gratis (the ads don't count as a price in most people's minds).
Religion is inevitable. http://www.shirky.com/writings/group_enemy.html
Nothing that the older timers don't already know since the mainframe days.
Google is just arriving to the point where the shareholders have more to say than whatever a few geeks scattered around the world might think.
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.
Interesting times for companies like Google.
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.
<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 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 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?
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.
1. http://msdn.microsoft.com/en-us/library/windows/hardware/hh7...
Even better, they support an standard called SIP. [1]
> Or an open source operating system? Or an open source browser?
They believe in open standards more than open source, although the Azure group very actively supports open source lately
[1] http://en.wikipedia.org/wiki/Session_Initiation_Protocol
Not in Skype they don't
Many times, these big companies are not the best in their offerings for a given service but rely on their brand to push adoption.
You can't expect to have it both ways, especially since Apple has proven that a closed infrastructure (walled garden) works.
Wave had lots of problems one of which was that they gave up on it fairly quickly.
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.
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 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 :)
The Verge says Hangouts is not using XMPP but does it mean that XMPP (Google Talk) is definitely going away?
We may need to wait for Google's announcement.
https://plus.google.com/107968525907303243288/posts/HFe3W7A9...
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.
EDIT: well, not really good news as they kill the federated support.
https://play.google.com/store/apps/details?id=com.xabber.and...
But if I can't talk with my contacts using a Gmail account, then is not that useful.
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 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'.
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.
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 logged into G+
I'm logged into GTalk with a Jabber client.
Someone messages me using the google web interface.
I get the message in my Jabber client.
I'm seriously just waiting for the anti-trust cases to roll in. Isn't this just like the 90's with Microsoft?
Same shit, different names.
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!
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.
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.
But yes, they are evil.
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:
https://news.ycombinator.com/submitted?id=recoiledsnake
https://news.ycombinator.com/threads?id=recoiledsnake
These submission are a honeypot for your sort.
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.
Because if you don't then YOU are the one degrading the quality of HN with baseless allegations.
Whether or not he is being paid and regardless of who their employer may be, it seems pretty clear they are working for Microsoft.
Now, can we get on with the discussion instead of trying to derail it by ad hominem attacks?
If you're not getting paid you should be.
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.
They built an unauthorized app and now they are complaining that the app is unauthorized.
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.
Trying to enforce a client side rule of 'no downloading' when every web browser in the world can download should be disregarded and mocked heartily.
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?
2. Microsoft is obliged to follow the ToS on websites they are pulling data from. Regardless of user count.
I'd love to see Google forced to admit what they are doing also, though.
Trying to paint this black/white picture of someone just because they disagree with you is frankly pathetic.
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?!?!?
We live in a world where weird fanboys exist for just about anything, including Google and Microsoft.
Fanboys work for free.
(From all directions, not just pro-google.)
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.
> Your users may use any chat client that supports XMPP. XMPP clients will continue to work as usual with the App Engine XMPP service.
> Note that the changes discussed above have no impact on non-Google XMPP clients
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.
http://www.fsf.org/blogs/sysadmin/google-reinstates-federate...
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.
No, those were already open source before Google got involved, so Google didn’t really have a choice.
- 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.
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).
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.
http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Pr...
I even checked the references, the MS page adds nothing to wikipedia's info in this matter
http://www.microsoft.com/openspecifications/en/us/programs/o...
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...
[1] http://www.reuters.com/article/2008/05/22/us-eu-microsoft-id...
[2] http://www.infoworld.com/d/open-source-software/how-microsof...
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.
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.
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.
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.
...
PLEASE!
:-D
(with apologies to Henny Youngman -- http://en.wikipedia.org/wiki/Henny_Youngman)
Better known as "reinvention of shit that already worked because we want to lock you into our platform and monetize your eyeballs."
Numerous organizations have deployments of these and other, smaller XMPP IM servers.
As for cherry picking standards, isn't that exactly what you're doing with your statement on Chromium and web standards?
edit: XMPP federation feature is not available in Ofice365 Lync options, that's sad
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.
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.
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.
> Several months ago I moved everything to the Microsoft ecosystem.
So now Microsoft has such a big impact on your life?
Wouldn't it make more sense to spread things out over a variety of services?
For reasons of workflow efficiency, no.
Web Search Interest for RSS; down 78% from its peak in 2006:
http://www.google.com/trends/explore#q=RSS
Web Search Interest for XMPP; down 33% from its peak in 2010:
http://www.google.com/trends/explore#q=XMPP
As Bob Dylan once said: the times, they are a-changin'.
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?