Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘usability

The struggling author: Amateurish Amazon and follow-up on construction noise

leave a comment »

Another shitty day: It appears that the construction works are here again—and, again, without any notification or possibility to judge the size of the problem. Indeed, there is now scaffolding along the house wall, which could imply something very major and something not perpetrated by an individual apartment owner or resident but the actual building management.

Fortunately, the disturbances started in the mid-afternoon, and I could spend enough time walking to come back home after they had stopped. However, firstly, I have no idea how the future will look, and, secondly, the city is almost dead due to COVID-restrictions, meaning that there is very little to actually do, except walking (per se).

To conclude the day, I decided to finally open that Amazon KDP account that I will need in the mid- or long term. This was a frustrating and annoying experience. A partial summary (even at the risk of exceeding the policy for this closed-ish blog, but I need to unload the frustration):

  1. The interface asks for an email address, sends a confirmation code to that address, and awaits entry of that code.


  2. The interface ADDITIONALLY asks for mobile phone number, sends a second confirmation code there, and awaits entry of that code.

    Not OK.

    Firstly, it must not be a prerequisite to have a cell phone to participate in various non–cell-phone activities. (Indeed, I have gone through quite long stretches without one and it is pure coincidence that I have a working cell-phone number at the time of writing.) Secondly, email confirmation should have been enough. Thirdly, Amazon claims that it would later be possible to opt out of cell phone verifications, but because it has to be activated the first time around, Amazon can now steal data that I would very much like to keep absent, e.g. to avoid abusive SMS/“text” spam. (Note that Amazon has no legitimate reason to know my telephone number, unlike e.g. my street address and email, for the current purposes. I have yet to investigate whether the opt-out claim holds true.)

    Moreover, the implementation was utterly incompetent, by repeatedly* resetting the country to the U.S. Here my explicit choice of Germany should have been kept; and the original default should have been Germany, too, as my address was German and I was clearly accessing the site from Germany. (In my recollection, but I might be wrong, Amazon even used German as the interface language.)

    *I tried to get past this step, as no mention of the reason had been made (itself a poor UI decision), by first entering a landline number, which is less susceptible to abuse. As the claim that a SMS had been sent was given after entry, I re-tried it with a cell-phone number, including (unthinkingly) a leading “0”. As no SMS arrived, I tried again, removing the “0”, for a total of three attempts.

  3. A highly annoying, moving CAPTCHA needed to be answered.

    At best dubious, as there seems to be little reason to assume that someone goes to the immense effort of handling automatic confirmations per email and SMS for a purpose like creating an Amazon account. (Indeed, with this level of overall stringency, it might have been better to simply send a postal confirmation code and accept the temporary delay in exchange for one single confirmation.)

    Moreover, the implementation was awful, including crossing the border to where it becomes hard even for a human to complete the confirmation. (I needed two attempts, myself.)

  4. I proceeded to enter the user account, an act apparently considered a separate log-in, despite following directly after the account-creation process, which required a second SMS confirmation.

    Not OK.

    Firstly, this particular type of two-factor authentication is very dubious in general,* increasing the efforts needed for trivial tasks disproportionately. (But note mentions of opt-out above.) Secondly, specifically in this situation, it was entirely redundant and my previous SMS confirmation should have been considered enough.

    *In fact, the two main scenarios where it is needed is (a) with idiot users who pick poor passwords (I use random and automatically generated ones) or have sloppy local security (I do not), (b) with idiot service providers who have too many flaws in their own systems or allow password hashes to get out (or, worse, have actually stored plain-text passwords). The risk of e.g. a snooper stealing a password exists, but is a lot smaller. Moreover, the (partially false) sense of security created by two-factor authentication can worsen the problem with (a); moreover, when more and more users access the Internet per cell phone, the value of this specific type of two-factor authentication is drastically reduced.

  5. (My account was marked as incomplete (as expected), and I proceeded to complete the data. Note that the below items might be in the wrong order or be incomplete. It does, in particular, not include several amateurish oddities with the workflow and ambiguities concerning what-button-does-what.)
  6. Address fields included an empty field for my telephone number, which was mandatory.

    Not OK.

    Firstly, my phone number is plainly and simply not Amazon’s business. Secondly, as a mobile number had already been entered, this should have been the pre-filled default.

  7. For my bank information, separate entries of IBAN, BIC, and name-of-bank were needed.

    Not OK.

    This shows a fundamentally flawed approach, as the IBAN is intended to serve as the sole account identification. Requesting a separate BIC is amateur hour. (This unlike the “old” German system, where a BLZ identified the bank, and an account number the account within that bank.) The bank name might be acceptable as a safety check, but better systems fill it out based on the IBAN.* Moreover, it should be a near given that data like account numbers are copy-and-pasted, which would either make the check unnecessary (data is guaranteed to be correct) or pointless (if, highly unlikely, the original is faulty, repeated copy-and-paste procedures will not help).**

    *Here Amazon might be excused as an international operation.

    **However, other checks, like “is the IBAN of the right length” are still justified, to catch e.g. an incompletely copied IBAN.

  8. I was led to the fill-out-the-U.S.-tax-excemption area.

    Not OK.

    A reasonable operation should have made sure that such nonsense is not necessary, e.g. through use of a non-U.S. subsidiary. A smaller company (or one, like Barnes & Nobles, highly U.S. centric) might have deserved a pass, but Amazon is one of the largest and most international companies in the world.

    (But I was already aware of the need to do this to avoid an absurd-for-any-European tax deduction of 30 % in favor of the U.S. (!) IRS, and had indeed even prepared by finding my German TIN in advance.)

  9. Required further fields for the preceding item included address fields that had already been entered.

    Not OK.

    Already entered data should be taken as default values.

  10. My German address contains an umlaut (a “ü”, to be specific). This was rejected when I tried to proceed.*

    *I am a little uncertain whether this was only with the tax fields or already with the main address fields. Below, I assume tax fields. If not, it is far worse.

    Not OK.

    Even assuming that this restriction was posed by the U.S. IRS, the check should have been performed during entry and a pre-filled value with a suggested correction provided and/or the data incompatibility should have been mentioned explicitly and up-front.

  11. As I re-submitted, post-adaption, there was an apparent error text, which read merely that “This field has been corrected.” (or very similar), leaving me uncertain whether further action was necessary. I tried to save again, and was brought back to the same error message. (The page automatically centered on the “error”.) I checked the top and the bottom of the page, in vain, and tried a third time, just in case. I was returned to the same message. I now went through the page in detail and found, a little further down, but outside of the area displayed by the browser after Amazon’s deliberate focus, a request that I confirm the correctness of the correction.

    Not OK.

    The page should have made crystal clear that further action was needed and what action. (Note that the idiotic focus and choice of layout sabotaged this.) Moreover, as I had corrected the field, there should have been no further assumption of error than with any other data entry, making the inquiry/error/whatnot redundant.

