gatorguy

davidw said:

spheric said:

davidw said:

gatorguy said:

davidw said:

gatorguy said:

So I've read an interesting perspective on Apple and RCS this morning, courtesy of Gruber and PED. 

While many here assume Apple's announcement of RCS coming to iMessage was in response to the EU's DMA, it might actually be due to China. Unlike European regulators who Apple feels free to argue with or if need be "maliciously comply", China is in the process of mandating RCS (without encryption for obvious reasons) despite Apple's preferences.They are a government that when they tell Apple to jump it's only a question of how high. There is no such thing as malicious compliance with China's mandates.

Without integrating RCS, Apple would be banned from China's smartphone market sometime later this year. It wasn't because of the EU if Gruber's sources are to be believed. Further, if those sources are correct I would not hold out hope for E2EE coming to the service with iMessage either even if it makes it into the standard. China requires source code be submitted for inspection in order to "ensure the security and privacy" of the algorithms used before that encryption method is permitted in the country.

It's not any government that will dictate whether Apple have to adopt RCS...

The proposed regulation requires new 5G devices to support RCS (locally called 5G messaging) to get certification. https://www.reddit.com/r/UniversalProfile/comments/153rrwl/chinas_proposed_regulation_could_force_apple_to/

That is not the same as forcing Apple to support RCS  by opening up iMessage or Apple Messages. Apple could satisfy the RCS requirement by letting the carrier install their own RCS client in iOS. The same as what the telecoms did with SMS.

The same as … what exactly? Apple never allowed any third-Party sms clients — or perhaps, it’s just that no one ever offered one. SMS is part of the basic cellphone protocol. Apple could support it in 2007 — or not have text messaging. No telecoms provider forced anything. 

But this doesn't mean that China will allow Apple to use their own RCS client. China telecoms can easily force Apple .... Yada yada

David, did you research any of this before posting as though it's fact? It does not appear you did. 

If you read the China proposed regulation I linked earlier (it will translate to English) you would understand it is Apple's responsibility to include it prior to certification by Chinese regulators and not the carriers post-certification. That's common sense since there would have been no reason for it if the carriers could already mandate it.

Number two, and answered with a simple question: Are there carriers who offer their own RCS services on Android devices they sell? The answer is yes. And how could that be if Google has forced them to use only Google Messages? Because Google hasn't forced them to do anything.
Google contributed the Android RCS client protocol to the GSMA in 2016, free for them to include under the RCS standard. You're confusing basic RCS with the end-to-end encryption and other advanced features built on top of it.

Here's how to think about it David: It's akin to iMessage built on top of Messages. The encryption and certain other advanced features come from iMessage. You can use other apps to send texts from your iPhone, but if you want to use all of iMessage's features, you must use the Messages app. 

The carriers are not currently interested in E2EE RCS, so that's put on Google's back via Google Messages.

It's only been somewhat recently that the big three US carriers decided to move their in-house RCS services over to Google Jibe, I'd guess for simplicity and economics. Many, many carriers don't preload Google Messages as their default, yet still offer RCS services. No one is forced. But China can certainly force whatever they wish, and they are. Apple has no say in the matter other than they could choose to leave China's smartphone market. 

The two situations are not comparable. At all.  

chasm said:

Apple has already made it clear that it will adopt RCS the moment the governing body (GMSA) accepts proposed changes for encryption and better security. This will be happening later this year, so thanks to Apple everyone on both platforms scores a win.

Google’s been using RCS for years and never once thought to make the GSMA add more security and encryption. One has to wonder why.

The only thing I wonder is why you never read the links you're given that would have saved you from another FUD post.

Google has tried for years to prod the GSMA, which is controlled by the carriers, to work with them on E2EE. You are almost certainly unaware that it was Google who gave GSMA the tools to finally make RCS a worldwide standard back in 2016. Still, carriers were not onboard with RCS default encryption (for obvious reasons), at least in the timeframe that Google wanted, which was "let's start work on it now."

So in 2019 Google announced they'd do so themselves, no more waiting.

Before you make statements, wouldn't it be a great idea to familiarize yourself with the topic? Here's links you've been given before but apparently refuse to read. https://www.gsma.com/newsroom/press-release/global-operators-google-and-the-gsma-align-behind-adoption-of-rcs/ https://www.theverge.com/2019/6/17/18681573/google-rcs-chat-android-texting-carriers-imessage-encryption

Everything you want to know about how fines are computed, and where the money goes:
https://competition-policy.ec.europa.eu/index/fines_en#:~:text=Fines imposed on undertakings found,following year are reduced accordingly.

davidw said:

gatorguy said:

So I've read an interesting perspective on Apple and RCS this morning, courtesy of Gruber and PED. 

While many here assume Apple's announcement of RCS coming to iMessage was in response to the EU's DMA, it might actually be due to China. Unlike European regulators who Apple feels free to argue with or if need be "maliciously comply", China is in the process of mandating RCS (without encryption for obvious reasons) despite Apple's preferences.They are a government that when they tell Apple to jump it's only a question of how high. There is no such thing as malicious compliance with China's mandates.

Without integrating RCS, Apple would be banned from China's smartphone market sometime later this year. It wasn't because of the EU if Gruber's sources are to be believed. Further, if those sources are correct I would not hold out hope for E2EE coming to the service with iMessage either even if it makes it into the standard. China requires source code be submitted for inspection in order to "ensure the security and privacy" of the algorithms used before that encryption method is permitted in the country.

It's not any government that will dictate whether Apple have to adopt RCS...

The proposed regulation requires new 5G devices to support RCS (locally called 5G messaging) to get certification. https://www.reddit.com/r/UniversalProfile/comments/153rrwl/chinas_proposed_regulation_could_force_apple_to/

So I've read an interesting perspective on Apple and RCS this morning, courtesy of Gruber and PED. 

While many here assume Apple's announcement of RCS coming to iMessage was in response to the EU's DMA, it might actually be due to China. Unlike European regulators who Apple feels free to argue with or if need be "maliciously comply", China is in the process of mandating RCS (without encryption for obvious reasons) despite Apple's preferences.They are a government that when they tell Apple to jump it's only a question of how high. There is no such thing as malicious compliance with China's mandates.

Without integrating RCS, Apple would be banned from China's smartphone market sometime later this year. It wasn't because of the EU if Gruber's sources are to be believed. Further, if those sources are correct I would not hold out hope for E2EE coming to the service with iMessage either even if it makes it into the standard. China requires source code be submitted for inspection in order to "ensure the security and privacy" of the algorithms used before that encryption method is permitted in the country.