Table of Contents
Native URL support is one of RCS’s simplest yet most powerful features. It enables developers to effortlessly create sophisticated app experiences.
URLs can live discreetly behind buttons or cards, deep-link directly to websites, or trigger webhooks to servers without user interaction. They can also launch RCS chats from websites or link seamlessly between different chats.
With WebView, authenticated web sessions can even be embedded directly within the messaging app.
Compare this to traditional text messaging. URLs appear as raw text. Their usability depends entirely on Android or iOS. Whether you get a helpful preview or just a bare link is determined by your operating system.
Clicking the link usually forces an awkward transition out of the messaging app into your mobile browser. This creates a high-friction, high-stakes handoff. It feels like those cartoon moments when a character runs off a cliff, briefly scrambles in midair, and inevitably plunges downward.
Example 1: Frictionless Authentication
I’ve written at length about the frictionless authentication use case, specifically regarding two-factor authentication (2FA). Although the bulk of the work was done by Sonal Doshi, who holds patents in this area, and Radu Maierean, it’s worth revisiting briefly here because it clearly illustrates the power of URLs in RCS.
The solution, unveiled at MWC 2018 in Los Angeles, was elegantly simple:
- Users visited the ADP Workforce Now site and entered their passwords.
- Upon authentication, an RCS message was pushed directly to the users’ phones.
- The message prompted the users to tap, confirming their identities.
Underneath the branded, rich-media interface, authentication was accomplished through URLs passing securely between the device and the server. While users saw an engaging, visual message on their device, behind the scenes, it was simply URLs exchanged to verify identity—a straightforward concept but a powerful implementation.
Example 2: Payments and Multi-Agent Conversations
Universal Profile, the GSMA specification behind RCS, provides another powerful example with multi-agent conversations. Consider a payment scenario:
When you’re ready to make a purchase within an RCS chat, the initial agent hands the conversation off via a deep-link URL to a dedicated payments agent. That payments agent securely processes the transaction and then hands the conversation right back.
Even though multiple agents handle the interaction, the user experiences it seamlessly within the messaging app itself. URLs make the entire process frictionless and in-app. URLs FTW.
This experience is dramatically different from traditional authentication methods.
Today, users are forced into awkward text-message transactions, confirming purchases through replies, or worse, clicking URLs sent via SMS. Not only is this a terrible user experience, it’s also the single biggest source of spam and phishing attacks.
Because it’s acceptable to send URLs via SMS to process credit cards, users must personally verify each URL and phone number before deciding whether to trust them. This places an unfair security burden directly onto the user.
With RCS, this burden disappears completely. Users experience secure, frictionless interactions without needing to second-guess URLs or sender authenticity.
Example 3: WebView and the Embedded Web Experience
New in Universal Profile 2.7 is the support for WebView. For those who remember the evolution of the World Wide Web, this may feel like old news, but it’s new to the world of messaging. It brings the Applet-like experience to messaging. It solves the duplication of user experience problem prevalent with multi-channel interactions.
WebView allows for a rich, interactive experience by embedding web content directly into the conversation. Forms, product catalogs, and other web elements can be placed right inside the chat. Depending on the need, the experience can expand to full screen or use a more compact “tall mode.”
You can also use existing RCS features like suggested actions and payments. And this is an authenticated session, creating a sense of security and trust. But of course, in reality, it’s URLs (URIs if you want to be technically accurate) that are doing the heavy lifting.
Finally
URLs are dynamite. Their utility, flexibility, and ability to be overloaded far beyond their original design make them one of RCS’s most powerful features. But, like dynamite, in the wrong hands, they can cause untold damage.
Often, the simplest features are the most powerful. RCS’s native ability to commandeer the URL—both as a way to deliver information and drive interactions—is a perfect example.
We’ve already seen the harm that malicious URLs can do in traditional messaging—where a single misplaced character can make a fraudulent website look legitimate. With RCS, URLs are everywhere. That makes them even more powerful, but also something that needs to be handled with care.
The same feature that enables seamless interactions also increases the stakes. Getting security and authentication right isn’t just important—it’s necessary to maintain trust in the channel.