> 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.
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...
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.