Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘KDP

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.

    OK.

  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