lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] reaching gmail in basic html?


From: Mouse
Subject: Re: [Lynx-dev] reaching gmail in basic html?
Date: Mon, 11 Nov 2019 13:45:09 -0500 (EST)

> In October 2018, a senior staff member at google stated that since
> only crooks turned off JavaScript, Google was starting to use their
> own proprietary edition which among other things is supposed to
> detect the presence of adaptive technology for recaptcha,

That "senior staff member" either doesn't understand JavaScript or
hopes other people don't.

A proprietary version of JavaScript does not make sense unless the
producing entity - Google, in this case - controls both ends, here
meaning both the webserver side and the browser side.  See below.

> Additionally, when I first discovered that some Linux associated
> browsers, Links and Elinks, which can be compiled with a form of
> JavaScript, but which no longer work to log into gmail, I was told by
> Thomas, a member of Google's accessibility team, that these browsers
> did not use the "right kind" of JavaScript.

Again, Thomas either does not understand JavaScript or hopes you don't.
There is, in principle, no way for Google to tell whether the browser
is, say, Firefox, or something else pretending to be Firefox, not as
long as they're conforming to the JavaScript spec enough to
interoperate with implementations other than their own.

> Some of the articles I find speak of a more open source form of
> JavaScript, which some Linux developers use, but which now Google
> will not permit.

Google is not in a position to do that, unless they are going to deny
access to all Web browsers not built by Google - or at least not
running Google implementations of their language (which then isn't
really JavaScript any longer).

What Google is counting on here is that non-"approved" JavaScript
implementations are not actively trying to defeat whtaever
fingerprinting Google is doing.  It leads directly to an arms race
between Google trying to fingerprint implementations and
implementations trying to pretend.  The endgame would be something like
a browser running a Firefox instance in a sandbox and never displaying
the results directly, only presenting what it wants to to the user.
Lynx, even, could do that, if anyone wanted to bother putting in the
(significant) effort to make it do so.

> in short Google is defining JavaScript in such a way so as to allow
> only their tracking features to function so to speak.

Google is not in a position to redefine JavaScript - unless, as I said
above, they always control both ends, in which case they have no need
to use JavaScript at all and can just use something completely
unrelated and better tuned to their purposes.  This is because the
essence of JavaScript is that it's all about the webserver providing
code for the browser to run; JavaScript is a language for such code to
be written in.  For it to work at all, both ends have to agree on the
language, so one end unilaterally redefining it can't work.

As for accessibility in general, well, Google has only minor reason to
care about accessibility.  As a gmail user, you are not a Google
customer; you are part of Google's product (the customers are the
advertisers), and if the cost of supporting your continuing to be part
of Google's product exceeds the benefit - to Google, not to you - then
they have not only an incentive but a duty (to their shareholders) to
drop that support.

Unless you're actually paying Google for your mailbox and access, in
which case it depends on how much you're paying them and what the terms
of the contract are.  Based on just what I've read, though, I'd guess
that even in that case your having managed to get through to a real
person makes you a net money loser to them.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                address@hidden
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B



reply via email to

[Prev in Thread] Current Thread [Next in Thread]