Month: July 2017

Eleven and half or so years ago, a younger and more darkly bearded version of myself gave an invited talk at Google’s L.A. offices that I called “Internet & Empires” (https://www.youtube.com/watch?v=PGoSpmv9ZVc). Things were still pretty new there — I believe I was the first external speaker that they taped, and since there was no podium yet I presented the talk while sitting on the edge of a table (which actually turns out to work pretty well).

The talk had been scheduled well in advance, so it was a total coincidence that Google had earlier that day announced their (ultimately ill-fated) agreement with China to censor Chinese search results as demanded by the Chinese government.

I had already planned to talk about topics such as censorship and net neutrality. I even had managed to work in a somewhat pithy reference to the classic 1956 sci-fi film “Forbidden Planet” and the downfall of the Krell.

Back at the time of that talk, I was fairly critical of Google’s privacy and data management practices in some key respects. In ensuing years, Google evolved into a world-class champion for data privacy, user control over data, data transparency, and data portability. I’ve been honored to work with them and to put considerable thought into the complex ways that Google-related issues can be seen as proxies for critical policy issues affecting the entire Internet.

During the talk, I mentioned the newly announced China situation. I explained that while I understood the reasoning behind the decision to launch a censored version of Google Search for China (essentially, that some access to Google Search was better than none, and might help push China toward reforms), I suspected that this effort would end badly.

My main concern was based on history. Once authorities and governments start down the censorship path, they virtually always attempt to expand its reach, both in terms of content and geography. Government censorship is in many ways the classic example of the “camel’s nose under the tent” — you almost inevitably end up with a complete camel smashing everything inside.

And so it was with China and Google. China kept demanding more and more control, more and more censorship. Ultimately, Google reversed their decision, and wisely ceased participation in China’s vast censorship regime. Some other firms have not been as ethical as Google in this regard, and are still kowtowing to China’s censorship czars.

Fast forward to today. Depressingly, we find that in major respects the censorship and net neutrality issues that I discussed more than a decade earlier are in even worse shape now.

Dominant ISPs have been using dishonest political gamesmanship — often outright lies — to trample net neutrality, as if they weren’t already raking in the dough from often captive subscribers.

And in the censorship realm, the threats are more ominous than ever — not just from totalitarian countries like China or Russia, but from western countries as well — like Canada. Like France. And more broadly, from the European Union itself.

Today we’ve learned that Apple has reportedly surrendered to Chinese officials and has suddenly removed VPN apps from the Chinese users’ version of Apple’s App Store. These apps are crucial not only to the free speech of Chinese users but also in many situations to their physical safety in that dictatorial regime.

In some countries, a single Facebook post deemed to be critical of the local royal or elected despot — or other government officials — can trigger decades-long prison sentences.

And even in the so-called “enlightened” western environs of Canada, France, and the European Union more generally, domestic officials are attempting to impose global censorship over Google search results (via the horrific “Right To Be Forgotten” and other twisted means) — all in an effort to each become censors dictating what everyone else on this planet can see.

Success in such efforts would result in a lowest common denominator rush to the bottom, with politicians and other leaders around the world all attempting to cleanse search results of any materials that they find to be politically or otherwise personally offensive — or even simply inconvenient.

Unfortunately, all of this is very much in keeping with the predictions that I made in that Google talk years ago.

And here’s a new prediction. While Google will valiantly battle these oppressive forces in courts, in the long run the masters of censorship will continue to expand their choking grip on free speech globally, unless more drastic measures are deployed by free speech champions.

Imagine that you own a large store stocked with all manner of merchandise for a wide variety of customers. Now let’s say that you had some customers who insisted that they wanted to continue patronizing your store, but that they personally disapproved of various items that you stocked, and demanded that you remove them — even though those items were still very important to the vast majority of your other customers.

Most likely you’d tell the customers making those demands to either grow up — realize that they are not the only fish in the sea — or to take their business elsewhere. Period.

This is very much the kind of situation that Google and various other large Internet service firms are now facing. Users around the world demand access to the services that these firms provide, but increasingly their own governments are demanding to dictate not only what users in their own countries can access and see, but are also demanding the right to censor other users everywhere on Earth.

Here’s my admittedly drastic proposal to deal with these scenarios: Cut those countries off from the associated services. No more Facebook, no more Google Search or Gmail for them. No more cloud services. And so on.

Let these countries’ leaders deal directly with their citizens who would no longer have access to the global services on which they’ve come to depend for their business and personal communications, entertainment, and much more in their daily lives.

Tough love? You betcha. But this could end up being necessary.

If the would-be global censorship czars can’t behave like decent 21st century adults, with an understanding that they do not have the right to dictate planetary content controls, then let them build their own services in their own countries using their own money — but no longer would they be permitted to leverage our services to dictate terms to the rest of us.

Obviously, given the vast sums of money at stake, taking such a path would be a very difficult decision for these firms. But I would assert that permitting domestic governments veto power over your global services will be absolutely deadly in the long run, and that the time to stamp out this malignancy is now, before it spreads even more and has achieved a veneer of a new, repressive status quo.

In fact, the odds are that serious threats of service cutoffs would likely serve to cause some major rethinking in government circles, well before actual cutoffs would be necessary.

The Chinese “death by a thousand cuts” torture seems applicable here. Given escalating censorship trends, it’s difficult to postulate how to successfully fight this scourge through litigation alone in the long run. Meanwhile, individual censorship orders are likely to expand massively both in scope and number, eating away ever more of global free speech by increasing degrees each and every time.

While continuing to fight this trend in the courts is of course an appropriate primary tactic, I’m ever more convinced that the sorts of drastic actions outlined above — details to be determined — should be under consideration now, so that rapid deployment is possible if current censorship trends continue unabated.

It is indeed extremely unfortunate that we’ve reached the point where actions such as these must even be seriously contemplated, but that’s the reality that we now are facing.

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.

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:

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.

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)?

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.

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.