Two of the most active Google users whom I know are in their mid-90s. They use Google Search and News. They use Gmail. I moved one of them from Windows to a Chrome OS Chromebox, and I recently showed the other how to use Google Docs as an alternative to paying Microsoft’s ransom for a full-blown version of Office on their new Windows 10 system. Frankly, they’re better versed at using their computers and Google services than some users I know who are less than half their ages.

I support these users — and many other persons that I also support informally among friends, family, and acquaintances, almost entirely via Google’s Chrome Remote Desktop (CRD) — I rarely if ever see various of these folks in person, and some live across the country from me. For the Chromebox and Chromebooks, CRD is the only viable remote sharing option that I know of. For Windows systems I consider CRD overall to be the easiest for talking a user through the initial installation over the phone, and then to use for the majority of associated purposes going forward.

In most respects, CRD is excellent. Data is encrypted, and in most circumstances the data connection is peer-to-peer without going through Google servers. In some configurations, system audio is sent along with the screen image.

But Chrome Remote Desktop also has a horrible, gaping accessibility problem — that has persisted and generated bug threads that in some instances now stretch back unresolved for years — that seriously limits its usefulness for those very users who could most benefit from its use.

And this flaw is unfortunately representative of a rapidly growing class of accessibility failures at Google — in terms of readability, user interface deficiencies, and other related problems — which have been spreading across their entire ecosystem to the dismay of myself and many other observers.

You’ll be hearing a lot more from me about Google accessibility problems — which in some cases may rise to the level of actual discrimination (though I don’t believe that discrimination is Google’s actual goal by any means) —  across their various products and services, but let’s get back to Chrome Remote Desktop for now.

I’ve written about this particular aspect of CRD before, but after spending a couple of hours yesterday battling it with a nonagenarian Google user, it’s time to revisit the topic.

CRD uses a completely reasonable system of credentials matching and/or access/PIN codes to provide session setup authentications. But CRD also imposes a “faux” security feature that ends up driving users crazy, making CRD much more difficult to use than it should be in many cases, and can actually result in reduced security as users seek workarounds.

There are two basic authentication mechanisms available for CRD. For non-Chrome OS versions, there is a choice between one-time access codes and “persistent” login credentials (the latter is really designed primarily for remote access to your own computers). For Chrome OS installations of CRD, only one-time access codes can be used as far as I know.

For most typical remote support situations, the one-time “share” access codes are the appropriate choice, since sharing of actual Google login credentials should be avoided of course (that’s not to say that this doesn’t sometimes become necessary when trying to help some users, but that’s a matter for a separate discussion).

And herein is the problem that has generated long threads of complaints — as I noted above some going back for years now — on the Chromium support forums, with users pleading for help and Google doing essentially nothing but occasionally popping in to make frankly lame excuses for the current situation.

Unlike in the shared credentials persistent connection model, when using the conventional one-time share codes in the typical manner to use CRD, the remote user is prompted every 10 minutes or so and must quickly respond to avoid having the connection terminated. There is no way to change this timeout. There is no way to disable it. And when trying to support a panicky or confused user remotely — irrespective of their age — this situation isn’t security — it’s a godawful mess.

Often users just want you to fix up their system remotely while they go do other things. Sitting there or running back every 10 minutes to refresh the timeout is a hassle for them at best, and can be extremely confusing as the associated prompts keep interrupting attempts to repair problems and/or explain to the remote user the details of their problems.

For some of the users even seeing those prompts is difficult, and as frustration grows over the continuing interruptions they often just want to give up or keep begging you to do something to stop the interruptions themselves — which is impossible, without asking them to share their credentials with you so that you can use persistent mode instead where that’s available.

And sometimes that’s what you end up having to do — violate proper security protocols by having them give you their Google credentials and switching to persistent mode where the interruptions won’t occur (keeping in mind that this apparently isn’t even an available option for Chrome OS — you’re stuck with the interruptions with no way out).

The upshot is clear — a feature that Google apparently thought was a security plus, easily becomes a massive security minus.

Now here’s the really sad part. From a technical standpoint, fixing this should be straightforward. The bug discussion threads — which as I’ve said have been largely ignored by Google — are replete with suggestions about this (including by yours truly).

If the view is that having a default connection timeout is security positive, at the very least provide a means for users to disable and/or change the duration of that timeout as they see fit, either permanently or on a per-connection basis. This could be implemented in a manner so that this could only be changed by the local user, not by the remote user.

But in the name of bits, bytes, and beer, don’t keep forcing everyone trying to use Chrome Remote Desktop to fight a wired-in 10 minute timeout that is incredibly disruptive to many users and in many support situations, and that drives users to using workaround methods that are detrimental to security!

Over on those bug threads, there’s considerable speculation about why Google refuses to fix this situation. The most likely reason in my opinion is that the Googlers in charge of CRD (which may not be a particularly desirable assignment) either don’t understand or just don’t care about the kinds of users for whom this situation is so disruptive. Perhaps they’ve never supported non-techie users, or older users, or users with special needs.

And unfortunately, we can sense this view across a wide sweep of Google products. A particular, young demographic appears to be the user group of overwhelming interest to Google, with everyone else increasingly left twisting slowly in the wind.

I view this as neglect, not actual malice — though the end result is much the same in either case.

Strictly from a dollars and cents standpoint, concentrating on your most desirable users can be viewed as at least being rather coldly logical, but users not in that demographic are just as dependent on Google as anyone else, and at Google scale represent vast numbers of actual human beings.

As I’ve said before, I fear that if Google does not seriously move now to solve their expanding accessibility problems (alternative user interfaces are one possible positive way forward) — in terms of readability, user interface designs, and other areas such as we see here with Chrome Remote Desktop — governments and courts are going to start moving in and dictating these aspects of Google operations.

Personally, I believe that this outcome would likely be a disaster both for Google users and Google itself. Government micromanagement of Google via the U.S. Americans with Disabilities Act — or heavy-handed directives from E.U. bureaucrats — are the last things that we need.

Yet this seems to be the direction in which we’re heading if Google doesn’t voluntary get off their proverbial butt and start seriously paying attention to these accessibility problems and the affected Google users.

I don’t doubt for an instant that Google can accomplish this if they choose to do so. I know of no firm on the planet with employees who are more skilled and ethical than Googlers.

But the clock is ticking.

–Lauren–