Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘internet

The misadventures of a prospective traveler

leave a comment »

Three issues that have collaborated to drive me nuts today:

  1. I had promised my father and step-father to try to come to Sweden over Christmas or New Year’s.

    For this purpose, I had already made several attempts to find suitable tickets with the Tor Browser (relayed through Tor or directly over my non-torified Internet connection, even with JavaScript enabled). This had proved very annoying and unproductive. For instance: The Lufthansa site simply does not load at all, it just hangs with a perpetually waiting tab. The SAS site loads, appears to work, allows me to fill in all criteria—and then does nothing when I try to submit the search. Ditto EuroWings. A meta-search that I attempted to use was hopelessly slow, insisted on (with every single search) re-including flights with a change of planes,* and also insisted on re-ex(!)cluding potentially cheaper late-night** flights. At least one site interrupted my search by having a JavaScript pop-up demand that I take a survey to improve its usability…*** Almost invariably, these sites had various annoying blend-ins/-outs, animations, overly large images, poorly structured pages, …

    *Which roughly doubles the travel time between Düsseldorf and Stockholm (that have the most suitable airports) and is highly unwanted by me.

    **A smaller negative than changing flights…

    ***First tip: Do not molest customers with such pop-ups!

    Having given up and postponed the search twice already, and now having the 28th of December, I decided to install a brand-new vanilla Firefox, in the hope that at least the SAS/EuroWings problems would be explained by some version incompatibility with either the Tor Browser (as a Firefox derivative) or my version being too low.*

    *Many web-sites, in the year 2018!, still fail to make browser-agnostic implementations, insist on very recent versions of browsers, and similar—usually with no indication to the user that they do. (And visiting an eCommerce web-site without JavaScript on is more-or-less bound to fail.)

    First attempt, SAS: Everything seemed to work, but the web-site was now even more visually annoying than before. The choosing of dates, for some reason, worked in a different manner than before and was highly counter-intuitive. Seeing that there also (not entirely unsurprisingly) were no good flights prior to the New Year and that prices were unnecessarily high, I decided to look elsewhere first.

    Second attempt, Lufthansa: Still did not load…

    Third attempt, EuroWings: To my great and positive surprise, everything appeared to work perfectly, showing me timely and much-cheaper-than-SAS flights. Things kept working as I began my purchase, entering name, address, and whatnot—and I even found the alternative to pay by invoice!* Alas: As I tried to confirm the last step, I was met with an uninformative error message and the request to start again from the very beginning. There was, in particular, no mention of factors like the last few seats on that flight having been suddenly snatched by someone else, or invoice payment not being possible on so short notice**. Before starting over from the beginning, I gave just the last page a second try. I re-entered some (inexplicably deleted) information and re-submitted. Same error message—but now followed by an intrusive pop-up suggesting that I start a chat with someone… I clicked the dismiss button—but, instead of disappearing, the pop-up did a weird and time-consuming animation and kept blocking a significant part of the page even after the animation was finished. At this point, I had had enough, closed my browser, and decided to find other means—which will likely amount to going to a physical travel agency and visiting at some point after the New Year…

    *Thereby removing one of my last doubts, namely the risk that I would be forced to pay with a combination of credit card and 3D-secure—which I (a) have never attempted with my new bank, (b) fear would involve the idiotic use of SMS (I do not currently have a cell provider), (c) had found to simply not work at all with my previous bank (the to-be-avoided Norisbank).

    **For which I would have had some sympathies–but, in that case, invoice payment should never have been offered in the first place.

    These events are the more annoying, seeing that there actually was a time when it was reasonably easy to handle tasks like these over the Internet—it really is not that hard to implement a decent search–choose–pay UI. However, year for year, the usability of various Internet shops and whatnots grows worse and worse, and appears to make more and more specific demands on the browsers. Much of this goes back to the obsession with Ajax. Credit-card payments are also not what they used to be, being much more laborious and likely to fail than in the days before 3D-secure and similar technologies. Worse, from the customers point of view, they likely lead to a net loss of security, whereas the stores and involved payment entities see the gains.* Then, if not relevant above, we have the inexcusably poor efforts of various delivery services, notably DHL, which often make it less of a fuzz to go to a store and pick up a purchase in person…

    *For the customer, the risk that someone will manage to fake a payment is reduced, but if someone does, he has very few options to prove that he was the victim of fraud. Without 3D-secure, the burden of proof was on the other party, and the customer had very little risk at all (short of additional work). The merchants and credit-card acquirers, on the other hand, can have large costs and losses when a fraudulent purchase is followed by a charge-back—and 3D-secure helps them, not the customer, by reducing this risk.

  2. Installing and setting up Firefox proved to be a PITA. Apart from the issues of the next item, I note that any version of Firefox has tended to come with very poor default settings, including default UI behavior; and that the “new” Firefox is highly reduced compared to the “old”.* After installation and prior to my attempts at finding tickets, I spent at least five minutes going through and correcting settings—that were then, obviously, only even valid for that one user account**…

    *The changes would be enough for a long own text. For now, I will just note that (a) that the GUI-configurable settings have been reduced to a fraction of their previous scope, (b) the general attitude described in e.g. [1] is continued.

    **I have a number of user accounts for different purposes, in order to reduce the risk of and damage from security breaches and whatnots. This includes separate accounts for eCommerce (the current), my professional activities, ordinary surfing, porn surfing, and WordPress.

    To boot, a new dependency was installed: libstartup-notification0. I did some brief searching as to what this is, and it appears to be just a way for an application to change the shape of the cursor during startup… (Beware that my information might be complete.) Firstly, why would I want the cursor to change?!? Secondly, even if this was seen as beneficial, it certainly is not reason enough to add yet another dependency—there already are too many useless dependencies, many of them recursive (also see portions of a text linked below).

  3. The idiotic Debian “alternatives” systems and the “desktop nonsense”.

    Disclaimer: Some familiarity with Debian or similar systems might be needed in order to understand the below.

    When a Debian user installs an application, e.g. Firefox, /usr/bin/firefox (or whatever applies) does not contain the Firefox binary—nor even a link to the Firefox binary. Instead, it links to an entry in /etc/applications, which in turn links to the actual binary (unless a certain setup has even more indirections involved). To boot, this system is administered by a poorly thought-through tool (update-alternatives) and/or configuration; to boot, it is vulnerable to applications arbitrarily overriding the status quo, as well as adding pseudo-applications (e.g. x-www-browser) that at least I simply do not want polluting my system.

    In fact, these pseudo-applications are likely the reason why this system was added in the first place—because e.g. x-www-browser can be “provided” by a thousand-and-one different real applications, it would be highly complicated to work with straight links, let alone binaries (especially when one of the “providers” is removed). For real applications, there is a much better way to solve such problems—namely, to just link e.g. /usr/bin/firefox directly to the usually sole instance of Firefox present and give the user an explicit choice of the “default” Firefox every time a new Firefox version was installed or an old removed.

    Why do I not want these pseudo-applications? Firstly, they bring me and most reasonable users, at best, a very minor benefit (for which they bring the cost of the indirections and the greater effort needed when looking for something). Secondly, the “providers” are usually sufficiently different that unexpected effects can occur.* Thirdly, they are often used by other applications in a manner that is highly unwanted: For instance, one of the alleged main benefits of x-www-browser is that any other application, e.g. an email reader, should have an easy way to open an HTML document, without having to bother to check what browsers are installed—but I absolutely, positively, and categorically do not want my email reader to even try this. In a saner world, this would be something configurable in the email reader (and only there), and those who want this endangerment can configure it, while those who do not want it simply do not configure it. By having x-www-browser, the user no longer has such control. Worse: Since the real application behind x-www-browser can change without his doing (be it due to presumptuous applications or an administrator with different preferences), the effects can be very, very different from the expected—e.g. that a known browser with JavaScript, images, and Internet access disabled (appropriate for reading e.g. HTML emails) is replaced with an unknown browser with everything enabled. (Which, in combination with email, could lead to e.g. a security intrusion, leaking of data to a hostile party, activation of unethical tracking mechanisms of who-read-an-email-when, and similar.)

    *For instance, there are many highly specific tool families, e.g. awk, whose members will superficially appear to be and behave identically (much unlike e.g. Firefox and Chrome/Chromium, as x-www-browser candidates), but will have subtle differences that can lead to a failed execution or a different-than-expected result in certain circumstances. Such problems, especially when undetected, can have very serious consequences. It is then much better for the user to, depending on circumstances, pick the specific awk-version he needs by explicit call (=> the alternatives system is not needed), make sure (for a one-user system) that he only ever has one instance installed and use the generic “awk”-name (=> the alternatives system is not needed), or restrict himself to only the common base of identical features. In the last case, the alternatives system would have some justification—however, it would place a very high burden on the user in terms of not making mistakes, might still fail due to undocumented differences or bugs, and is vulnerable to other differences, e.g. regarding performance. Obviously, this would also reduce the available capabilities of the tool in question—in many cases, quite severely.

    Similar remarks concern the “desktop nonsense” (which would deserve a long text of its own; a partial treatment is present). In this particular case, there are at least two* further mechanisms (/usr/share/applications, /usr/lib/mime/packages/) that cause similar problems, including allowing e.g. email readers to launch things that they should not launch. I have used the tool chattr to forbid additions to these two directories; however, due to the incompetence of the apt implementers and/or package builders, this is only a partial help: Despite these entries being unimportant for the actual functioning of the system/the installed application, the chattr-setting leads to a hard error from the apt-tools. I know have to “de-chattr” the directories, re-attempt the install, manually delete the added files, and “re-chattr” the directories … Effectively, I do not prevent the directories from being polluted—instead I trade an increased work-load for the benefit of knowing when I have to manually clean them up after pollution.

    *Proof-reading, I suspect that /usr/lib/mime/packages is not strictly desktop related, and might better have been treated as a third area. In the big picture, this does not matter. (And I do not have the energy to sort out “what is what” at the moment.)

