Google Introduces “Invisible” Gmail Messages!


A Google “Project Fi” user contacted me on Google+ this afternoon, expressing his extreme displeasure at a Gmail message (please see image below) that he received a week or so ago from that project. His comment: “I’m sure they’re trying to tell me something, but I can’t really read it.”

Not surprisingly, it’s in the dandy new Google low-contrast font style — oh so pretty and oh so useless to anyone with less than perfect vision.

Perhaps he saw my recent post “How Google Risks Court Actions Under the ADA (Americans with Disabilities Act)” — https://lauren.vortex.com/2017/06/26/how-google-risks-court-actions-under-the-ada-americans-with-disabilities-act — in any case he thought that I might be able to help with this overall accessibility issue.

Well, I’m willing to keep writing and talking about this until I’m Google blue, green, yellow, and red in the face — but so far, I’m not having much luck.

I’ll keep on tryin’ though!

–Lauren–

How Twitter Killed My Twitter Engagement by Killing Email Notifications

I don’t currently use Twitter all that much — it’s become loaded down with too much timeline content in which I’m utterly disinterested, and I’m far happier with ad-free Google+ (https://google.com/+laurenweinstein). But I do post on Twitter those items that I hope are interesting, nearly every day, via https://twitter.com/laurenweinstein.

I’m also more than happy to stay engaged with my Twitter followers. Lately though, a number of them have been emailing me and contacting me through other means, asking why I’ve been ignoring their replies and other routine Twitter-based interactions.

The reason is simple — Twitter doesn’t tell me about you any more. At least, not in a way that’s useful to me.

Until early this month, Twitter would send me a short, individual notification email message for mentions, replies, new follows, retweets, and likes. These were easy for me to scan using my available tools as part of my normal email workflow.

But now, Twitter no longer sends these individual notifications. Instead, once a day I receive an utterly useless “digest” from them, only providing me with the counts in each of those categories. No clue as to the contents. For example, the one I received today looks like this:

– 6 new followers – See them
> https://twitter.com/i/notifications
– 32 likes – See them
> https://twitter.com/i/notifications
– 3 replies – See them
> https://twitter.com/i/notifications
– 29 Retweets – See them
> https://twitter.com/i/notifications
– 5 mentions – See them
> https://twitter.com/i/notifications

A Twitter help page claims that this is to reduce my “email clutter.” It wasn’t clutter to me, it was how I stayed on top of my Twitter activities. 

Pretty clearly, this change was made to reduce Twitter’s email load, and to try drive users more frequently back to their site.

Frankly, I don’t have the time to keep running back to that one ridiculously long page on their site to plow through all of those notifications, which are stuffed in there like a Thanksgiving turkey. I presume this isn’t a big problem for folks who live on Twitter all day long, but it’s a total no-op for me.

So unless somebody knows of a way to get those individual email notifications back again (screen scraping apps, perhaps?) you can safely assume that your Twitter interactions with me will almost certainly be going into a black hole for now.

And that’s really a shame. Or to put it another way — shame on you, Twitter.

–Lauren–

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–

Another Google Accessibility Failure: Chrome Remote Desktop

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–

Comparing the Readability of Two Google Blogs

Let’s compare the readability of two Google blogs. On the right, a recent item from Google’s main blog, which has converted to Google’s new low readability design. On the left, a recent entry from the Google Security Blog, which is currently still using the traditional high-readability design.

The differences are obvious, and the low contrast on the right is especially bad for persons with aging vision (this degrading of vision typically begins around age 18, by the way). Both samples are at the same (default) zoom level.

Google is failing at accessibility in major ways, and this is just one example. For more discussion, please see: “Does Google Hate Old People?” – https://lauren.vortex.com/2017/02/06/does-google-hate-old-people and “How Google Risks Court Actions Under the ADA (Americans with Disabilities Act)” – https://lauren.vortex.com/2017/06/26/how-google-risks-court-actions-under-the-ada-americans-with-disabilities-act.

–Lauren–