Heir to SMS finally excites carriers, by making Google grovel
Next-gen txt offers rich messaging services, should make it onto most 'Droids soon

ANALYSIS A couple of weeks ago, the world learned that Google's desire to gain more than a toehold in the world's messaging market had spawned a new "Chat" app.

The news left El Reg scratching its head because Google's new effort supports Rich Communication Services (RCS) – an effort that's spent years in that dullest of places: The Limbo of Half-Finished Standards.

Given that RCS has spent years in that nasty place we decided to figure out what it is and whether it matters.

As explained to The Register by David O'Byrne, a program director at GSMA, the mobile network operator industry lobby and standards group, RCS came about after carriers looked at the trajectory of SMS and the disappointment of MMS, then decided to take another shot at updating messaging standards.

It probably sounded like a great idea in, say, 2008. SMS bundling meant message volumes weren't matched by revenue, and over-the-top chat apps made it look like nobody would ever pay for a message again.

O’Byrne told The Register work on RCS started with carrier "tech types" more than eight years ago, and European carriers created an implementation profile in 2012.

That, however, turned out to be a problem: their JOYN offering, a simplified RCS profile, struggle to attract carriers or end users.

O'Byrne said that instead of promoting RCS adoption, JOYN became part of the problem – it helped foster fragmentation which resulted in Europe, the USA, and China all using slightly different implementation profiles.

Handset manufacturers were also unenthusiastic about the fragmented standard.

Without a built-in capability, RCS could not replicate the ubiquity of SMS, O'Byrne said.

Trying to drive adoption as a “viral application” was a huge risk: “For every WhatsApp, there are a thousand chat apps that failed,” he said.

Parked in a dead end 

RCS started to look like a dead end: handset manufacturers didn't like it, and there seemed to be no easy way to get users interested.

“In 2015 we went back to the handset manufacturers and the operators”, O'Byrne said, to decide on RCS's future.

Google was one of the dominant voices in the handset camp but had only a limited interest in RCS, because it had developed numerous chat apps of its own, in response to the perception that “messaging is nicer on the iPhone”.

A dialogue between GSMA and Google started a couple of years ago, O'Byrne said, and at the same time, the standards wonks “started to sketch out what we wanted to do differently”.

The aim – and the eventual result – was to craft a universal RCS profile that “got everybody together on the same page”.

With economies of scale on offer, handset manufacturers started to show interest – and that included Google.

Show us the money 

