Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't understand why they would do a default unencrypted messaging service today.


Probably because the spec started all the way back in 2008, and you could revise it yet again, even though almost nobody is currently supporting it, or you can get it out and improve the situation for many people, even though it's not perfect. I imagine pushing for an extension to support encryption might be a lot easier if there's actual uses to call for it.

Given that Google has started rolling it out with a fallback to Google servers if the network provider doesn't supply one, and Google has said they understand encryption is important and they will push for it, we might actually see some progress soon (on both the adoption and encryption fronts) if we're very lucky.

You can see references to that info in some of my other comments on this article, since I looked it up again today after mentioning it earlier.


> I imagine pushing for an extension to support encryption might be a lot easier if there's actual uses to call for it.

That's letting Google off the hook. Nobody knows better about the level of surveillance users are under. Encryption should be feature #1. For them to roll out an unencrypted service borders on malpractice. Luckily for them, software engineers aren't licensed.

> Google has started rolling it out with a fallback to Google servers

Even though Google may not be the most trustworthy company, I trust them far, far more than my ISP and cell company. If I could choose which back end I want to be on, I would choose Google's, especially if that meant messages would be end-to-end encrypted within that sphere.


> Encryption should be feature #1.

Well, you're free to travel back in time to 2008 and propose it to the working group that was making the spec...

> If I could choose which back end I want to be on, I would choose Google's, especially if that meant messages would be end-to-end encrypted within that sphere.

I agree, but it appears the way the protocol is federated means that there isn't specifically one back end. Also, since it does some discovery with a "hidden" sms to the other end to ask if it supports RCS, I imagine end-to-end encryption might not be that hard to tack on...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: