Key Points:
…after spending the last few months periodically poking around the trees inhabited by little birdies, I do have good news for fans of coercive government regulation,” Gruber says. “Apple’s hand was effectively forced. But by China, not the EU.”
“Coercive government regulation” lmao.
Gruber points to a new law in the works in China that will require that 5G devices support RCS in order to receive certification in the country.
Chinese carriers have been proponents of RCS for years, and last year, the Chinese government began the process of codifying into law that to achieve certification, new 5G devices will be required to support RCS. Shockingly, the Chinese government seemingly isn’t concerned that the RCS standard has no provisions for encryption. The little birdies I’ve spoken to all said the same thing: iOS support for RCS is all about China.
“Shockingly”.
Apple would prefer simply to continue ignoring RCS, on the grounds that they want to support neither any new non-E2EE protocols, nor any new carrier-controlled protocols (whether encrypted or not). But when the CCP says device makers must jump to sell their products in China, Apple asks “How high?”
The sheer Sinophobia omg.
One narrative in the months since Apple’s RCS announcement in November has been that the move was driven by the Digital Markets Act in the European Union. The DMA, however, makes no mention of RCS specifically – and now have official confirmation that iMessage is not big enough in the EU to fall under the purview of the DMA.
There goes EU, the saviour of digital rights.
Anyways, what an article.
Ios users think iMessage is secure?
Yeah, it’s a big part of the onboarding stuff when you make an account. It’s also in advertising and stuff.
They’re generally right too because the kind of mitm attacks that police or others make against texting with either stingray-likes or subpoenaed carriers are defeated by the encryption. It made the news some years ago even.
E: I had a little time to double check myself on this one and foiad training documents from the fbi showed that for both google rcs (not other rcs servers) and imessages they had to get warrants for the google cloud or icloud services the messages were backed up on instead of just using “normal” wiretapping methods in order to get the contents.
It is possible to turn off google cloud and icloud backup of messages, and that’s the smart way to go with it in my opinion.
If it's possible for the cloud service to comply with a warrant it's not correctly implemented end to end encryption.
That’s a great point, and while it’s generally frowned upon to use Wikipedia as a source, I’m not fucking digging through a bunch of crap to post a wall of links on a lib as we would normally do, both because I’m lazy and because you’re not a lib. To that end I’d like to direct you towards the modern usage and Compliance and regulatory requirements for content inspection sections of the Wikipedia article on end to end encryption.
The long and the short of it is that the language around e2ee is muddied now and sometimes a company is offering a service that would be illegal or prohibitively difficult to feature e2ee on in the state its operating in, and that’s important to know.
The point of my original comment way up there in our reply chain was that the default position of an ios user concerned about security should be “turn it off” with regards to rcs because the security posture of most users is to trust imessages and not to trust anything else, it would be too easy to say “ah ha, I can get android style imessages now!” under the assumption of some degree of feature parity including encryption and there is no guarantee that any old rcs message is encrypted. An ios user who turns off rcs will assume that the messages are insecure and will be more likely to have a safer set of interactions than if they trust the transportation layer security of the content which is ambiguously communicated, not communicated or communicated erroneously.
I’m actually pretty confident that the coming rcs implementation won’t be like that, but like you my default position is one of mistrust.
I'm quite a bit more doomer about security than that. An iOS user truly concerned about security should sell their iphone, get an old pre-Intel Management Engine laptop or something, install libreboot and linux, and manually encrypt all their emails with GPG. An iOS user only somewhat concerned about security should look into dedicated secure messaging apps made by companies or groups not subject to their own jurisdiction's laws. The casual iOS user who believes Apple marketing should just leave rcs on to make things that tiny bit more complicated for the world's various intelligence services.
That’s the point I was making though, there’s no guarantee that rcs would make things more complicated for the various intelligence services and a distinct (though, like I said, not my expectation) possibility that it would actually make things easier for them even if one of the encryption supporting rcs services isn’t actively collaborating with law enforcement.
It’s like opening a second loading bay door and suggesting it’ll make things more complex for intruders.
Some of the decisions around apples stuff are actually providing more security than just security through obscurity. Consider what we’re talking about: there’s the security of icloud and that’s it. You either have encrypted messages or plain old sms. The system communicates that to the user very clearly. Even if the system communicated the security of rcs communications as clearly as it does with imessage and sms, that’s still another thing for the user to screw up, another service for law enforcement to put the screws to.
At some point being able to say to people in a really clear way that this is secure, and the other thing isn’t is way better than having some weird in between added in.
We’re kinda chasing each other around a tree and missing the forest though, if the last few years are any indication they’ll just gobble up the push notifications and use them to establish probable cause to arrest then apply the rubber hose until you give up the passcode anyway.