Now let us see what future problems occur, including (I very strongly suspect) unsolicited and highly unwanted emails and/or text messages.

Written by michaeleriksson

February 23, 2021 at 12:47 am

Undue checks of values

leave a comment »

A common annoyance with poor software is undue intolerance against values that are, in some sense, faulty. (And, no, this is not a post about the political Left …)

Checks for correctness and consistency can be a great aid, as can automatic warnings of errors. However, often, the baby is thrown out with the bath water.

Consider e.g. Alpine, an email client that I use extensively: It has a field in the configuration to specify the default sender address. Here I have simply specified “@” and my domain because I use a great number* of different user names for different tasks (mostly to reduce the damage when one address falls victim to spammers). The idea is that I have this string pre-filled in the “From” field and then just need to add the right user name.

*Too many for a solution using e.g. Alpine’s role system to be a good alternative.

But what happens? If I begin to compose an email, the “From” field is just filled* with INVALID_ADDRESS@”.SYNTAX-ERROR.” (quote signs present in the original), presumably to indicate its dissatisfaction with the missing user name. The actual value entered by me is neither visible nor retrievable and there is no reasonable world in which this is a good reaction. A check when the user attempts to send, by all means, but not when a default value is retrieved or entered. If there are objections to the default value, they should be uttered when and where the default value is configured;** however, here such objections are not reasonable, as use cases like the above are quite common.

*The actual field. Contrast this with keeping the “faulty” value and displaying a warning message next to it. (Which also would have been acceptable.) Writing this, I begin to suspect that this is not so much a deliberate choice as poor programming, that there is an internal consistency check when retrieving the value, that this check gives an unnecessary error message, and that the error message is blindly taken over as the value.

**This is not the case with Alpine. The explanation might be that the the entry mask deliberately has a tolerance that is later arbitrarily removed, or that this config value is part of a larger string, which is not parsed or verified at the time of entry.

The result is that I have to delete the error message, write the user name, and copy the remainder of the address from elsewhere, i.e. one step more than without this configuration and two steps more than if it had worked reasonably. Time to remove it …

Of course, these extra steps occasionally lead to errors. For instance, when I use post-by-email with WordPress, I usually just “reply” to the last post, switch out Subject and Body, and re-enter* the email address. But today, with the three steps needed for the email address, I forgot the Subject and published a text under the same title as the previous (entirely unrelated) text …

*No, Alpine is not smart enough to handle replies to own messages correctly, i.e. that the old address is kept. Instead, the configured one is used (if present, else the field is, probably, empty).

Other examples include e.g. applications that prevent any entry of faulty information, even without saving*, e.g. that a numerical value using a decimal point is not allowed in a German application expecting a decimal comma. Then, instead of copying a (read-only) value from a PDF file or output from a calculator into the field, changing the point to a comma, and then continuing, the user is forced to copy the value, paste it in an editor, edit the point to a comma, re-copy it, and then paste it in the field.** Or consider fields that allow entry of most, but not all, legal values or makes normally optional parts mandatory.***

*In many cases, even the saving of faulty values can be beneficial, e.g. that a numeric field can be filled with a “TODO”, and that the application merely gives a warning that the input is faulty. However, this is not always trivial and rarely worth the benefit, as it might require switching a numeric internal data type to a string data type or similar.

**Yes, this could be solved e.g. by some type of keyboard macro, but it is not a sufficiently common scenario to be worth the trouble—in stark contrast to writing a better functioning field that e.g. allows entry of any value and just shows a warning message or allows entry but not saving.

***I do not remember any of the specific cases off the top of my head, but consider, again, email addresses: These can be quite complicated, and e.g. a simplistic name-plus-@-plus-domain parser would disqualify many legitimate versions. Vice versa, an idiotic tool could make the idiotic display name idiotically mandatory.