Advertisements

Written by michaeleriksson

December 28, 2018 at 6:43 pm

Search-engines missing the point

with 2 comments

Search mechanisms on the Internet are another ([1], [2]) common source of “missing the point”, be they global search-engines or site-internal:

When a user searches, it is not to find hits—but to find relevant hits. However, most* search-engines, etc., appear to focus on maximizing the number of hits and to consider relevance a secondary criterion—often combined with an attitude of “we know better than the user what he wanted to search for”.

*In my experiences over the last few years: I have, obviously, only used a minority of the world”s searches (and avoid Google for reasons of privacy) and things were a bit better in the past.

Wikipedia is a good example: Almost every time I search for something obscure, I am met with a message of “Showing results for [less obscure word]. Search instead for [original search word].”—utterly unacceptable! If I search for X, Wikipedia should non-negotiably show the results for X. The first assumption should always be that the user knows what he wants. If there is reason to expect a mistake, e.g. if someone searches for “reciever”, then it is acceptable, often beneficial, to also make a suggestion “Did you want to search for ‘receiver’?”—but the hits for “reciever” should be shown by default. Presuming to override the search punishes those who actually know what they do and do so correctly, while assisting those who do not…* (However, in the specific example used, some room for display of both can be available as per excursion below. In many or most other cases this is not so, because the actual word used is correctly spelled, but just happens to not have an article on Wikipedia.)

*I stress that I do not claim perfection in this regard: I often make mistakes that involve turning two letters around, hitting return before typing the last latter, and similar. However, I have no objections to paying the price of a second search when I actually have made a mistake—having to pay that price when I did not make one, that is what annoys me.

My current main search-tool, duckduckgo*, is truly horrible in this regard. It does normally show hits for what I searched for, but very often in a form so diluted as to make the results useless. This includes an ever recurring “Not many results contain [specific search term]. Search only for [the original search terms]?”, which amounts to “if this specific search term is included, we do not find many hits, so we have chosen to consider it secondary”. However, the terms falling victim to this are usually those that I very, very deliberately included in order to ensure that the relevance of the hits was high enough! In effect, the better my original choice of terms, the stronger they filter, the more valuable they would have made the resulting hits—the less likely they are to be taken at face-value by duckduckgo. Even a single relevant hit is better than a hundred irrelevant hits! This misbehavior is especially annoying when the space of potential hits has to be reduced by several types of criteria, each essential for the hits to be relevant.**

*A good choice in terms of claimed philosophy with regard to e.g. anonymity, and often the default with e.g. the Tor Browser. However, due to the poor search results, I will almost certainly look for a replacement in the near future. Notably, duckduckgo is yet another tool that has grown worse over time. This lately includes ever more “paid hits”.

**Consider e.g. searching for information on installing a certain piece of software, which requires at least three types of information: (1) Installation instructions are different for different platforms, implying that the platform is needed, preferably fairly specifically. Even with Linux there are often differences from distribution to distribution, and the instructions for Windows or MacOS are highly unlikely to be helpful. (2) These instructions are different for different pieces of software, implying that the current software is needed. (3) The fact that an installation is concerned (and not e.g. general product information or information on trouble-shooting a run-time problem) is needed…

However, even when this dreaded message does not appear, the actual use of the search terms appears to be fairly arbitrary and hits are very often of low quality. This to the point that I suspect that duckduckgo internally uses an “or”* search and then delivers the hits based on some ranking** where “and”*** is just a secondary criterion. The result is that I often have to repeatedly manipulate my query using additional instructions,**** which can waste quite a lot of time and be very frustrating, when it occurs repeatedly in a short span of time. It is far better to be honest, deliver the few relevant hits, and suggest a less stringent search, than to pretend that an ocean of relevant hits were found—but which actually are an ocean of irrelevant hits.

*A query like “a b c” should obviously per default be interpreted as “give me hits that match ‘a’ and ‘b’ and ‘c’ and nothing else”—not as “give me hits that match ‘a’ or ‘b’ or ‘c’ or otherwise only partially match my criteria”. The key to good searches is cutting out the irrelevant, not grabbing anything even remotely plausible looking. (The one case for “or”, as a default, that once could have been made, is long outdated. Cf. excursion.)

**Using a ranking is not a problem, but could even be seen as a necessity. (Another problem with Wikipedia is the weak or absent ranking of hits.) However, this ranking must have relevance as the most important criterion. If this is ignored in favor of criteria like popularity, a very popular page that deals extensively with “a” (but not “b” and “c”) might be ranked over an unpopular page that actually deals with all three.

***More strictly speaking, the textual relevance for the search terms.

****Specifically, the use of “+” to force the use of a given search term and quotation marks to ensure that a certain term is taken literally, e.g. “a “b” c” (but see excursion below).

Excursion on synonyms and similar:
An acceptable, normally highly beneficial, exception to the use of the user”s literal query is the application of synonyms and similar fuzziness. For instance, if a search for “horse” does not include pages that use “horses”, “equine[s]”, and whatnot (but fail to use “horse”), there would be a considerable additional burden on the user, including the need for repeated searches or searches that make heavy use of “or” instructions. In the minority of cases where the specific, literal, search-term is required, the user still has the option of being explicit* about this. Some degree of such fuzziness has been a quasi-standard since the late 1990s or the early 2000s.

