SMS verification code quality-of-life improvements

[vasi]

Problem statement

It's common for websites to do multi-factor authentication (MFA) using SMS (Wikipedia). This process has several steps:

1. You log in to the website (or application) on your computer
2. The website redirects to a form for verification
3. Either automatically or upon pressing a button, the website sends you an SMS
4. You receive an SMS message on your phone with a six-digit or seven-digit numeric "security code"
5. You find your phone, view the SMS message, and then type the code into your computer

I find this pretty unpleasant, for many reasons:

• There are many steps, so it's a pretty long delay to log in
• If my phone is not already on me, I have to find it
• Either I have to arrange my phone immediately next to my computer screen so I can see both at once, or I have to remember a random multi-digit code; and I often mis-remember or mis-type and have to repeat the process
• My SMS app is polluted with one-time-use messages that I don't really want to see later

Proposal

It ought to be possible to do something easier for the user. For example, Apple has a feature where an iPhone can forward messages to a Mac, which then will autofill the form in Safari.

GSConnect could get a new plugin that triggers on SMS messages that look like verification codes. Once detected, we could do various things--possibilities include:

1. Display a persistent PC notification with the code easily visible, so it's easier to type into the verification webpage
2. Copy the code to the computer's clipboard
3. Autofill the code directly into the verification webpage
4. Archive the SMS message, so it no longer appears in the messaging apps (PC or phone)

Implementation notes

Basic implementation strategies:

• Writing the basic plugin sounds fairly doable, it doesn't need any capabilities we don't already have in GSConnect: triggering on SMS, copying to the clipboard, displaying notifications. No extra device features should be necessary!
• Autofilling into webpages would require going through native messaging and the browser extension, as well as detecting the relevant forms in the verification webpage. There's some code used in an MIT-licensed browser extension that we could use for this.
• I don't know of any API for archiving messages, so that may not be possible

Some things to worry about:

• It may be difficult to detect what SMS messages actually count as "security codes", there's no common format. Probably anything containing the word "code" and a 6+ digit sequence (surrounded by spaces) would be a reasonable heuristic, which we could expand on over time.
  • We could add heuristics to distinguish between automatic-looking threads and human ones, by looking at things like length-of-messages and number-of-messages. But this could get confusing.
• We want to take care when copying codes to the clipboard, as some users may find it annoying to lose their previous clipboard contents. Perhaps making this a notification action and/or button is safest
  • Similarly, if a user is logging into multiple services, auto-fill may do the wrong thing. A notification button could be safer
• Arguably, the notification functionality could simply be a variant of the existing Notification plugin functionality. But it might be nice to allow users to enable this as a separate plugin, without getting constant phone notifications on their PC.
• We may want to be cognizant of SMS spam, we don't want to allow someone to mount a DoS attack on someone's clipboard! Maybe adding a rate-limit would be useful? GSConnect generally doesn't attempt any spam countermeasures though.

Security notes

This may sound scary from a security perspective! Isn't the entire point of SMS verification to make the user prove they have a second device?

But I don't think it's really a big deal. The Messaging app in GSConnect already makes it possible for a connected PC to access security codes as they come in, and the Notification plugin can already make these easily surfaced.

Metadata

GSConnect version

50

Installed from

GNOME Extensions website

GNOME Shell version

42.9

Linux distribution/release

Ubuntu 22.04

[vasi]

I doubt I'll attempt this right away, but happy to look into implementation in the next few months.

[ferdnyc]

I've actually been thinking about this for a while, for an unexpectedly silly reason: You have no idea how many times I've gotten an SMS notification with a code in it mirrored to my desktop, and clicked the "Copy '######'" action button on it expecting the value to be copied to my Linux clipboard. 🤣

And every time, a moment after I click that button, I realize how dumb that was. And then I start manually typing the code into whatever page generated the SMS, digit-by-digit. Like a CAVEMAN.

So I've long thought about a feature in GSConnect that could solve just that general "Copy buttons don't work when mirrored" issue. If GSConnect could recognize when a notification includes a "Copy" button, and automatically replace the remote-device (Android-side) copy action with a local action that copies to the Linux clipboard instead, problem solved!

Here are the two main sticking points that've stopped me from progressing with that idea: Internationalization and generalization.

It's a fairly simple prospect for me to implement recognition of the copy button in notifications that my SMS app generates.¹

It's not that hard to look for an action message that matches RegExp("Copy \"([0-9]*)\"") — or probably RegExp("Copy \"[a-zA-Z0-9]*\""), because some sites include letters in their codes — and to extract the code from that.

But the thing about that regular expression is, it's correct for copy notifications in my language, created by my SMS app. But other SMS apps may use a slightly different format. And for sure, the action string will be completely different for users who have their phone set to another language.

So in reality, for this feature to work, the matching regular expression probably has to be more flexible, or even be a list of several different expressions appropriate for different apps. (Not that hard, as GSConnect knows the source application for each notification — in fact, it already contains code to recognize notifications from various SMS apps, for other reasons.)