Written by michaeleriksson

July 26, 2020 at 2:36 pm

Odd usability decisions and rsync

leave a comment »

One of the most popular tools among e.g. software administrators is rsync, which allows efficient and flexible synchronization of files between different directories—even when located on different servers.

However, every second time that I use it, I feel like tearing my hair in frustration:

For some reason, the makers of rsync decided to implement something better governed by flags through obscure and unintuitive “directory semantics” (for want of a better word) and the behavior of rsync varies depending on whether a source and/or destination directory has a trailing directory separator*. Moreover this behavior is incompatible with almost any other tool, including the Unix command cp, for which it is a natural replacement.** Indeed, I would go as far as calling it a “best practice” to normalize directory inputs with a directory separator to exclude*** it before further processing, in order to ensure that both cases are handled identically and to avoid programming errors through assuming that a directory separator has to be added (or removed) at some later stage, e.g. when specifying the name of a new sub-directory to be created. Of course, here we have an other reason why rsync’s behavior is unfortunate: in a programmatic context, a normalized directory could lead to a very different behavior from the intended—as could a minor slip of the keyboard.

*In the Unix world, a slash resp. “/”. I have not investigated the behavior on other systems, including whether rsync is tied to the slash or the local directory separator, but I go with the more generic term for now.

**The cp command CoPies files and directories. In most cases, it is perfectly good at this, but rsync can be a superior choice for the same task in certain circumstances. Consider, e.g., copying between two servers over an imperfect network connection. If the connection fails during a use of cp, one can either start over from scratch or spend time with a manual clean up, and even then a partially transmitted file has to be re-transmitted from scratch. With rsync, the command can be repeated and the download will automatically be resumed with little overhead. (Interestingly, rsync can be used to save an interrupted cp, but then why not use rsync to begin with?)

***Why “exclude”? In part, through convention; in part, because the directory separator is not a part of the name of the directory, and it makes little sense to keep it at the end of a directory, even when given through a full path, when there is no further sub-directory that it could separate.

Specifically, I am ever again caught by the trailing directory separator of the source directory leading to a different treatment of the destination directory.* If a trailing directory separator is present, the files of the input directory are put directly into the output directory; if it is absent, they are put into a sub-directory** with the same name as the input directory. Not only is this very easy to forget, and not only is this highly counter-intuitive, but the standard file-name completion of e.g. Bash automatically adds a trailing slash when it expands a directory name, implying that the user who has used completion to generate the name has to explicitly think about removing that slash (should it not be wanted in conjuncture with rsync—in almost any other context it will be either wanted or irrelevant).

*At least in terms of manifestation. Conceptually, it might possibly be argued to that the source directory is treated differently. Cf. the rsync–cp comparison that follows.

**Created, should it not already be present. I suspect that the original motivation for these special behaviors related to the complication that such a sub-directory could or could not already be present.