*Typically, through the use of “””.

However, even this can be taken too far. For instance, I recall once searching for information on User-Mode Linux: Knowing that using the typical abbreviation, “UML”, might give me many irrelevant hits on Unified Modeling Language, I very, very deliberately spelled the phrase out—and found hits dominated by … Unified Modeling Language! Apparently, the search-engine had reasoned that “Hmm, ‘User-Mode Linux’ is the same as ‘UML’, ‘UML’ is the same as ‘Unified Modeling Language’; ergo, I should show hits for ‘Unified Modeling Language’!”, despite the two having nothing to do with each other.

A particular problem with too much fuzziness is that countering it with a literal search will be an all-or-nothing deal (for the search-term in question): For instance, if an over-eager search-engine includes results for “address Doctor John Smith” for the search “address Professor John Smith”, this can be corrected by searching for “address “Professor John Smith””. However, this will also exclude references to “Pr. John Smith” and “Prof. John Smith”. Here, the attempt to combat too much fuzziness requires throwing the baby out with the bath water.

Remark on quotes:
Note that there are three types of quotes used in this text, regular double (“/”), regular single (‘/’), and the-ones-on-the-keyboard (“/”).

Written by michaeleriksson

September 29, 2018 at 12:03 pm

Tor Browser missing the point

with one comment

I have written before of browser makers having the wrong attitude (recently, Pale Moon; Firefox repeatedly, e.g. [1]) and of people missing the point to such a degree that what they do borders on the pointless.

Unfortunately, the Tor Browser is another case, brought to my mind by a recent “user agent”* issue (cf. below).

*Strictly speaking, “user-agent header”. For simplicity, I will use just “user agent” below.

The Tor Browser is a modified Firefox browser that allows surfing through the anonymisation/privacy/whatnot network Tor, while attempting to remove weaknesses in Firefox that could defeat the use of Tor. On some levels, the developers take a very strict approach, e.g. in that they advice against using Tor with another browser. On others they are paradoxically negligent.

Consider the following claim from the current version of the Tor FAQ:

Why is NoScript configured to allow JavaScript by default in Tor Browser? Isn’t that unsafe?

We configure NoScript to allow JavaScript by default in Tor Browser because many websites will not work with JavaScript disabled. Most users would give up on Tor entirely if a website they want to use requires JavaScript, because they would not know how to allow a website to use JavaScript (or that enabling JavaScript might make a website work).

This, however, makes both the use of Tor with the Tor Browser and the many alterations of the Tor Browser pointless… Allowing JavaScript is not just “unsafe”—it is a complete and utter disaster, defeating the purpose of Tor entirely! Indeed, I am very, very careful about allowing JavaScript even when not using Tor, because JavaScript does not only allow a circumvention of anonymity protection (which is not a concern in a more “vanilla” situation)—it also very severely increases the risk malware infections and whatnots. (To which can be added complications like more intrusive advertising, redundant and annoying animations of other kinds, and similar.) It would be better to use Firefox (over Tor) with JavaScript off than to use the Tor Browser with JavaScript on!

The we-do-not-want-to-scare-away-beginners argument normally carries some* weight; however, here it does not, because the damage done is so massive. This is like a word-processing program that does not allow the user to enter text… I would also argue that because someone is a beginner, it is more important to give him safe defaults—I know the dangers of JavaScript; most beginners do not. These beginners might then surf away as they like, in a false sense of security, and potentially find themselves in jail after insulting the local dictator…

*But only some: To a large part, it is a fallacy, because it so often involves insisting on behavior that benefits the beginners for two days and either harms the more experienced users for years or forces them to invest considerable time in searching for settings/plugins/whatnot to make the behavior more sane. Indeed, in many cases, the result is a background behavior of which most users will not even be aware, despite being harmed by it. (Consider e.g. “accessibility services” that run up processor time, increase the attack surface for hostile entities, make the OS sluggish, …, without ever being used by the vast majority of users.)

A much better solution would be to keep JavaScript off by default and give beginners sufficient information that they can judge why things might not work and when it might or might not be a good idea to activate JavaScript.* Indeed, the nature of anonymity on the Internet is such that Tor is of little benefit unless the user has received some education on the traps and problems.

*In most cases, the answer is “never”: The security loss will always potentially be there, even a trusted website can be abused by third-parties, and most sites that require JavaScript to function properly, at some point, require a de-anonymizing log-in or registration, e.g. to complete a purchase. With the rare exceptions, I would recommend using an entirely different Tor Browser instance.

The text continues:

There’s a tradeoff here. On the one hand, we should leave JavaScript enabled by default so websites work the way users expect. On the other hand, we should disable JavaScript by default to better protect against browser vulnerabilities ( not just a theoretical concern!). But there’s a third issue: websites can easily determine whether you have allowed JavaScript for them, and if you disable JavaScript by default but then allow a few websites to run scripts (the way most people use NoScript), then your choice of whitelisted websites acts as a sort of cookie that makes you recognizable (and distinguishable), thus harming your anonymity.

Apart from understating the risks of JavaScript, this argument hinges on an easily avoidable use of NoScript. (Cf. footnote above.) This use is the normal case when using a vanilla Firefox, but it is only a convenience, it is not a good idea with the Tor Browser, and it is not acceptable to let the uninformed dictate behavior for the informed. Better then to inform them! In a pinch, it would be better to not include NoScript at all,* point to the possibility of using several browser instances (with or without JavaScript on), and let those who really, really want NoScript install it manually.

*With some reservations for secondary functionalities of NoScript, which is not just a fine-grained JavaScript on/off tool. Then again, these secondary functionalities could in some cases also help with de-anonymization through making the browser behave a little differently from others and thereby allowing some degree of finger-printing.

The same type of flawed thinking is demonstrated in a recent change to the user agent: Historically, this identifier of the browser, OS, and whatnot has had the same default for all Tor Browsers (with occasional updates as the version changed), in order to make it harder to de-anonymize and profile individual users. With the recent release of version 8.0*, this had** changed and at least the OS was leaked. The implication was that e.g. a Linux users could be pinpointed as such—and because of their smaller proportion of the overall users, their anonymity was turned into a fraction*** of what it was before.

*Based on Firefox 60.x, incorporating the extreme overhaul of Firefox hitherto kept back. I am not enthusiastic about the changes.

**The developers have recanted in face of protests—a welcome difference to the way the Firefox developers behave.

***In some sense: Consider a game of “twenty questions”, where the “questioneer” is told in advance that a mineral is searched for… Not only does such information prematurely cut the average search space in three (mineral, plant, animal resp. Linux, MacOS, Windows), but due to the smaller size of the mineral kingdom resp. set of Linux users, the specific current search space is made far smaller.

The justification for this appears to be a fear that websites would (as per the old default) hand out Windows content to Linux users, causing sites to not work. While this is not as bad as the JavaScript issue, it is bad enough, especially since this change was not clearly communicated to the users.

Again, the reasoning behind the change is also faulty: Firstly, the influence of the OS is fairly small and any site that relies on OS information is flawed. Secondly, the opposite problem is quite likely, that a website sees “Linux” and decides “I have nothing tailor-made for Linux. What if the display is not pixel perfect?!? Better to just show an error message!”, even though the site would have worked, had the Windows version been delivered. Combined, these two factors imply that the change likely did more harm than good even for functionality…

