XMPP Operators Begin Requiring Encryption, Google Still Not Allowing TLS
Via El Reg comes news that major XMPP (formerly known as Jabber, likely the only widely used distributed instant messaging protocol other than IRC) operators have all begun requiring encryption for client-to-server and server-to-server connections. Quoting the Prosidy developers: "Last year Peter Saint-Andre laid out a plan for strengthening the security of the XMPP network. The manifesto, to date signed by over 70 XMPP service operators and software developers, offered a rallying point for those interested in ensuring the security of XMPP for its users. Today is the date that the manifesto gave for the final 'flip of the switch': as of today many XMPP services will begin refusing unencrypted connections. If you run an XMPP service, we encourage you to do the same. On the xmpp.org wiki you can find instructions for all the popular XMPP server software. While XMPP is an open distributed network, obviously no single entity can 'mandate' encryption for the whole network — but as a group we are moving in the right direction."
There is a handy tool to test your server. A result worth noting is Google's: they still do not support TLS for server-to-server connections, and their sudden dropping of TLS s2s connections a few years ago is likely the primary reason operators switched off mandatory TLS for s2s (I know that's why I did it). Although Google Hangouts offers no federation, GTalk still does, but it appears that the XMPP network-at-large will now cease to federate with Google voluntarily.
So their lack of support for TLS with it is sort of a moot point.
http://tech.slashdot.org/story...
We should do the same for all EMAIL. Require encrypted connections. Eliminate spam while we're at it.
Google is acquiring all of the arrogant bullshit attitudes and implementing arbitrary rules and standards just the same way that microsoft did.
It's a sad shame. But an evil empire smells not different from an empire that's rotting.
Why is why Google will drop XMPP. You can use plugins for true end-to-end encryption. This disallows Google from reading your chats which it will never stand for.
No one would ever have expected Google to make the transition from evil to incompetent so quickly.
Google is pretty well seated in the back pocket of the US government. Even if they were to endorse TLS it doesnt preclude them from silently forwarding all your conversations to the NSA.
Voluntarily ceasing to federate is the logical conclusion to a software project run by people who care about their users, so nothing special here. However, voluntarily ablating yourself from Google, Facebook, Twitter, snapchat, and other "social" sites is probably a longterm goal to which we should all strive.
adblock, noscript, and ssl everywhere are all valid tools. For Android users AdAway can be found on F-Droid.org. Your alternative search engine is Duckduckgo.com, and although its nowhere near as powerful openstreetmaps can be used in place of google maps quite often. Alternative free email can be found at freeshell.org (it includes webmail too.) Use unbound for DNS recursion instead of Google, or use www.opennicproject.org.
Good people go to bed earlier.
No one ever expected Google to make the transition from evil to incompetent so quickly. There must be some chairs flying in the boardroom of Microsoft.
They currently are behind development of the most popular (And open source!) mobile OS out there
... which is getting progressively less open, as more and more things move from the OS proper to Play Services (which is both closed and heavily license encumbered.)
, the most popular (and "mostly" open source) desktop browser out there
... which has forked its rendering engine, no longer uses standard widget toolkits, and incorporates a number of proprietary extensions (like DRM for HTML5 video).
and one of the most popular (and very open) email systems out there.
... which is a meaningless phrase, since it's just as "open" as every other functional e-mail service. Outlook.com is every bit as open, and every bit as closed as GMail.
Use Retroshare.
There are proposed systems that require expensive-to-generate signatures - something where sending an email might require a minute or so of processor time.
The keyword is "hashcash".
the calculation intended to be a minor inconvenience for desktops can be a serious problem for mobile devices.
At first, I thought a mobile device could start generating hashcash once it charges past 80%. But then I tried Google hashcash mobile which brought up this article as the first result: "It seems plausible that if a system like stored Hashcash were developed, some people would prefer to purchase stored Hashcash directly instead of generating it themselves. A market for stored Hashcash would emerge, with the value being some function of the supply and demand of scarce Internet resources." Even before I started reading that article's comments, I realized that the Bitcoin network had implemented just that. Perhaps people with the money to pay the $336 per year difference between a dumbphone plan and a smartphone plan could spend a little more to buy hashcash.
Play store is included with AOSP
Since when? I thought the Google Play Store client was the one app not included with AOSP. As I understand it, the Google Play Store client is lawfully available only as a preinstalled app on devices manufactured by OHA member companies. If you're an OHA member, you can't manufacture Android-fork for other companies, and all Android devices that you make must conform to the CDD. In the early days of Android (1.x and I think early 2.x), all devices had to include a working cellular modem, which ruled out an Android-based competitor to the iPod touch. And even now, the CDD requires that the screen size presented to an application never change after installation, which severely limits the sort of multitasking that can be done on an Android tablet.
We have a chat system at work, based upon xmpp. In the set up of my account it says 'encryption required'. Does this mean only my chat buddies can see the messages, and my employer cannot read those chats?
Please login to access my lawn
Compromises over screen size are hardly an indication of being "less open"; im not even sure what "evil" spin you could put on that.
If the screen size never changes, then it's impossible to have two applications on the screen at once. This means apps run all maximized all the time despite a 7" tablet's screen being big enough for two phone apps, and if you want to see two apps running at the same time, you have to pay for twice as many devices.
Let's just hope that E-Mail doesn't suffer the same fate at the hands of GMail.
You haven't been using Facebook Messaging, recently ?
The only reason it's not considered such by all is that they still tactfully manage to avoid calling it "E-Mail".
But the set of functionality is very similar to any other webmail system (including attachement, etc.) minus the interoperability.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Not a real problem for most uses
It is, it's only "not a real problem" for user sending one-to-one e-mails.
As soon as you send one-to-many e-mails (newsletter, mailing-list, announcement, or just corresponding with lots of friends) this starts to be a problem, as you need to recalculate a new hash for all mail recipient.
but a serious hold-up for spammers.
Not a hold-up, at all.
No true spammer does still mail all his/her spam from home using a single mail server (the spam will be immediately detected and blacklisted).
Spammer do routinely use botnets. As each single bot doesn't send much SPAM itself alone, each single bot won't have much problem with hashcash.
Remember, the definite characteristic of SPAM isn't that it's addressed to multiple recipient, it's that it is unsolicited.
It happens that it used to be sent simultaneously to several recipient at a time, because back then, it was best done so.
But hashcash (like many other proposed systems) are not detector for "unwantedness" of e-mail, they don't address the fundamental problem with SPAM, they only address minute detail of the way it was done in the past.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
They both server different goals.
Server encryption, helps securing the service.
But it doesn't address privacy. (the channel is only secured between 2 servers, or between a client and a server).
End-to-End encryption (like OTR) is for privacy.
It make sure that, no matter what, the message will stay encrypted during the whole transit between one user to the other user.
Even during the time spent on servers, an OTR-encrypted message is still useless and not eavesdropable.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Who covers leap years? (24/7 is sufficient.)
How is certificate validation done? The server setup documentation mention no CA repository is to be configured, which suggests no validation is done.
And TLS without certificate validation is vulnerable to easy Man In The Middle attacks. It is barely more secure than plain text commuications