Google Asked Me How I’d Fix Chrome Remote Desktop — Here’s How!

Since my posting a few days ago of “Another Google Accessibility Failure: Chrome Remote Desktop” — https://lauren.vortex.com/2017/07/21/google-accessibility-failure-crd — I’ve been contacted by a number of Googlers whom I know, asking me specifically how I’d address the accessibility problems that I noted therein. These queries were all friendly of course — not of the “put up or shut up” variety!

OK, I’ll bite. And Google can have this one for free — but like I’ve said before, this isn’t really rocket science.

Before I begin, I’ll answer another question that a number of readers have posed to me in response to that same post.

Why do I think that Google has so long ignored these sorts of problems with Chrome Remote Desktop (and various other of their products, for that matter)?

Without addressing Chrome Remote Desktop (CRD) or Google products specifically in this context, I’ll offer one possible explanation.

Around the information tech industry, it just isn’t usually considered to be career enhancing to be working on older software fixes and/or improvements, even when that application is fairly important and widely used.

By and large, most software engineers feel that rising on the career ladder is facilitated by working on new and “sexy” projects, not by being assigned to the “maintenance detail” — so to speak.

That’s a difficult corporate cultural problem, but a very important one to solve.

All right, let’s get back to Chrome Remote Desktop.

Here’s how I would fix the most glaring accessibility problem that I’ve noted regarding CRD operations — the damned “share mode ten minute timeout” (which, as I’ve noted in the referenced post above, actually can push users into terrible security practices when they attempt to work around the sorts of problems that the timeout causes — please see that previous post for details about this).

There are various somewhat complex ways to approach this issue — such as permitting the local user (the user who is sharing their screen with a remote user) to specify a desired timeout interval.

But the most straightforward and likely most useful approach for now in most cases would be to permit the local user to simply disable that timeout at the start of individual sessions, for the duration of those sessions.

Currently, when a local user provides a one-time CRD access code to a remote user, and the remote user attempts to connect using that code, the local user is presented with a dialogue box (which varies a bit across operating system platforms) that typically looks like this:

Obviously, only the local user can interact with this dialogue. They click “Share” if they wish to accept the connection.

And this is the obvious location to place a “session timeout disable” flag, as emphasized in my quickie demo mock-up here:

It’s that simple — and that logical. This checkbox (which defaults to timeouts enabled) only applies to the current session. The usual ten minute timeout is automatically restored for the next session.

– – –

Addendum: As suggested in the first comment on this post today, it would be reasonable to also provide this same timeout disable option in the actual ten minute timeout popup dialogue boxes themselves, so that even if the local user did not disable timeouts at the start of a session, they’d be able to later disable them for the remainder of the session if they so chose.

– – –

We probably should remind the local user that they’ve disabled timeouts for a session. There are logical places to do this, too.

CRD already provides a warning to local users that they’ve shared their desktop. For example, in Chrome OS (e.g. Chromebooks), a dialogue box like this is used:

An information notification is also popped up for the user with the same information in the Chrome OS notification area.

The CRD implementations for other OSes behave similarly. Windows systems provide a “currently sharing” dialogue box similar to the above, and also display a “floating” notification:

For all of these info notifications when timeouts have been disabled, it would be straightforward to add within them a text “warning” such as:

Timeouts have been disabled for this session.

If we’re feeling particularly paranoid about this — even given all of the other security elements that have already been satisfied to get the sharing connection open in the first place — we might want to add some sort of new warning box that can’t be covered, minimized, or moved by remote users, providing the same reminder that timeouts have been disabled.

That’s pretty much the whole enchilada. This paradigm should not be difficult to implement, and from security, usability, and accessibility standpoints overall it’s definitely a big plus for Chrome Remote Desktop users.

OK, Google — the ball’s back in your court!

–Lauren–