Operators, however, had reason to remain wary: SMS inclusions are so plentiful that the service is essentially free (which, it's worth noting, keeps volume healthy). Building a new messaging service would demand capex, and with so many free chat apps in the world there was no obvious route to profit.

Business messaging emerged as the secret sauce for RCS, in a world where SMS is an all-you-can-eat commodity, O'Byrne said.

Even while person-to-person SMS has declined, business messaging continued to grow, he said.

The GSMA decided that was “the tap with money in it”, O'Byrne explained. “People pay to get messages to their customers! Who knew?”

It wasn't just that RCS carries images and video that made it attractive to brands – it's also that unlike SMS, it's a session-oriented protocol.

If you're (for example) a Subway sandwich store, SMS offers little engagement: you send a message with an offer, and even though people have subscribed to get those offers, the outcome is hit-and-miss.

MMS offered its own examples of what could go wrong with a standard – like RCS, it suffered from fragmentation.

Most of the fragmentation was hidden from users. Travellers might notice that Australian carriers had different file size limits or timeout settings, but that's about all.

However, O'Byrne said, in implementing MMS, “there were hundreds of settings the operator had to set.”

Operators put up with that because they expected MMS to backfill the revenue SMS was shedding. MMS's performance probably helped feed carriers' wariness about RCS.

RCS is built on SIP (the Session Initiation Protocol that also underpins IP telephony services), and that makes it interactive. Users are accustomed to even minor things like “Richard is typing” in chat apps, and in a business setting, knowing the person at the other end of a tech-support communication is responding improves the user experience.

What attracted carriers to which GSMA demonstrated RCS, O'Byrne said, was the “tap rather than type” interaction. Rather than hoping a user would key in a text to reply to a promotion, the advertiser could send an RCS message with a button in it – a form of interaction already familiar to people using familiar OTT chat apps.

That simple change in model - a smart button instead of a passive message - meant much higher completion rates for brands using RCS as the promotional channel.

Subway in the US, Byrne told us, could get customers spending 15 per cent more with a successful SMS campaign. RCS would send completions up a further 30 per cent.

Other SIP-enabled features in the standard include “enriched calling” (allowing a caller to attach a message to the incoming call, whether it's “just calling to say Hi!” or “This is important” – we suppose brands will be too intelligent to misuse such a feature!); screen sharing between users; and calendaring integration.

 

Google joins in 

Suddenly, one-to-one operator-provided messaging had an opportunity again – and Google, which has seen native messaging in Android utterly dominated by OTT apps, decided to join the party.

Not because (as Gizmodo put it) Google is “quietly lobbying major carriers” to adopt it. It's the other way around, the carriers finally created something that got them in the door at Google.

There's also a Google server effort, and that's a big deal, because it will lessen the risk for rollout, particularly for smaller carriers.

And – get this, because it's important – Google's had to take an uncharacteristically low-key position. An Android phone will have an app called “Chat”, not “Google Chat”, even if it's Google's code – or, if it's a Samsung phone, Chat will talk to Chat servers, and won't be Google's code.

And the server? Google doesn't get to turn Chat users – or their Chats – into part of its vast data lake, because telcos live in a regulated world where one of the things you buy with a service is the relative privacy of your communications (yes, The Register know about wiretaps, but even those are regulated to a greater or lesser degree).

In a departure for Google, the hosted RCS service will be operator-branded, not Google branded, and RCS chats will be – gasp! – paid for, rather than being fed through advertisers' apparatus.

“Google were kind of bemused by that,” O'Byrne said.

In the pre-Cambridge Analytica era, he added, “Customers have been casual about what they're giving away”.

That left people at the mercy of “someone who is VC-backed and the master plan is that they do something with customer data somewhere down the line.”

In the Silicon Valley era, '“I will give you a service and you will give me money for it” … is a quaint and unusual notion' – but, just maybe, people are reconsidering the trade-off.

“I think customers are getting way more aware of who owns their data, who is doing what – I believe there is an opportunity to readdress the customers. We can say 'we charge you for the service', but you don't just get the call or message or Internet browsing, you also get security and privacy of the personal data, because that's what the regulators say you get.”

After what looked like a wasted effort, the GSMA feels optimistic again: “We've doubled the numbers of networks that have turned on RCS, doubled the monthly active users, there's a pipeline to double the active networks again, an we've carried about 20-25 trials around the world.” ®

Source:  The Register:  By Richard Chirgwin, 7 May 2018 at 12:02

The article is offered to provoke thought – It represents the views of the author; TUFF Ltd does not endorse it.


Things going well? OK, your   iPhone, iPad can be owned via  Wi-Fi sync

RSA 2018  The iTunes Wi-Fi sync feature in Apple's iOS can be potentially abused by cops, snoops, and hackers to remotely extract information from, and control, iPhones and iPads.

This is according to researchers at Symantec, who discovered that, once an iOS device trusts a physically connected computer, the device can, in certain circumstances, be accessed by miscreants sharing the same Wi-Fi network as the device and the computer.

Said miscreants can make backups of the iPhone or iPad's documents, extract screenshots, and even add and remove applications without the iThing owner's knowledge.

Speaking at the 2018 RSA Conference today in San Francisco, Symantec operating system research team leader Roy Iarchi and senior veep Adi Sharabani said it's all because the cryptographic keys generated for accessing devices via USB are also used when authenticating access via Wi-Fi.

Thus if an iThing trusts a computer, or some other terminal, hands over its keys, and those keys land in the hands of scumbags, they can be used to hijack the handheld or fondleslab over the shared wireless network. The iOS gadget must also have iTunes Wi-Fi sync enabled, which can be turned on via social engineering or some tricky app on the device.

It sounds like a bit of a long shot – but could be pretty useful for determined snoops, crime investigators, and so on.

Once an iOS device is plugged into a PC or Mac, and the user has opted to trust the machine, those aforementioned access credentials can be used via Wi-Fi to perform the same tasks possible if the device were connected with a USB-Lightning cable.

What's worse, said the eggheads, those credentials are permanently saved by the computer, meaning they can be used to get into the smartphone weeks or months after it was paired. An attacker could infect the PC – or just buy a used machine that wasn't wiped – and reuse those credentials on a targeted victim. Or an airport charger station could ask to be trusted when plugged in, and later pwn devices via shared Wi-Fi. Just your imagination.

Additionally, the duo noted, the technique could be paired with malicious profile attacks to route the device's network traffic via a VPN, and exploit the vulnerability when the device is not on the Wi-Fi network.

Iarchi said the issue was discovered by accident in 2017 when, while debugging several iOS devices for a different project, he noticed a strange set of logs showing up in his terminal window.

"The problem is those logs didn't collate to what I did on the devices," he explained. "It was the logs of another device of one of my team members that wasn't in the same room with me."

From there, Iarchi was able to determine that, with a bit of digging, he could use developer tools to access backups, stream screens, and covertly remove and install the apps on any iOS device that had previously been connected to his machine.

Symantec said it had notified Apple of the issue, and though iOS 11 now requires a passcode to trust a computer, the so-called "trustjacking" design flaw they found is still present and open to abuse.

Until Cupertino decides to permanently fix the problem, Iarchi and Sharabani recommend users take some basic steps to limit trusted machine access, including encrypting their backups and deleting their list of old trusted machines (this can be done via Settings> General> Reset> Reset Location and Privacy).

Developers can also help to protect their apps from data harvesting by not saving sensitive info to the device nor including it in backup data.

Source:  The Register:  Shaun Nichols 18 Apr 2018

The article is offered to provoke thought – It represents the views of the author; TUFF Ltd does not endorse it.

 

 

 

Additional information