For comparison: “cp -r x y”, “cp -r x/ y”, “cp -r x y/”, and “cp -r x/ y/” all do the same thing—they copy the directory x to the directory y, where there will be a new sub-directory with the appropriate name. In contrast, “cp -r x/* y” (or “cp x/* y/”; in both cases, note the asterisk, which here does not point to a footnote) copies the individual files and sub-directories present in x to y.* An “rsync -r x y” does the same** as the first four cp commands; “rsync -r x/ y” does the same** as the fifth (and sixth).

*Excepting “hidden files”, as the “*” is expanded thus by Bash and shells in the same family. Other shells might have a different behavior. Writing this footnote, I suspect that this could be another clue to the origins of rsync’s idiosyncratic behavior—a poorly thought-through attempt to reduce the dependency on the shell (or scripting language) used.

**With reservations for details, e.g. that cp might give an error and/or ask for a user decision when it tries to copy something which already exists or that, cf. above, cp-with-Bash is more restrictive in terms of hidden files.

Pure insanity.

How to do it better? Well, one option, would be to just have a flag that indicates whether the input directory, it self, should be copied or just its contents—while any trailing slashes are entirely ignored.

Excursion on (and reservation for) flags:
The behavior of these commands can vary considerably depending on what flags are given. The rsync “r” flag is roughly equivalent to the “cp” one, according to documentation, and I use it for consistency between examples. In practical use, I almost always call rsync with “avz”, of which the “a” includes the full effect of “r”. I have “cp” aliased to ‘cp -i”, which increases the “interactiveness”, in case of name collisions, over the “vanilla” cp. (Similarly, I have “mv” aliased to “mv -i”.)

Written by michaeleriksson

May 31, 2020 at 2:40 pm

Posted in Uncategorized

Tagged with , , , ,

CAPTCHAs and forced JavaScript

leave a comment »

An increasingly common annoyance, at least for us Tor users, are CAPTCHAs that are impossible to overcome without JavaScript* activated. Worse, an increasing number of sites seem to use “JavaScript is not enabled” as a heuristic for “is a bot”. The point might come where even a security-minded and well informed user is forced to surf with JavaScript activated in a near-blanket manner just to satisfy such checks and to handle such CAPTCHAs, while the site visited, per se, would have worked well anyway. A particular problem is Cloudscape, which in multiple ways is a threat to usability, anonymity, and security for the end users, due to the extreme number of sites that route their contents over the Cloudscape network—a very significant portion of these CAPTCHA requests stem from Cloudscape.

*I highly doubt that JavaScript, or even images, are necessary in order to implement any level of CAPTCHA protection, in terms of difficulty of automatic solving. More likely, the current JavaScript-and-images construct is chosen through a mixture of laziness and a wish to apply the no-JavaScript heuristic mentioned above. (Possibly, combined with an analog no-images or even a no-cookies heuristic.) However, I will not go into this below.

However, JavaScript is a severe hazard, its use in combination with Tor is almost always brainless*, and I would generally, even for non-Tor users, recommend that it only be activated on a case-by-case basis and on sites with a great degree of trust. Such sites cannot include those with a presence of content not under strict control by the site, which rules out, among others, any site using an advertising network**, the whole of Wikipedia***, and all search services****. (As a bonus, most sites intended for reading are more enjoyable with JavaScript off, e.g. due to less or less intrusive advertising and fewer annoying animations. Other sites, unfortunately, are often so misprogrammed that they simply do not work without JavaScript.)

*The main purpose of Tor is anonymity and no-one who has JavaScript activated has any guarantee of anonymity anymore. Even a selective activation of JavaScript for chosen sites (e.g. by the NoScript plugin) can help with profiling and, indirectly, threaten anonymity—even without e.g. a JavaScript attempt to spy on the user.

**The ads come from a third party and can contain hostile content.

***Wikipedia can be edited by more-or-less anyone and could, at least until detection, contain hostile content.

****Search services display foreign content as a core part of their service, and with insufficient sanitizing, someone could smuggle in hostile content. (Even ambitious sanitizing can overlook something, run into bugs, or otherwise be flawed.) Of course, search services also often serve content from an advertising network …

The last few days, Startpage, my currently preferred search service, has thrown up CAPTCHA-with-JavaScript requests at such a rate that I will be forced to switch again, should the situation not improve.

Specifically, I am, again and again, met with the text:

JavaScript appears to be disabled in your web browser. To complete the CAPTCHA, please enable JavaScript and reload the page.

As part of StartPage’s ongoing mission to provide the best experience for our users, we occasionally need to confirm that you are a legitimate user. Completing the CAPTCHA below helps us reduce abuse and improve the quality of our services.

The best that can be said about this, is that it does not make the (otherwise common and highly ignorant) claim that my browser would be outdated or not support JavaScript.

Firstly, a search site is (cf. above) not a place to ever activate JavaScript. Secondly, the legitimacy of a CAPTCHA, at all, is highly dubious. Thirdly, in as far as a legitimate* reason is present, the cited reason is not it. Fourthly, there is nothing “occasionally” about it—today, I have been hit about ten times for about a dozen searches. Fifthly, the talk of “best experience” (and so on) seems almost insulting, considering the quality problems of Startpage**.

*E.g. that the IP from which the current request comes has sent a very great number of request in a very short time span.

**And DuckDuckGo, etc. If anything, these Google-alternatives appear to grow worse over time. Outside the search services that are known or strongly suspected to engage in user-tracking and profiling, are involved with advertising networks, or similar, I know of no truly good alternative since the demise of Scroogle—and that might have been close to ten years ago.

In fact, when I see a combination of such an implausible* message and such a high frequency of CAPTCHAs, I must at least suspect that this is a deliberate attempt to either drive Tor users away or to force users to surf with JavaScript enabled. Whether this is so specifically with Startpage, I cannot know, but that it is the case with at least some sites out there is almost a given.

*In contrast to e.g. “We have seen some odd activity from your IP. Please confirm that you are a human user.”.

As an aside, the use of CAPTCHAs to solve the perceived problem is disputable on several counts, including that CAPTCHAs can often be solved by clever bots, that they can pose great problems to many human users, including those less-than-bright or of weak eye sight,* and that better solutions might be available, e.g. that IPs with a large amount of requests see an artificial delay before treatment**. To boot, it can make great sense to investigate whether a block of bots makes sense, as they are often beneficial or neutral, or whether a block based on amount of traffic, irrespective of the human vs. bot issues, would be better.*** Certainly, a CAPTCHA-based block on bots should only be contemplated if means like the use of a robots.txt (which, in all fairness, is quite often ignored) have failed.

*But even very bright people who can read the text well can run into problems. I have myself sometime failed because it has been unclear e.g. whether a certain character was a distorted “O” (Upper-case letter), a distorted “o” (lower-case letter), or a distorted “0” (digit).

**This has the advantage of serving everyone, while keeping the situation acceptable for a human who makes one or two requests, and while posing a major problem for a bot that makes a few thousand requests.

***This especially with an eye on the truly problematic bots—those that perform denial-of-service attacks.

Startpage does have a robots.txt, which manifestly does not attempt to exclude bots from the page that I have accessed—a further stroke against it:

User-agent: *
Disallow: /cgi-bin/
Disallow: /do/
Noindex: /cgi-bin/
Noindex: /do/

Written by michaeleriksson

April 29, 2020 at 10:35 am

Follow-up: Stay away from Unitymedia

leave a comment »

The saga of the inexcusable customer hostility of Unitymedia continues:

My most recent problems had long resulted in no reaction whatsoever from Unitymedia (not counting automatic confirmations of receipt), until the 28th of February, almost a month after my first marked-as-urgent (!) query.

This reaction first came in the form of another* “please confirm your email address” email, again with a body consisting just of the text “null”**. Of course, this is entirely pointless, because I have terminated the contract with Unitymedia and have no intention whatsoever of confirming, registering, or whatnot anything—and this should have been obvious even to Unitymedia.

*As I speculate, based on previous interactions, every time a Unitymedia staffer gets her hands on an email address, the first thing she does is to create some type of online account for this email address. Once it is created, automatic emails are sent badgering the user to confirm this email address—even when he has no interest in this account.

**Either the email is basically empty or it is made out of such poor HTML that my email client cannot convert it to something readable. Using HTML, per se, is wrong in an email (and especially business email); using severely broken HTML is inexcusable. I note that this problem was present already during my first contacts with Unitymedia several years ago, and that I pointed it out explicitly: not correcting a known problem with inexcusable behavior over several years is doubly inexcusable.

This email I just saved in my Unitymedia folder and wrote it off as yet another proof of gross incompetence. Worse is to come, however:

Later the same day, I received a (readable, but extremely poorly formatted) email from a human. First claim: “Bitte entschuldigen Sie die ungewohnt lange Bearbeitungsdauer.” (“Please excuse the unusually long treatment [processing?] time.”) Under no circumstances will I excuse an almost month-long response time to a message marked as urgent—a time during which, important, not even a message of “we are sorry, but there will be several weeks before we can get back to you” arrived. Even now, an explanation for the delay was missing.

Next claim: She was sending a replacement router. Why?!?! I have TERMINATED my account! I have no interest in anything relating to Unitymedia and under no circumstance will I bother with collecting a package from Unitymedia, renew my troubleshooting, and whatnot for an account that I do not want!

Various other claims were equally idiotic, like that I should give her my telephone number, that she would check whether compensation was possible after my connection had been restored (Why the hell would that be relevant? Why should I go by her opinion on the matter?), a one-sided rejection of any damage claims (for a more* than month-long service interruption), and a request that I manually transfer allegedly outstanding fees.

*In a best case scenario, I would receive the new router (cf. below) tomorrow, March 6th, 34 days after my first email for assistance—and 41 days after the likely occurrence of the problem (January 24th, based on router logs). Factoring in my experiences with e.g. DHL, I doubt that I would have had the package, even would I try to receive it, before Monday, the 9th, for another three days and a total of a-month-and-a-half.

A particular absurdity is the claim “Wunschgemäß habe ich Ihnen einen Retourenschein zugesandt. Sie können Ihren Vertrag nicht allein durch die Rückgabe des Zubehörs kündigen. Die monatlichen Beträge werden weiterhin berechnet.” (in paraphrase: I have sent you the requested pre-address return label*, but you cannot terminate the account just by sending back the equipment and we will continue to charge monthly fees.). Considering that I have explicitly (!) terminated my account, the return of the equipment (i.e. router, etc.) is secondary, and was certainly not the means of my termination. Unitymedia has no basis whatsoever for continuing to charge monthly fees, and this seems like an outright fraudulent attempt to trick unsavvy customers into continuing an unwanted, intolerable, and unconscionable contract.

*I have not found a good translation for “Retourenschein”, but I do not that it has yet to arrive. Further, that I had explicitly requested a pre-paid one, and whether that will be the case is yet to see.

I replied with harsh email stating that I remained as a non-customer and would* outright block the used email address. About a week later, this email has seen no reaction, but I have received a notification that “my” package, presumably with the replacement router, would now be underway (earlier today, March 5th). I have also noted that Unitymedia has made an illegal “Lastschrift” withdrawal from my account, despite my having terminated the corresponding permission and despite an alleged (according to the above email) switch from Lastschrift to manual transfer for my account.

*And will, but I have not yet gotten around to it. It is the very next thing on my todo list after publishing this text …

Written by michaeleriksson

March 5, 2020 at 11:41 am

Stay away from Unitymedia

with 2 comments

I have repeatedly, but highly incompletely, written about my problems with Unitymedia (cf. [1], [2], [3]).

The original problems eventually resolved themselves through my efforts, with not one iota of help from Unitymedia. However, as of January 24th, my connection is gone again and nothing seems to help. Contacting Unitymedia has been hard, because, of course, my telephone runs over the same connection and is also not functioning.* An attempt to visit one of Unitymedia’s stores failed due to it being closed in the middle of the day.**

*I do not currently have a cell-phone; however, due to problems like these, the extreme restrictions on e.g. credit-card payments without a cell- or even smart-phone, etc., I am currently looking into the topic again. Effectively, individuals without a cell-, increasingly smart-, phone are put in an evermore unconscionable situation, have it ever harder to function in a smartphone-centric society.

**And I strongly suspect that I would have been turned out again with a “Call the hot-line. We only sell subscriptions and refuse to help in any way, shape, or form.” had it been open.

Over the weekend, I moved a planned visit to Mönchengladbach ahead; and used the WIFI in my hotel room to send an email, including a detailed description of the problem and my counter-measures, and to do research on various related topics.

Despite my email being marked as “urgent”, I have still not, five days later, received a reply of any type (except an automatic confirmation of receipt) and my connection is still unusable. Correspondingly, I have today terminated my contract(s) with Unitymedia, effective immediately.

Excursion on my current situation:
I am currently, based on my research, using a near-by Deutsche Telekom hotspot, which is actually cheaper per month and seems to have a considerably lower latency (and/or otherwise let me surf faster). On the downside, there is an automatic disconnect every six hours, the maximal through-put is lower (but not too low), and I do stand a risk that the hotspot is turned off at some point (has not happened during these few days). Long-term, this might be replaceable with a mobile subscription and tethering, but at the moment I am kept back by the poor conditions in Germany. There are recently some true* flatrates, but these go at 85 (?) Euro per month with a 24-month minimum subscription, which does not leave me enthusiastic. Non-flatrates invariably have an upper limit on the high-speed traffic which is much too low for the money paid, while the providers praise the high speed and hope that the customers are too stupid to calculate how short a time that speed is usable before the limit is hit.**

*As opposed to the pseudo-flatrates often claimed to be flatrates, where the user has a few GB per month to surf at high speed with, after which the speed is dropped to the level of an ISDN connection.

**Useless speed-promises are extremely common. For instance, Unitymedia raves about how it can deliver up to 400 Megabit/s, but only rarely will even several parallel users actually benefit from that rate. In my case, the WIFI on my (possibly outdated) notebook could not handle more than a fraction of that rate and even my old 100 Mbit/s subscription was overkill. (Specifically, the highest numbers I have seen during download have been around 50 Mbit/s, resp. 6.x MB/s.)

Written by michaeleriksson

February 6, 2020 at 10:06 pm

Email addresses and the abomination of a display name

with one comment

A strong case can be made that various Internet standards created before the Eternal September, the commercialization of the Internet, the (once) dominance of Internet Explorer, … where superior to what came later.* One interesting counter-point is the “display name” of an email address, which has annoyed me for ages. This idiocy appears** to be present as far back as RFC 822 in 1982, possibly even earlier, depending on what implementations predated this document. (My own history on the Internet “only” goes back to 1994.)

*Of course, allowing for deficiencies due to a smaller amount of practical experience and a changing world.

**RFC 822 gives “mailbox” as “addr-spec” (i.e. a proper email address) or “phrase route-addr”, which seems to match the idiocy under discussion. Its 2001 replacement, RFC 2822, actually uses “display name” in its descriptions.

In effect, instead of using an email address like “john.smith@example.com”, senders are allowed to use e.g. “donald.trump@whitehouse.gov <john.smith@example.com>”.* Here “Donald.Trump@whitehouse.gov” is the display name, which has no actual impact on the email handling. Of course, John could equally use “Trump”, “Hillary Clinton”, “mermaid lover”, or “info”.

*There might be cases where additional escaping or use of quotations marks is needed. I have not investigated this in detail, and I deliberately do not wish to include quotation marks in the examples, even at the risk of a slight inaccuracy, due to incompetent handling by WordPress.

Here we see the first problem: The display name is highly unreliable. Not only can it be used to try to fool the email-illiterate user into making incorrect assumptions, but major confusion can arise when one party switches* display name between two emails, or when several parties use the same** display name. This problem is made the worse, because some email clients rely very strongly on the display name, e.g. in that only the display name is present in overviews of a mailbox (at all or per default). Indeed, even when the email address is displayed, the display name can make it less accessible, e.g. through pushing relevant parts out of sight.

*Say that someone started with “John” and switched to “John Smith”, because there were other Johns; or that someone went with “John Smith” professionally and “Johnny Boy” when writing his family, and that some recipient was both a family member and a professional contact.

**With “info” being the paramount example. In contrast, the email address proper is unique. (But note potential complications like equally ill-advised attempts to allow generic Unicode characters, which might cause e.g. an apparent Latin “A” to be exactly that in one address and and a Greek capital alpha in another.)

A particular complication is mailing lists: Because the sender determines the display name used for the mailing-list address, the eventual recipients can receive dozens of display names for the same mailing list. I can still recall trying to automatically put emails from one or two mailing lists into different folders at work—we were stuck with Outlook, Outlook only allowed filters* based on display name, and even with half-a-dozen alternative display names appended to the filter I regularly found emails that by-passed the filter… Of course, if emails to two different mail-lists used the same display name, filtering would be done incorrectly… (But, in all fairness, these were more Outlook issues than email-specification issues.)

*With reservations for terminology. I have not used Outlook in a good long while.

Another issue is that this feature is mis-designed (even its existence aside): now parsers need to handle two inconsistent formats, writers of emails need to understand two formats, etc. Indeed, because the display name can be empty, a parser needs to handle both “john.smith@example.com” and “<john.smith@example.com>”—and if faced with “john.smith@example.com”, it can only conclude that this actually is an email address (not a display name) after having noted that a “<>” expression does not follow. Absolutely amateurish… A better solution would be to put the display name in angle brackets, which allows for easier and more consistent parsing, and is less likely to cause misunderstandings (i.e. “<Johnny Boy> john.smith@example.com”, not “Johnny Boy <john.smith@example.com>”).

A minor potential advantage is the ability to replace a non-descript email address with something easier for the recipient to recognize. I note e.g. that my own first email address (provided by my college and based on my user name in its systems) was something like “f94-per@nada.kth.se”*. However, the advantage was very minor even back then, very few are stuck with such addresses today,** and that “john.smith@example.com” is named “John Smith” does not need additional mention. If worst come to worst, the (claimed) identity should be clear from the email body, even if at some loss of comfort. Schemes like allowing several people to use the same email account with different pseudo-identities are highly disputable, and it is better to either give them separate accounts or to not use pseudo-identities with the one account at all, because they are likely to do more harm than good. (As an example, a customer-service department should not use the names of individual co-workers as display names for one common account.)

*Do not try it. Chances are that I misremember the details, my last log-in was likely in the late 1990s, and I have no idea what my password might be—even should the account still be functional… The local part, should anyone be interested, comprises a program-of-study identificator (“f”, in my case), the year of enrollment, (a hyphen,) and some letters from the student’s name.

**Or they have only themselves to blame for registering using the likes of “ahf38js” (instead of e.g. “john.smith384”) when a name is already taken.

Unfortunately, display names see heavy use and I very often even receive email back, where my sender address has been abused as a faked display name (i.e. if someone uses just the email address proper, e.g. “john.smith@example.com”, he receives a “john.smith@example.com <john.smith@example.com>” back). This is utterly pointless on two counts: firstly, it adds no information compared to just using the address proper; secondly, it unnecessarily forces the use of one format when the other would have done just fine. Outlook, as already mentioned, seems to consider the display name more important than the actual email address. Certainly, the display names picked by the sender, especially in a commercial context, are often quite poor—as with “info” (why not include the company name?!?) and other very generic phrases.

Written by michaeleriksson

July 9, 2019 at 7:08 pm

WordPress and its user-hostile administration area

leave a comment »

And don’t you believe it: The morons from WordPress still managed to introduce links where they do not belong, despite use of quotation marks.

Written by michaeleriksson

April 8, 2019 at 11:08 am

WordPress and its user-hostile administration area

with one comment

As I tried to refresh a page from my WordPress account earlier today, I found that I had been logged out.* More specifically, I was forcefully lead to (what I assume was) a log-in page that simply did not work or show anything useful, but which complained about a lack of JavaScript. (No, activating JavaScript did not help.) After digging around, I found a log-in page that did work, logged in—and found myself in some version of the administration area that did not even slightly resemble what I was used to, and which simply did not work—with or without JavaScript activated. Problems included incomplete displays, “my sites” simply not being found, and (browser-side) warnings about a possible XSS** attack by a “doubleclick.net” address***.

*Having a dedicated user-account and browser for WordPress, I have no qualms about never logging out manually. Automatic log-outs, on the other hand, are so rare that I cannot even recall the previous time that it happened (or whether I had similar problems back then).

**Cross-site scripting: Roughly speaking, an attempt to cause mischief for a user by including JavaScript from one site into another, in order to circumvent the user’s and browser’s security controls/checks/awareness/whatnot.

***Presumably, a part of Google’s advertising efforts that still carries the name of the former “DoubleClick” brand. The alarm is likely a false positive to the degree that this is almost certainly is not caused by an illegal activity; however, (a) users are still better off without it, e.g. for privacy reasons, (b) the integration into the WordPress pages is obviously not done sufficiently well.

After wasting five to ten minutes trying this-and-that, I contemplated simply foregoing WordPress entirely and effective immediately*, but resorted to a last ditch attempt: One of my old tabs contained a page from the (familiar) admin area. I copy-and-past-ed** it into a new tab, and things suddenly worked as they should.

*WordPress sucks, and I have long-standing plans to move away anyway. However, time constraints and the many other things that I do has postponed this ever again.

**Just re-loading would likely have worked equally well, but keeping the old tab intact gave me a better chance at a second attempt, should something go wrong.

The difference is likely that this link already led to the blog specific admin area, which still works as it should; while what was served after log-in was a user account admin area.* Should the above happen to you (or me, at a future time): Look at the URL. If it begins with “https://wordpress.com/me”, you are probably stuck in the user level area, and you should try to get to the blog area, which will begin with “https://michaeleriksson.wordpress.com/”**. The “dashboard” of the blog administration can then be found under “https://michaeleriksson.wordpress.com/wp-admin/index.php”**, from where other parts of the administration can be found. (In all cases, with reservations for future changes.)

*There can be more than one blog associated with each user account.

**For my main WordPress blog. Please substitute your own blog name/address as appropriate. Also see excursion below.

Excursion on WordPress, incompetent handling of post-by-email, and how this can influence a text:
I have written repeatedly of how WordPress handles post-by-email incompetently, e.g. through introduction of artificial links. This text provides a good example: without the quotation marks around “doubleclick.net” above, it might have been mangled into “http://doubleclick.net” and turned into a link, which is not only contrary to the purpose of use above, but could also be highly confusing to the reader. Knowing of this issue, I resorted to add quotation marks where I would not normally have used them.

The use of e.g. “https://michaeleriksson.wordpress.com/” above is yet another example of why WordPress handles links poorly: I do not intend to link—only to make a statement of how a link would begin. Indeed, going directly to this address would show the published blog—not the administration area. (But here, I would have used quotation marks anyway, because I discuss strings.) Further, “https://michaeleriksson.wordpress.com” would normally have called for a use of place-holders, e.g. in that I had replaced “michaeleriksson” with “[your blog]”. I refrained from doing so, because I see at least a risk* of mangling.

*I have made good experiences with quoting, which seems to protect the text, but if I find an exception I would need to research a work-around, edit, and/or re-publish the text, which would cost me time and energy. To boot, this would involve a delay and inconsistent texts being sent to subscribers. Better then to take the safe road.

Written by michaeleriksson

April 8, 2019 at 11:04 am

Follow-up: The misadventures of a prospective traveler

with one comment

Recently, I had great problems booking an airplane ticket to Sweden, ultimately resorting to using a travel agency, which required both an unnecessary fee and a trip on foot.

For my return to Germany, my seasoned-traveler father booked the ticket from his computer.* While this worked in one go, the service that he ended up using (“supersavertravel”) was abysmal: The entire interface seemed geared at one thing and thing only—to coerce the user into buying expensive additional services that he did not need. This to the point that it was necessary to explicitly decline these many services and to do so individually—no, I do not want a hotel; no, I do not want extra insurance; no I do not want a rental car; no, …; no, …; no, …; no, …; no, …; no, …; no, …; no, …; no, …; … I even seem to recall (but could be wrong) that there was an additional query after submit along the lines of “You have not chosen this-or-that. Are you really sure that this is deliberate?”… Utterly inexcusable was the checkbox to decline spam: Where more main-stream businesses use a checked checkbox to imply “I consent to be spammed”, here the user needed to check the checkbox to decline spam…** The confirmation email, unsurprisingly, contained much more advertising and attempts to bring unneeded services to my attention than it did confirmation…***

*I had left my own computer in Germany in order to travel lightly; and only bought a one-way ticket to Sweden, because I did not know how long I needed to stay.

**Implying that the main idea almost certainly was to trick users into making the wrong choice.

***This in stark contrast to EuroWings below, where the confirmation email was informative, to the point, and did not even abuse HTML for the email text. (Portions of [1] contain some discussion of why HTML has no place in emails.)

A second trip turned out to be needed.* I tried EuroWings again, and this time everything actually worked.** However:

*My mother’s old house is being sold, and the time needed to sort through my own old books and whatnot turned out to be much longer than I originally thought.

**Contrast this with the original text. This time, I made sure to pay by credit card (3D-secure was not needed) instead of invoice. I do not know whether the old issue was a temporary server-side problem, a problem with a workflow somewhere, or whether there is some problem relating to invoices that I now ducked. (Regarding workflow: In my experience, most QA checks tend to run through fairly straight-forward scenarios, meaning that a scenario that involves the user e.g. going back to a previous step, responding to a validation error, actually reading the T-&-C’s, whatnot, is often left untested. These scenarios, however, are disproportionately likely to cause errors—especially when Ajax and other “state sensitive” technologies are used.)

  1. EuroWings too tried to advertise additional services, if far fewer, in a manner that detracted considerably from usability and prolonged the process unnecessarily. Unlike with “supersavertravel”, they were all opt-in, but it would be so much better if they were all collectively moved to a separate and skippable step, especially since they will only ever be interesting for a small minority of the customers. (Be it because they have no need, already have made other arrangements, would lose points with some program by booking/buying somewhere else, …)

    Hotels are a potentially odd area. In the specific context of a flight, admittedly, I can see many cases where it would be helpful to “co-book” a hotel. However, hotels are offered more-or-less everywhere, including for e.g. train-travel. In most of these cases, booking a hotel together with the means of travel turns the reasonable workflow on its head: It is usually the hotel, not the means of travel, that is the bottle-neck, and a reasonable workflow would then involve finding and booking a hotel first and finding means of travel second.

  2. Integrating a please-do-not-spam-me checkbox in the main pages would be trivial. Nevertheless, declining spam is only possible through visiting a separate page. On this page, moreover, the email address has to be added redundantly and manually, and it could be (depending on internals and the exact steps used by the customer) that the spam rejection only takes effect after the fact, e.g. in that the one click somewhere activates an unethical implicit consent to spam, while the other page only revokes this consent. This would leave a window of abuse open.

    Frankly, this is so common that legal measures are necessary: It must by law be forbidden both to use implicit consents and to require explicit rejections for any use of personal data (in general, but the more so for email data) that is not central to the process for which the data was provided. This, notably, from the customers perspective—not the data collector’s. (For instance, the data collector might see sending a news letter with advertising as a central part and having to send a confirmation email as an annoying negative, but for the customer it is the other way around.)

  3. There are potentially redundant entries for email, including one for the actual transaction and one for please-notify-me-in-case-of-delays. It would be better to keep them as one per default (if in doubt by automatically filling the one with the other and allowing a manual change). Further, the entries are likely made in the wrong order for most users, with a non-mandatory entry of please-notify-me-in-case-of-delays on one page and the mandatory actual transaction address on a later page. Further, the former came with a pop-up upon submit that urged me to fill in this non-mandatory field anyway—which seems more like fishing for email addresses than an attempt to provide a service.

    Why had I left the email address out? Well, I knew from my earlier attempts* that if I did provide an email address for notifications, then I would also be forced to provide a cell-phone** number—absolutely idiotic.

    *The attempts in general are described in the original text, but details like the above were left out.

    **Note that I currently do not even have a cell-phone. Also note that cell-phones too can be abused for spam (through SMS).

Written by michaeleriksson

February 25, 2019 at 1:08 am