A specific argument in favor of the change was that it made little sense to spoof the user agent, because this information could still be deduced by other means. However, almost all these other means require JavaScript to be active—and no reasonable user of the Tor Browser should have JavaScript active (cf. above)! For those who, sensibly, have deactivated JavaScript, the user agent is now an entirely unnecessary leak. To boot, there are situations, notably automatic logging of HTTP-requests, that have access to the user agent, but not to other values (or only with undue additional effort). Looking at such a log, an after-the-fact evaluation can show that a Linux (and Tor Browser) user from IP X visited a certain North-Korean site at 23:02 on a certain day, while the JavaScript based evaluation has to take place in real-time or not at all. Possibly, the logs of another North-Korean site shows that a Linux user from the same IP visited that site at 23:05. It need not be the same user, but compared to a (real or spoofed) Windows user in the same constellation, the chance is much, much larger.*

*Among many other scenarios. Consider e.g. a certain page on a site which is visited by a Linux user somewhere between 23:00 and 23:30 everyday—had he been a Windows users, no one might even have noticed a pattern. Or consider a user visiting one page of a site with one IP at 23:02 and another page with another IP at 23:03—now the risk that the user is recognized as the same is that much larger. Such scenarios obviously become the more serious when other information is added from the “regular” twenty questions. (And while they might seem trivial when applied to e.g. me or the typical reader, they can be very far from trivial in more sensitive situations, e.g. that of a North-Korean fighting for democracy or of someone like Assange.)

Excursion on user agent, etc.:
The situation is the more idiotic, seeing that there are* very, very few cases where e.g. the browser or the OS of the user is of legitimate interest to the website. Apart from statistics** and similar, the main use is to deliver different contents, which is just a sign that the web developers are incompetent—with very, very few exceptions, this should never be needed. If in doubt, it is virtually always better to make a specific capability check*** than to check for e.g. specific browser. Writing websites that look good/function in all the major browsers, on all the major platforms, and even simultaneously in “desktop” and “mobile” versions****using the same contents is not that hard—and doing so ensures that the website is highly likely to do quite well in more obscure cases too.

*Today: In the past, this was not always so, with comparatively weak and highly non-standardized browser capabilities. I think back on my experiences with JavaScript and CSS in the late 1990s with horror.

**And what legitimate reasons do websites have to gather statistics on user agents? The answer is almost always “none”. The main reason that is even semi-justifiable is to optimize the website based on (mostly) the browser, and (cf. above) this is almost always a sign of a fundamentally flawed approach—and the solution is to write more generic pages, not to gather statistics. (In contrast, statistics like how many users visit at what hour or from what country can be of very legitimate interest. A partial exception to the above are major technological upheavals like the switch to HTML 5, but these are likely better handled by more central and generic statistics—or, again, specific capability checks.)

***For a trivial example, if a site needs JavaScript to function, it should check for JavaScript with or in combination with the “noscript” tag (not related to the NoScript plugin)—not whether a browser from a short list of known JavaScript capable browsers is used. The latter will give false positives when JavaScript is turned off and false negatives when a rarer-but-JavaScript-capable browser is used.

****If different versions are needed at all (dubious), this should be an explicit choice by the user. I note that I have very often preferred to use the mobile versions of various sites when on a desktop, because these typically are less over-wrought, are “cleaner”, have a lesser reliance on (unnecessary) JavaScript, come with less advertising, …

Unfortunately, a fad/gimmick/sham of the last few years has been adaptive web design. Attempts to apply this virtually entirely unnecessary and detrimental concept is the cause of much of the wish for e.g. knowing the browser, OS, screen size*, device type, … (other reasons relate to e.g. de-anonymization, profiling, and targeted advertising), to the point that some have wanted to detect the charge level of a mobile’s battery in order to adapt the page… The last is horrendous in several aspects, including an enormous patronization, the demonstration of a highly incompetent design (no page should ever, not even when the battery is full, draw so much power that this is a valid concern), great additional risks with profiling, and a general user hostility—if this was a legitimate issue, give the user an explicit choice: He might prefer to run everything at full speed when low on charge, because he knows that he will be home in ten minutes; he might prefer to run everything at minimum speed even with a full battery, because he is gone for the weekend and has forgotten his charger.

*Screen size might seem highly relevant to the uninitiated, but normally is not—a sufficiently generic design can be made for most types of content. With the rare exceptions, leave the choice to the user.

Written by michaeleriksson

September 27, 2018 at 4:08 pm

Posted in Uncategorized

Tagged with , , , ,

A discussion of naive use of links

leave a comment »

People with a poor understanding of the Web and/or “hyper text” often add links in odd and suboptimal ways, including what I think of as “here”* links, which make the text specific to the medium, can confuse readers, and/or cause problems for automatic and semi-automatic tools (screen readers, link listers, search engines, whatnots). A typical example**:

*Because of the common use of the word “here”.

**All examples adhere to patterns that I have seen on many occasions; however, none are direct quotes. I mark the linked portions of the text by an opening and a closing “#”. For instance, “a #b# c” implies a text of “a b c” with a link on the “b”. (Using real links could cause problems very similar to those I advice against with this text, and has the added complication that the difference between e.g. “#a# #b#” and “#a b#” is not always obvious.)

Smith has written an extensive report on X. You can find the report #here#.

Consider e.g. how this would look in a link list: Now we have a link identified only by the word “here”… Consider what happens after printing, conversion to plain-text, or similar: What is “here” even supposed to imply? “You can find the report here.” leads to the obvious question “Where?!?”, which cannot be answered from the text it self. (And there need not be any indication in the text that this resulted from a link being lost, since coloring and, often, underlining will also be lost.) Consider the lack of information as to where the link leads. Consider how search-engines are hampered in their attempts to make classifications and evaluations. Etc.

Of course, these problems are not restricted to “here”. Consider variations like:

Smith has written an extensive report on X. #Use this link to download.#

Unsurprisingly, it is common for “here” links to occur repeatedly in the same document, often in the same sentence:

[…]
You can find the report #here#.
[…]
Other sources can be found #here#, #here#, #here#, and #here#.
[…]
For more on X click #here#. For more on Y click #here#.

Now the problems are made that much worse, because the links are indistinguishable without further investigation.

Contrast the first example with:

Smith has written #an extensive report on X#.

This avoids most* of the above problems, is more informative, more user-friendly, and shorter to boot. Other alternatives are possible, especially when some reformulation is allowed. For instance, “#Smith has written an extensive report on X#.” is even more informative, but makes the link unnecessarily long (which is why I preferred the chosen version).