Then, once the code works for the variety of English-language apps, in order for that to work in other languages the regular expressions themselves need to be localizable strings that are first processed by gettext.

I don't really see any way that you could implement appropriate matching without making the expressions themselves translatable. This just isn't going to work:

const copy_msg = _('Copy');
const copy_re = new RegExp(`${copy_msg} "([a-zA-Z0-9]*)"`);

For starters, [a-zA-Z0-9] may not be appropriate for all locales (though it probably is, as sites don't tend to send localized codes). But the \" quoting around the matched value certainly won't be correct for all localized formats.

So the expression itself almost certainly has to be translated as a whole. And localization of RegExp() arguments is a much bigger responsibility to put on our translators than simply localizing display string values, and presumes technical knowledge that not all of them will possess.

It's also not conceptually the same activity as output localization, and requires a different skillset. When translators create localizations for output messages, the primary concern is that their translation convey the same meaning as the source string. But when translating a matching regular expression, the source string is completely irrelevant. The correct expression to match the copy-action string used by, say, WhatsApp in French, doesn't depend on the regular expression used in English. It depends entirely on how WhatsApp formats their message in French, which may not be a direct translation of the English format.

So, those issues were always what held me back from pursuing this further. I was confident I could make something that would work for me, but that's no good unless I'd be able to make it work for everyone.

But it would be awesome to have.

Notes

1. The feature would have to work off of the notifications, because SMS support in GSConnect is too broken to work off the SMS data itself. And working off the notifications is preferable anyway, because it leverages the fairly complex SMS scraping the Android SMS app is already doing. Rather not reinvent that wheel, and then have to deal with it accidentally picking up time indexes from my music player notifications and crap like that.

[ferdnyc]

For starters, [a-zA-Z0-9] may not be appropriate for all locales (though it probably is, as sites don't tend to send localized codes).

Well... now I'm second-guessing myself on that.

I was thinking primarily of locales that use the Latin alphabet in general — if you're in France and your bank sends you a 2-factor code, it may contain ASCII letters but I assume it wouldn't contain á or è.

But if you're in, say, Russia, do they exclusively use all-numeric codes? Or might someone get a code like 7И35ЛЯ? How about China, or Japan?

[ferdnyc]

I'm going to migrate this to Discussions, BTW, as that's a more appropriate venue for a conversation like this.

[vasi]

Thanks for your input! Some thoughts:

• Ooh do I ever like the idea of reusing the "Copy ..." button that Google already generates. It would be awesome to skip the full-SMS-parsing.
• It's a bit unfortunate that there's full-alphanumeric codes out there. I've only seen digits here in Canada! But that shouldn't matter, because of the below suggestion.
• For translation, I was thinking something a lot easier. We don't have to expose translators to the full, crazy power of regexes, just simple templates. Eg: if the French message would be Copiez «123456», then we can just have the translator write Copiez «%s» or Copiez «XXX» or some such. We don't really care whether the code has digits, alphanumeric characters, some whole other alphabet—as long as the template matches the button label, it seems reasonable to allow the desktop user to copy it.
• I'm not sure what I think about alternative SMS app support. As long as they're easy to support, eg: by adding another "Copy XXX" style template, it's probably fine? But it's quite possible that some apps have text like "Copy passcode" or "Copy OTP", where the button label doesn't contain the actual code, in which case we'd need a whole different strategy involving parsing the SMS. I'm pretty ok here with only supporting the easy cases (Google + others which can be templated), and ignoring others. Third-party SMS apps seem increasingly rare anyhow.
• I still would really like this to live in a plugin that's not the Notifications plugin, simply because that one is so noisy. Would you strongly object to me putting this in an auxiliary plugin? It could still be based on Android notifications of course, it just would be something users could enable/disable separately from all the other notification-sync functionality.

[ferdnyc]

Actually, the more I think about it the more I think this would have to live in the Notifications plugin, because it's already processing the incoming notifications, and it already contains the SMS notification recognition I mentioned, which this would just be another aspect of. And there's quite a bit of code already for handling that stuff:

gnome-shell-extension-gsconnect/src/service/plugins/notification.js

Lines 74 to 99 in 97a1287

	// A regex for our custom notificaiton ids
	const ID_REGEX = /^(fdo|gtk)\|([^|]+)\|(.*)$/;
	// A list of known SMS apps
	const SMS_APPS = [
	// Popular apps that don't contain the string 'sms'
	'com.android.messaging', // AOSP
	'com.google.android.apps.messaging', // Google Messages
	'com.textra', // Textra
	'xyz.klinker.messenger', // Pulse
	'com.calea.echo', // Mood Messenger
	'com.moez.QKSMS', // QKSMS
	'rpkandrodev.yaata', // YAATA
	'com.tencent.mm', // WeChat
	'com.viber.voip', // Viber
	'com.kakao.talk', // KakaoTalk
	'com.concentriclivers.mms.com.android.mms', // AOSP Clone
	'fr.slvn.mms', // AOSP Clone
	'com.promessage.message', //
	'com.htc.sense.mms', // HTC Messages
	// Known not to work with sms plugin
	'org.thoughtcrime.securesms', // Signal Private Messenger
	'com.samsung.android.messaging', // Samsung Messages
	];

gnome-shell-extension-gsconnect/src/service/plugins/notification.js

Lines 102 to 120 in 97a1287

	/**
	* Try to determine if an notification is from an SMS app
	*
	* @param {Core.Packet} packet - A `kdeconnect.notification`
	* @return {boolean} Whether the notification is from an SMS app
	*/
	function _isSmsNotification(packet) {
	const id = packet.body.id;
	if (id.includes('sms'))
	return true;
	for (let i = 0, len = SMS_APPS.length; i < len; i++) {
	if (id.includes(SMS_APPS[i]))
	return true;
	}
	return false;
	}

gnome-shell-extension-gsconnect/src/service/plugins/notification.js

Lines 554 to 563 in 97a1287

	// Special case for SMS notifications
	} else if (_isSmsNotification(packet)) {
	title = packet.body.title;
	body = packet.body.text;
	action = {
	name: 'replySms',
	parameter: new GLib.Variant('s', packet.body.title),
	};

As I said, I'm not opposed to it being a separate plugin philosophically, but I'm not sure that could work within GSConnect's architecture. If you were to find a way to do it and make it make sense, then color me impressed, and I'd certainly have no objections to merging such a plugin. But I suspect it's at least complicating the effort, if not actually impossible.

[ferdnyc]

 // A regex for our custom notificaiton ids 

*snrk* "notificaiton". All of the eslint scanning and other source checks on the repo, and we never did add a codespell scan.

[vasi]

On the Android side, KDE Connect has separate plugins for notification sending and receiving, with the send plugin ("Notification sync") having configuration options similar to GSConnect's

Omg, I had no idea these settings even existed. I even had to read the source code to figure out how to get to them!

Actually, the more I think about it the more I think this would have to live in the Notifications plugin, because it's already processing the incoming notifications, and it already contains the SMS notification recognition I mentioned, which this would just be another aspect of. And there's quite a bit of code already for handling that stuff:

Eh I mean it's not that difficult to pull out _isSmsNotification() into a common place? But it's true that it'd be annoying for the Notifications and (putative) Security Codes plugins to decide of the two should handle a security code notification. Hmm, I'll have to think about this.

[ferdnyc]

@vasi

Eh I mean it's not that difficult to pull out _isSmsNotification() into a common place? But it's true that it'd be annoying for the Notifications and (putative) Security Codes plugins to decide of the two should handle a security code notification.

Well, not even just that. Every plugin has to register the set of KDEConnect protocol messages it can both receive and generate. (incomingCapabilities and outgoingCapabilities, in the GSConnect plugin API.) Only plugins that support at least some of the message types the remote device reports it can send or receive will be activated, and within each of those plugins, only the actions that handle enabled message types will be available. (Individual D-Bus Actions within a plugin also register possible incoming and outgoing message types from the set of the plugin's incomingCapabilities or outgoingCapabilities, though few actions handle both and some use neither.)

On connect, each device sends the other end a packet listing all of its enabled message types in both directions, which in GSConnect's case are the sum of all incomingCapabilities or outgoingCapabilities for all enabled plugins.

I know that we don't currently have multiple plugins handling the same message types (I just checked to be sure), and I'm not entirely sure whether it's possible.

Even assuming it is, it will mean (if they're both activated) two plugins having to double-process all of the incoming kdeconnect.notification messages, picking out the ones they want to handle and trying not to stomp all over each other. Not necessarily impossible, but... well, like I said, potentially complicating things.

[ferdnyc]

Mm, nope. At the moment, the assumption is coded into GSConnect that there will only be one handler (plugin) for any given message type:

gnome-shell-extension-gsconnect/src/service/device.js

Lines 432 to 438 in 97a1287

	const handler = this._handlers.get(packet.type);
	if (handler !== undefined)
	handler.handlePacket(packet);
	else
	debug(`Unsupported packet type (${packet.type})`, this.name);
	} catch (e) {

[vasi]

Thist just got a lot harder since Android 15, see the relevant KDE Connect bug: https://bugs.kde.org/show_bug.cgi?id=495146

[ferdnyc]

Huh. Yeah, that'll throw a wrench in things.

It's interesting that the wiki documentation on the issue includes,

Disable Enhanced Notifications

In the notification settings, disable "Enhanced notifications" which will remove this restriction.

...But just that, full stop. No explanation of the consequences/tradeoffs of doing so. It seems like there must be some.

More interesting, actually, is that the OTP message content is apparently still accessible via KDE Connect's SMS permission; it's only the notification of the SMS that gets "censored".

I wonder if there's potential for KDE Connect itself to automatically extract and forward OTP strings directly from the SMS texts as they're received, using a new kdeconnect protocol message type? That would moot the whole parsing issue, we'd just have to support receiving this new message and displaying a notification to copy the data to the clipboard.

I can imagine they might be reluctant to do that, tho, for fear of Google freaking out that an app is explicitly collecting OTP texts and spiriting them off-device.