*When moving to another medium, the link is still lost; however, the result is at least less confusing. (This could be avoided by spelling out the full link, which is legitimate and sometimes the best thing to do. Much more often, the negative effects on the HTML view would be too large through breaking a natural text flow or taking up too much space, as with e.g. #https://www.fictional-college.edu/~john.smith/my-extensive-report-on-X.html#.)

Similarly, what if the middle part of the third example had been:

[…]
Other sources include #an interview with Mike Tyson#, #the book XYZ#, #a NASA study#, and #Smith’s Ph.D. thesis#.*
[…]

*The exact texts to use are open to discussion, depending on factors like how the author prioritizes informative links vs. short links, what is clear from context, and similar. Going down to e.g. “[…] include #Mike Tyson# […]” might, depending on context, keep enough information, and would make the link shorter.

Ideally, the resulting text should read in a manner that is agnostic of the medium and could be moved unchanged to e.g. a (printed) news-paper article, as with a regular text that has simply been enriched with links for the convenience of the reader; ideally, the text of the link should have sufficient explanatory value that the reader has a good expectation of what to find even when just looking at a link list, but, at a minimum, when looking at the full sentence of the link. (Which is not to say that these ideals are always realistic or that I, myself, always keep them in mind—I do not. However, by making links even somewhat sensible, and by categorically avoiding nonsense like “You can find the report #here#.”, most of the problems automatically disappear. Compromises that I often deliberately make include “#an older text#” and the “#[1]#” discussed below.)

The alternative of using “#[1]#”, “#[2]#”, etc., is a hybrid between “good” and “bad” linking. Compared to “#here#”, such links have the advantage of being unique, being easily recognizable as references in other contexts (e.g. after printing), and allowing an easier transition to another medium by extending the text with a set of explanatory references (cf. how Wikipedia handles references*). They also allow for easier intra-text references. They still share disadvantages like the linked text not being very informative. I use this alternative fairly often, especially when several links are given at once and/or I will reference the same source later on in the text—however, I stress this is a compromise between effort and result.

*I.e. as combination of bracketed numbers in the text that refer to a later section with more information, including the full link, book title, author, or whatever might apply. In terms of results, this is arguably a better solution even for HTML; however, it implies a lot more work than if a link is put directly on the bracketed number, and will be impractical in many contexts. To boot, the effort for the reader can also be increased unduly when he is expected to actually visit the linked-to source in a high proportion of the cases (which is not the case with Wikipedia).

Excursion on other problems:
Other common problems include failing to indicate that a link leads to non-HTML content (e.g. a PDF-file), causing unexpected behavior* when the link is clicked; and forcing the opening of external links into new windows/tabs, contrary to the expectations of a reasonable user, potentially breaking tabbed browsing**, and violating the principle that the user should be in control: If the reader wants a page to open in a new tab/window, he actively does so. If he does not, it is not the right of some far away author to override his decision.

*Including opening additional applications (or a sub-standard browser view), often in combination with focus stealing; longer download times; and bandwidth wasted for those on a slow or non-flatrate connection.

**Even when the page is opened in a new tab, the result rarely fits the normal workflow of tabbed browsing, i.e. that tabs are opened in the background for later viewing, while the user remains on the original page. If the browser does not support the conversion of “new window” requests into “new tab” requests, the results can be far worse.

Excursion on too specific assumptions in general:
Youtube provides many examples of making too specific assumptions. For instance, a video that asks the users to “comment below” might become misleading even through a minor Youtube redesign. Others, e.g. “please ‘like’ this video” might survive even a drastic redesign, but would still be irrelevant if moved to or viewed in another context, e.g. after a manual download.

Blogging comes with potentially similar problems, but is rarely as bad (likely because bloggers are less obsessed with “likes” and subscriptions); however, I advice being careful about using highly blogging specific terminology for a text that might later appear in another context—just like a book or news paper written in the era of e-books and online news should avoid speaking of the paper it is (not necessarily) printed on. (I acknowledge that I have often violated my own advice.)

Many instructions for computer and whatnot use make far too many assumptions. Consider e.g. giving users instruction to use a certain key shortcut that is browser specific (or even to “click” on a link), telling him to start a certain program, giving him OS instructions that require Windows (or even a specific version of Windows), giving instructions on how to start an application through menus in a specific language (instead of giving the name of the application to start), …

Written by michaeleriksson

August 16, 2018 at 8:20 am

Posted in Uncategorized

Tagged with , , , ,

Pale Moon as a replacement for Tor Browser (or Firefox)

with one comment

With the continued deterioration of Firefox and the major recent or (for Tor Browser* users) up-coming changes, I have strongly considered moving away from the Tor Browser*. Specifically, I have had my eyes on Pale Moon, a complete fork of an older Firefox version, for a long time, but have held back because it was not available from the Debian repositories**.

*The Tor Browser is a derivative of Firefox, based on the “extended support releases” rather than the latest release. This implies that changes of various kinds are released later or considerably later than for Firefox it self.

**Implying that there would be more hassle to get it running, no way to get automatic security updates through the standard Debian mechanisms, etc.

I read up more in detail some weeks ago*, with the urgency rising, considering going for a switch anyway:

*The below contents are from my open browser tabs. There might have been edits, new posts, whatnot since then.

At first, it seemed to be a sufficiently strong candidate that I could see myself dropping the hardening provided by the Tor Browser in return for having a “better Firefox”. In particular, it promised not to duplicate Firefox’ absurd attitude towards the users (cf. e.g. [1], [2]). For instance, the FAQ claims:

Firefox is created with one-size-fits-all in mind; Pale Moon is created with efficiency and user choice in mind. These two approaches are mutually exclusive, […] Pale Moon also has a different set of goals as to what should be included in the browser and intended audience.

Pale Moon has a number of differences in the user interface and feature set to provide an as intuitive, predictable, logical and usable user interface as possible for the best user experience. […]

Note that Pale Moon will never adopt the Australis (Firefox 29 and later) interface and aims to remain a fully XUL-driven browser with full user interface customizability.

Also please note that Pale Moon has not run rampant with its releases […]

However, the official forums showed that Pale Moon might talk the talk—but it does not walk the walk. (I have particular concerns about the lead developer, “Moonchild”, but make reservations for the risk of misattributation.) Consider the following forum discussions (by no means a complete list):

  1. https://forum.palemoon.org/viewtopic.php?f=46&t=17619:

    The developers more-or-less force the users to give up the very, very valuable NoScript plug-in*, using the motivation that too many web-sites would break when it is turned on and that Pale Moon would be blamed by uninformed users—a truly Firefoxian move!

    *The use of “plug-in” and “add-on” in this text might be inconsistent. (Starting with my never quite having found out whether there is a difference in Firefox terminology and, if so, exactly what that difference is.)

    Since this is implemented through blacklisting of the plug-in, it appears that the only way to get the plug-in to work again is to turn off the blacklist entirely, which means a considerable unnecessary security risk… The flaws of this implementation, be it of the block, per se, or the blacklist, seem to be beyond the developers’ comprehension.

    The repeatedly displayed lack of insight to the criticism raised in the thread led to comments like

    This makes the whole idea of switching from Firefox a farce– it is replacing the arrogance of one party with the arrogance of another.

    You are the one who needs perspective, and people are going to be giving it to you. You will certainly not gain it though.

    (More complaints about this decision can be found in e.g. https://forum.palemoon.org/viewtopic.php?f=46&t=19119. This might at some point include the above, seeing that the moderators want to merge threads.)

  2. https://forum.palemoon.org/viewtopic.php?f=13&t=5647:

    Here a number of rules are given for those who want to suggest new features. While some of them are somewhat sensible, not all are, and the overall impression is not positive:

    Is the suggested feature specific to your workflow? If so, you have to think about how it would affect people who do things differently, and how many people are likely to use the same workflow you do. Evaluate your own browsing behavior before suggesting this kind of feature.

    This is not only very hard to check, but the attitude displayed here goes a long way in the direction of “if the majority does not use it, it should not be a feature”, which is a major problem with modern software—including the Firefox of the last years. (There is much positive to say about avoiding feature bloat, including easier maintenance; however, older Unix software has shown that it is possible to achieve tremendous functionality and flexibility without writing undue features, simply through the correct thinking. In contrast, most modern software falls on its face as soon as the user tries to do something other than the designers explicitly intended—which is often pitifully little and highly limiting.)

    Is the suggested feature culturally neutral? Keep in mind that Pale Moon users come from all walks of life everywhere in the world. Core features should apply to everyone and not be regionally or culturally bound where possible.

    This sounds like the worst type of Politically Correct crap: Either a feature makes sense or it does not. “Cultural neutrality” is not a valid criterion. (Note that e.g. a Bible-study helper or a find-the-way-to-Mecca helper would be, even without this guideline, too specific to make a useful feature, a prime example of something to put in a plug-in, and/or something that could be generalized to something more useful and culture neutral.)

    How “advanced use” is the suggested feature? While I wholly welcome power users and gurus to use Pale Moon, any added feature should still be easy to understand for most anyone.

    Again a fundamentally flawed approach from a software-development perspective: This ties the hands of the development and could cause a number of beneficial features not to be implemented. It would, for instance, have prevented the development of the features needed for plug-ins… To boot, the limit for “too advanced” is usually set far too low, as e.g. with Firefox and images on/off or, indeed, with Pale Moon and NoScript above…

    Are there multiple existing solutions to what the suggestion addresses? You can call this “technical neutrality”. If there are clear choices a user can make from e.g. existing add-ons to get the feature implemented in different ways, with different levels of granularity or catering to different situations, then the feature is likely less suitable for inclusion in the browser core. User choice is an important driver for Pale Moon.

    While I agree with the question, I find the explanation incomprehensible. For one thing, I am not certain that I understand what is meant; for another, the argumentation is contrary to expectations: If there are multiple existing add-ons to solve a problem, then that could very well be a sign that the functionality should be given a blessing as a core feature (or that some core feature should be made available to cover commonalities of the add-ons). The more solutions there are, the more popular the feature is likely to be, and the more duplication is caused by not having it as a core feature… Indeed, the question would be better as “Is there at least one existing solution to what the suggestion addresses?”, seeing that this is where the question gains its legitimacy.

    Does the suggestion improve overall quality of the browser? A suggestion for a core feature should improve overall quality or convenience for the user in the broadest sense of the word and applicable to a majority of the Pale Moon users.

    Again, a question that makes sense followed by an explanation that does not: This again commits the sin of ruling out features based on some version of “majority use” and rules many things out that would fulfill the question.

    Does the suggestion hinder the download and display of any content? Pale Moon should enable and promote the download of web content, not prevent it. This applies to any content, including commercial content that might be considered “superfluous” or “undesired”. As such, the Pale Moon browser core will not be a good place to put any “blocking” features (ad blockers, script blockers, etc.)

    Spurious reasoning: A good browser should serve to display content the way the user likes it. This includes having some ability to block content as a matter of course, including a minimum of e.g. images on/off*, JavaScript on/off, Cookies on/off, animated content on/off, movies on/off, sound on/off, and preferably e.g. a possibility to black-list based on a pattern. Indeed, many of these can be hard or impossible to implement without supporting core features… However, more advanced solutions, e.g. that provided by the NoScript plug-in are preferably to put in an add-on to avoid bloat. (But then the NoScript plugin is not available anymore…)

    *In some examples, there can be a question of whether the actual download or only the display should be prevented. However, one of the main reasons to block some types of contents is to reduce the number and size of downloads—especially for those who use Tor and see correspondingly slower downloads.

  3. https://forum.palemoon.org/viewtopic.php?f=13&t=19187:

    A post titled “The developers’ attitude” starts this thread thus:

    OK, you have to be the biggest asshole developers I’ve seen in a while. With this attitude you don’t deserve any attention or recognition whatsoever.

    The stupidity that stems from this is so immense that after I read it, its force was so strong a wind gushed from my monitor and pushed me back.

    I don’t care if you delete this thread or ban me, the important thing is that a moderator and maybe some users will read it before its deletion and you will get called out for the arrogant asshats you are.

    You need to stop with this attitude or even the few people that use your outdated, laughable FireFox forks will stop using it knowing you’re a bunch of douchebags.

    Unfortunately, there is no reason given for this opinion, but it is certainly not a good sign, especially when combined with the other threads mentioned.

    (The rest of the thread is, predictably, a flame war.)

  4. https://forum.palemoon.org/viewtopic.php?f=3&t=19696:

    Here a user has problems with a missing option to continue with a page display after a warning concerning certificates—a standard feature in modern browsers. The responses are not cooperative and the OP says:

    But in this case it was safe, as seen by the fact the page loaded if I followed a link to get to it. So, why does Pale Moon get to make the decision instead of me? Shouldn’t a manual override always be an option? Shouldn’t I have control over how I use the program?

    (An opinion that I support whole-heartedly: He should be in control, Pale Moon claims to want to put users in control, and not actually doing so is both user-hostile and hypocritical. Software should enable—not disable.)

    Most of the thread consists of a back and forth between users, who believe that they should be in charge, and developers, who believe that they know better…

  5. https://forum.palemoon.org/viewtopic.php?f=17&t=11659:

    Here the developers explain “why we prefer to not allow TOR relayed users to use our services”—using entirely specious reasoning: Because Pale Moon would not in any way be “personally or ideologically sensitive”, anonymity is not needed and the only conceivable use of Tor would be for illicit purposes like “abuse, spam and trolling”.

    This shows a fundamental lack of understanding for how anonymity on the Internet works and the problems relating to e.g. profile building and government surveillance—not to mention the potential extra effort to e.g. run multiple browsers. To boot, if all sites reasoned in this manner, only a fraction of sites would be usable with Tor, and Tor correspondingly be reduced to a tool for criminals/terrorists and vulnerable politicals, instead of the general anonymity tool it is supposed to be.

    Some other thread that I did not keep open also showed a complete misunderstanding of the advantages and disadvantages of Tor.

    For someone considering a switch from Tor Browser (or even Tor it self), this is not a good sign, especially since this type of naivete is likely to also manifest it self in the internal workings of Pale Moon, e.g. concerning what data is volunteered to various sites.

At least at this point of time, I would not touch Pale Moon with a ten-foot pole. For others, it might or might not be better than the original Firefox, but that is not a ringing endorsement… Tor Browser users should certainly stay with Tor Browser, even at the price of losing a few plug-ins. Sadly, the reason for my rejection is that Pale Moon manifestly does have the same user-despising philosophy as Firefox—quite contrary to the official claims.

Written by michaeleriksson

August 14, 2018 at 8:29 am

Eternal September? I wish! (And some thoughts on email)

with 2 comments

One of the most unfortunate trends of the Internet is that erstwhile standard procedures, behaviors, whatnot are forced out by inferior alternatives, as an extension of the Eternal September. Indeed, the point where even the Eternal September can be viewed with some nostalgia has long been reached:

The name arose through a combination of how, every September, the Internet would see a sudden burst of college freshmen, who still needed to learn how to handle themselves and who were an annoyance to older users until they had done so; and how the popularization of the Internet outside of college caused this inflow of unversed users to take place over the entire year. Even so, in the early days, the new users tended to be of over-average intelligence, tech affinity, and/or willingness to adapt—and many could still continuously be made to leave their newbie status behind. The problem with the Eternal September was its Hydra character: Cut of one head and it grew two new.

Today’s situation is far, far worse: There is no filtering* of who uses the Internet, be it with regard to intelligence, technical understanding, willingness to learn from more senior users, …; and, by now, the vast majority of all users are stuck in a constant newbie state. Indeed, we have long reached a point where those who have been on the Internet since before the problems became overwhelming** are viewed as weirdos for doing things the right way***. Worse: Websites are usually made for the “lowest common denominator”, with regard to content, language****, and interface, making them far less interesting than they could be to the old guard. This is paralleled in a number of negative phenomena on the Internet (and, unfortunately, IT in general): Consider e.g. how much less profitable it would be to spam a collective of STEM students than a random selection of the overall population, or how much less successful an Internet-based virus among the tech savvy.

*A formal filter, a legal restriction, an equivalent of a driver’s license, or similar, was not in place before the Eternal September either. However, Internet access outside of higher education was reasonably rare, and even within higher education it was far more common in STEM areas than in e.g. the social sciences. Correspondingly, there was an implicit filter that made it far more likely for e.g. a math major to have Internet access than for e.g. a high-school drop-out.

**The linked-to Wikipedia page puts 1993 as the start date in the U.S., but other countries like trailed somewhat. I started college in 1994 and the situation was reasonable for a few years more, before the Internet boom really started—after which is has been downhill all the way.

***Note that while there is some arbitrariness to all rules and there is usually more than one legitimate way to handle things, there is at least one important difference between the “old ways” and the “new ways” (even aside from the benefit of continuity and consistency, which would have been present with the old rules): The old ways were thought-out by highly intelligent people and/or developed by trial-and-error to a point where they worked quite well—the new are a mixture of complete arbitrariness; ideas by less intelligent and less experienced users, or even managers of some software company; attempts to apply unsuitable “real-world” concepts to the online world; … To this must be added the technical side: Someone who understands it, all other factors equal, is objectively better off that someone who does not—and less of a burden to others.

****Even Wikipedia, once an exemplary source of good writing, has gone downhill considerably, with regard to both grammar and style. (Notably, the “encyclopedic writing” aspect is increasingly disappearing in favor of a more journalistic or magazine style. I have long had plans for a more detailed post on Wikipedia, including topics like an infestation with unencyclopedic propaganda, but have yet to get around to it.)

A particularly depressing aspect, but great illustration of the more general problems, is the (ab-)use of email by many businesses, government institutions, and similar, who simply do not understand the medium and how to use it properly. No, I am not talking about spam here (although spam is a gross violation)—I am talking about everyday use.

Consider e.g.:

  1. That many businesses and virtually all (German) government institutions fail to quote the original text when replying and replace the subject line with something to the effect of “Your message from [date]”.

    The former makes it harder to process the message, in particular when a re-reply is needed, often forcing the user to open several other messages to check for past contents; the latter makes it much harder to keep messages together that belong together*, to find the right reply to an email, identify why a reply was sent**, etc. To boot, these problems likely contribute to poor customer service through creating similar issues on the other end, e.g. through a member of customer support not having all the information present without looking through old emails or some ticket system: Even if the information is there, access will be slower, more resources will be wasted, and there is a major risk that important information will still be missed.

    *Not only manually, but also through giving automatic “threading” mechanisms in email clients an unexpected obstacle.

    **When the original text is not included, this becomes even harder. In a worst-case scenario, when several emails were sent to the same counter-part on the same day (rare but happens), it might not even be possible to make the correct match—or only through comparing various IDs in the message headers. The latter is not only much more effort than just looking at subject lines, it also requires that all involved software components have treated them correctly, that the counter-part has used them correctly, and that the user knows that they exist…

    The explanation for this absolutely amateurish and destructive behavior is almost certainly that they have never bothered to learn how to handle email, and just unreflectingly apply methods that they used with “snail mail”* in the past. This is the more absurd since going in the other direction, and altering some snail mail procedures in light of experiences with email, would be more beneficial.

    *This phrase gives another example of how the world can change: Twenty years ago, I could use the phrase and simply assume that the vast majority of all readers would either know that I meant “physical mail sent by the post”—or be willing both to find out the meaning on their own and to learn something new. Today, while typing the phrase, I am suddenly unsure whether it will be understood—and I know that very many modern Internet users will not be willing to learn. I might be willing to give the disappearance of the phrase a pass: We can neither expect every phrase ever popular to continue to be so in the long term, nor the phrases of any group to be known in all other groups. However, the attitude towards learning and own effort is a different matter entirely.

  2. When messages are quoted, established rules are usually ignored entirely, especially with regard to putting the quote ahead of the answer and to intermingle quote and reply, which makes an enormous difference in the ease of processing the reply. Some tools, notably MS Outlook, more-or-less force a rule violation on the users… When quote and reply are intermingled it is usually not done in the established manner, with separating new lines and use resp. non-use of a “> ” prefix; instead, the new text is simply written straight into the old and separated only by a highly problematic* use of a different color.

    *Among the problems: The colors are not standardized. The result becomes confusing as to who wrote what in what order after just a few back-and-forths, to the point of making a lengthier email discussion almost impossible (whereas it was one of the main uses of email in the days of yore). It forces the use of HTML emails (cf. below). There is no guarantee that the colors will be visible after printing or a copy-and-paste action to another tool (notably a stand-alone editor). Not all email clients will be able to render the colors correctly (and they are not at fault, seeing that HTML is not a part of the email specifications). Generally, color should not be used to make a semantic differentiation—only to highlight it. (For instance, in the example below, an email client could automatically detect the various “>” levels and apply colors appropriately; however, the “>” signs must remain as the actual carriers of meaning.)

    To give a (simplistic and fictional) example of correct quoting:

    >>> Have you seen the latest “Star Wars” movie?
    >> No.
    > Why not?
    The one before that was too disappointing.

  3. Ubiquitous use of “no-reply” addresses: Anyone who sends an email has a positive duty to ensure that the recipient can reply to this email. This includes event-generated automatic messages (e.g. to the effect of “we have received your email” or “your package has just been sent”) and news letters. Either make sure that there is someone human able to read the replies or do not send the email at all.* This is not only an ethical duty towards the recipient, it is also a near must for a responsible sender, who will be interested in e.g. tracking resulting failures.

    *The exact role of this human (or group of humans) will depend on the circumstances; often it will be someone in customer service or a technical administrator.

  4. Abuse of email as just a cost-saver relative snail mail: There is nothing wrong with sending relevant attachments in addition to an email text, and in some cases, e.g. when sending an invoice*, even a more-or-less contentless email and an attachment can be OK (provided that the recipient has consented). However, some take this to an absurd extreme, notably the outrageously incompetent German insurance company HUK, and write a PDF letter containing nothing that could not be put in an email, attach the resulting file to the email, and use a boiler-plate email text amounting to “please open the attachment to read our message”. This, obviously, is extremely reader hostile, seeing that the reader now has to go through several additional steps just to get at the main message** and it ruins the normal reply and quote mechanisms of email entirely. To boot, it blows up the size of the message to many times what it should be*** and increases the risk of some type of malware infection.

    *This especially if the contents of the invoice are to some degree duplicated in the email proper, including total amount, time period, and due date (but more data is better). Writing an invoice entirely as a plain-text email is possible, and then the attachment would be unnecessary; however, there can be legitimate reasons to prefer e.g. PDF, including a reduced risk of manipulation, a more convincing and consistent visual appearance if a hard-copy has to be presented to the IRS, and an easier differentiation between the invoice proper and an accompanying message. (There might or might not be additional legal restrictions in some jurisdictions.)

    **Note that it is not just a matter of one extra click to open that one attachment that one time. Consider e.g. a scenario of skimming through a dozen emails from the same sender, from two years back, in order to find those dealing with a specific issue, and then to extract the relevant information to clarify some new development: If we compare a set of regular emails and a set of emails-used-to-carry-PDFs, the time and effort needed can be several orders larger for the latter. Or consider how the ability to use a search mechanism in the email client is reduced through this abuse of email.

    ***This is, admittedly, less of an issue today than in the past (but HUK has been doing this for a very long time…). Still there are situations where this could be a problem, e.g. when a mailbox has an outdated size limit. It is also a performance issue with regard to other email users: The slow-down and increase in resource use for any individual email will be relatively small; however, in the sum, the difference could be massive. What if every message was blown-up by a factor of 10, 100, 1000, …? What would the effects on the overall performance be and what amount of band-width and processing power (especially if spam or virus filters are applied) would be needed? For instance, the two emails at the top of my current mailbox are, respectively, an outgoing message from me at 1522 Byte and the reply to said message at 190 Kilo(!)byte—roughly 125 times as much. The lion’s part of the difference? A two-page PDF file…

  5. Use of HTML as an email format: Such use should, on the outside, be limited to recipients known both to handle the emails in a compatible manner and to be consenting: HTML is not supported by all email clients, and not in the same manner by all that do. It poses an additional security and privacy risk to the recipient. It bloats the message to several-to-many times the size it should be. It makes offline storage of the email more complicated. It makes it harder to use standard reply and quoting mechanisms. The risk of distortion on the way to the recipient is larger. … Notably, it also, very often, makes the email harder to read, through poor design.

    To boot, the reason for the use is usually very dubious to begin with, including the wish to include non-informative images (e.g. a company logo), to try to unethically track the recipients behavior (e.g. through including external images and seeing what images is retrieved when), or to make the message more aesthetic*. A particular distasteful abuse is some newsletters that try emulate the chaotic design of a commercial flyer or catalog, which often deliberately try to confuse the readers—either the newsletter senders are incompetent or they try to achieve something incompatible with the purpose of a newsletter**.

    *This is simply not the job of the sender: The sender should send his contents in a neutral form and the rendering should be done according to the will of the recipient and/or his email client—not the sender. Efforts to change this usually do more harm than good.

    **Most likely, but not necessarily, to use it as advertising. I note that while newsletters are often unwelcome and while the usual automatic addition of any and all customers to the list of recipients is despicable, the abuse of a newsletter for advertising is inexcusable: Many will consent to being or deliberately register as recipients because they are interested in news about or from the sender; and it is a gross violation of the trust placed in the sender to instead send them advertising.

    There are legitimate cases where a plain-text email is not enough to fulfill a certain use-case; however, they are rare and usually restricted to company-internal emails. For instance, one of the rare cases when I use HTML emails is when I want to send the tabular result of a database query to a colleague without having to use e.g. an Excel attachment—and even this is a border-line spurious use: In the days of yore, with some reservations for the exact contents, this could have been done equally well in plain-text. Today it cannot, because almost all email readers use a proportional font and because some email clients take inexcusable liberties with the contents*.

    *For instance, Outlook per default removes “unnecessary” line-breaks—and does so making assumptions that severely restrict the ability to format a plain-text document so that it actually is readable for the recipient.

    Of course, even assuming a legitimate use-case, it can be disputed whether specifically HTML is a good idea: Most likely, the use arose out of convenience or the misguided belief that HTML was a generic Internet format (rather than originating as a special purpose language for the Web). It would have been better to extend email with greater formatting capabilities in an ordered, centralized, and special-purpose* manner, as has been done with so many other Internet related technologies (cf. a great number of RFCs).

    *Which is not automatically to say that something should be developed from scratch or without regard for other areas—merely that it should be made to suit the intended purpose well and only the intended purpose. Some member (or variation of a member) of the ROFF-family might have been suitable, seeing that they are much closer to plain-text to begin with.

  6. A particularly idiotic mistreatment of emails is exemplified by Daimler and in recent discussion for another large auto-maker (which one, I do not recall):

    If an email is sent to an employee at the wrong time, e.g. during vacation, the email is simply deleted…

    The motivation given is absurd and shows a complete lack of understanding of the medium: This way, the private time of the employees would be protected. To make matters worse, the “threat” comes not from the outside but from a (real or imagined) pressure from within the company to always be available. In effect, Daimler has created a problem, and now tries to solve this problem through pushing the responsibility and consequences onto innocent third parties.

    Email is by its nature an asynchronous means of communication; and one of its greatest advantage is that the sender knows that he can send a message now, even outside of office hours or during vacation periods, and have it handled on the other end later. He does not have to consider issues like whether the recipient (if a business) is open or (if a person) is at home with his computer on. Moreover, the “later” is, with some reservations for common courtesy and stated dead-lines, determined by the recipient: He can chose to handle the email in the middle of his vacation—or he can chose to wait until he is back in the office. Whichever choice he makes, it is his choice; and if he chooses the former against his own best interests, well, then he only has himself to blame.

    By this utterly ridiculous rule, one of the greatest advantages of email is destroyed. To boot, it does this by putting an unfair burden on the sender, who is now not only required to re-send at a later and less convenient time—but who can see a number of additional disadvantages. Assume e.g. that the sender is about to head for his vacation, sends an important and urgent email, goes of the grid for two weeks, and comes back to see that his email has not even been read. Or take someone who writes a lengthy email and loses* any own copy after sending—should he now be required to re-type the entire thing, because of a grossly negligent policy of the recipient’s? Or what happens when employees in very different time zones or with very different vacation habits try to communicate with each other? Should the one work during his normal off-hours or vacation so that the other can receive the email during his time in the office? What happens if the notification** of “please send again” from company A is it self deleted by company B?

    *Disk crashes and accidental deletes happen; I have worked with email clients that do not automatically save sent emails; and, in the spirit of this post, not all users actually know how to retrieve sent emails that are saved…

    **Daimler apparently at least has the decency to send such notifications. I would not count on all copy-cats to follow suit.

    Want to keep your employees from reading company emails in their spare time? Do not give them email access from home or do cut it off during those times when no access is wanted! The way chosen by Daimler turns the reasonable way of handling things on its head—to the gross detriment of others. (This even assuming that the intended goal is legitimate: These are adults. We could let them chose for themselves…)

Written by michaeleriksson

January 5, 2018 at 12:54 am

Posted in Uncategorized

Tagged with , , , ,

Unethical news sites endangering their readers

leave a comment »

Trying to research the previous post a little, I had major problems: Almost every German news site I visited displayed nothing but the claim that the site was unusable without JavaScript.

This is extremely problematic, because they have no legitimate* reason that could possibly require** JavaScript—and a news site is the last place, short of a porn site, where a user should allow JavaScript to be activated! News sites usually contain considerable external contents, e.g. in the form of advertising or comments left by other readers. This implies that the visitor is exposed to a very considerable and entirely unnecessary security risk— even when he trusts the news site it self to be non-hostile (potentially naive) and even if he can live with the entirely unnecessary animations and other idiocies that almost invariably worsen the user experience when JavaScript is on. This is the computer equivalent to having sex with a nymphomaniac without a condom…

*As opposed to illegitimate, like profile building or implementing unethically intrusive adverts.

**As opposed to providing a smaller benefit somewhere..

For a news site* to require JavaScript is grossly unethical and reckless, and I strongly encourage you to without exceptions avoid such sites.

*Much of the same argumentation applies to many other sites too. However, some other sites do have legitimate reasons and/or provide a considerable benefit; while the danger is usually smaller, since there tends to be less external content of various types. Still, most uses of JavaScript are entirely unnecessary and only bring an unnecessary risk to the visitors.

Written by michaeleriksson

December 11, 2017 at 11:20 pm