Michael Eriksson's Blog

A Swede in Germany

Posts Tagged ‘web design

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

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 , , , ,

Follow-up: My recent problems with Unitymedia

leave a comment »

The situation around Unitymedia (cf. [1], [2]) remains extremely frustrating:

  1. My support inquiry is still unanswered, despite a reminder.
  2. I still cannot use the main Internet connection of my apartment.
  3. While I am able to use the hotspot functionality as a workaround, it is (not unexpectedly) considerably slower than my real connection used to be. To boot, there are continual, highly annoying interruptions, leading to e.g. SSH sessions dying and needing a restart, and “ping”* does not work at all. Not to forget: This type of access is inherently more dangerous than the regular use, because it is easier for a hostile entity to listen in on and/or manipulate the communication.

    *Neither does e.g. “traceroute”, and I suspect that the entire ICMP is blocked, which would border on the negligent, seeing that this protocol has an import role in ensuring correctness and efficiency of Internet communications. (Blocking just specifically ping is dubious, but might be somewhat excusable due to its occasional abuse for denial-of-service attacks. For me, however, the lack of ping is a major nuisance, since I need to keep an eye on a few servers, and ping is the best way to do this; especially when reachability problems can be either a server-side problem or a connection problem, as is currently the case.)

  4. The miserable web interface of the router* works better in the newly installed Chromium than it did in Firefox; however, the situation is not satisfactory: Approximately every second attempt to run the built-in trouble-shooting results in a long wait and then an unspecified failure; every second results in a long wait and the claim that everything would now be OK—while de facto everything remains just as broken as before.

    *I note that the router is provided by and is the property of Unitymedia, with the implication that problems, malfunctions, whatnot, are Unitymedia’s responsibility—not e.g. those of an independent retailer.

Written by michaeleriksson

April 1, 2018 at 7:24 pm

My recent problems with Unitymedia

with 2 comments

Incompetent and user/customer hostile businesses has been a recurring theme in my writings. My experiences with Unitymedia rank among the very worst, however.

Problems until recently were mostly limited to abusing my email address for spam. However, the developments in the last two weeks are utterly inexcusable. Even in a somewhat abbreviated listing:

  1. Visiting my apartment in Wuppertal for pre-sabbatical preparations*, where I have had an Internet connection from Unitymedia for almost a year-and-a-half, I find that the connection no longer worked. This after my only using it for a total of roughly two months, due to my long absences, and now that I finally was going to use it on a daily basis for the foreseeable future.

    *Cf. a previous post.

  2. I attempt to trouble-shoot through the web interface of the router—only to find that the web interface simply does not work with my Firefox. This without any messages as to why, no “please activate X”, or anything indicating that something was amiss—apart from things not working. For instance, a button that was to be pressed was not visible; for instance, after finding the invisible button and pressing it, nothing happened.

    This state persisted after I had verified that all the likely complications, including cookies, JavaScript, and images, where activated and functioning.

    Having limited time, I (temporarily) gave up and focused on other things.

  3. Back in Cologne, I tried to log in to the customer area of Unitymedia’s website. This was not possible, with repeated errors of

    Bad Request

    Your browser sent a request that this server could not understand.

  4. I also investigated Unitymedia’s WiFi hotspots*, hoping to use them as a work-around. This was fruitless, with no information easily found (but compare below).

    *Every (WiFi-)router is per default enabled as a hotspot for other Unitymedia customers, implying that they can access the Internet without extra cost when away from their own routers. (Assuming that another router is sufficiently close by.)

  5. I now contacted customer service per email, giving a detailed record of events and including my last invoice number (the customer number not being obvious from any of the information available in Cologne).

    The result was a pure boiler-plate email claiming that my customer account could not be found based on the data given—utterly absurd since I copy-and-pasted the invoice number. (And have subsequently verified that I sent the correct number.)

    Worse: This email committed many of the sins I discuss in a previous post, including altering the subject line and not including the original message—and added one entirely new: The sender was replaced by a “no-reply” address in an ongoing conversation. These are inexcusable in any context (cf. the linked-to post), but in an ongoing conversation?!?!? Effectively, I have to go back to a previous message and copy the recipient address from there in order to reply!!! An absolute and utter travesty of email use.

    Whether Unitymedia is just utterly incompetent or are deliberately trying to sabotage email communications*, I do not know. Either which way, this is so far beyond the acceptable that the decision maker should be summarily fired for this alone.

    *For some reason, many businesses appear to be extremely email adverse and/or view email as a pure one-way channel for them to send messages, mostly spam, to their customers. Common problems include hiding email addresses, taking any chance to ask the customer to call customer service instead, trying to divert customers to Facebook instead of email, … On a few occasions, I have even had emails to officially publicized addresses be given an automatic response of “please use our contact form instead”.

  6. I sent back further (redundant!) information, and now Unitymedia apparently did manage to find me. However, instead of addressing the issues at hand, a message amounting to “we tried to call you; please call us back” was given—something which is entirely pointless, seeing that I am not in Wuppertal at the moment… Worse: Going by the time the email was sent, I and most others would have been at work in the first place—if they had reached me (or whomever) it would have done no-one any good, making the phone call a waste of time. I had described the events in sufficient detail and without being in the presence of the router, there is very little else that I could reasonably have added or tried.

    To boot, I currently have no use for a cell phone and have let my pre-paid SIM expire. Apparently, however, someone who does not have a cell phone is not allowed customer service…

    Also to note: The information that I had additionally requested should have been given per email, not per telephone. If I had wanted information per telephone (extremely error prone), I would have called myself; I sent an email and both common sense and common courtesy requires a reply by email.

    Almost needless to say, this reply also committed all the above email sins…

    As an aside, there are quite large bootstrap problems involved by now: Almost any attempt to open a contract requires leaving a phone number and/or email address—quite often “and”; often specifically a mobile phone number. This even when there is no actual justifiable need; this even when the contract is for e.g. telephone services. When I moved to Düsseldorf in 2011 (?), for instance, the provider I first turned to for telephone and Internet services (Deutsche Telekom) required a pre-existing phone number to even leave the first screen of the process. We could be approaching a state where e.g. an immigrant simply is stuck, not being able to get basic services because he does not already have basic services.

  7. I replied correspondingly, including pointing to the fact that most of the checks Unitymedia should do could or even must be done without my involvement. (For instance, checking that everything is OK with my contract does not require my involvement; correcting errors in Unitymedia’s web pages must not involve me.) This email is still unanswered.
  8. Today, I had grown tired of waiting and not wanting to risk further delays, seeing that I only have the Cologne apartment (and the Internet connection there) until the end of next week, I installed Chromium*, hoping that this would work with the atrocious web pages of Unitymedia. Well, to some approximation, it did. After various hitches, including a password field that refused my securely generated password** and an incorrectly constructed confirmation email***, I finally managed to register and login in.

    *An open source version of Chrome.

    **The best approach to secure passwords is complete randomness. Restrictions like “must contain a digit” can be helpful in slightly protecting idiots who try to use “password” as the actual password, forcing them to move to e.g. “pasSw@w0rd”. However, the emphases is on “slightly” and these restrictions lower the security of random passwords. (Since they are no longer completely random.) The procedure of Unitymedia is made a mockery by insisting on a “security question”, which very, very significantly lowers the security of the password mechanism: A glass window next to a steel door. (The considerably better, even if not perfect, way is to have the ability to send an email with a “reset” link to a pre-defined email address.) As for the security question, I originally tried to use (approximately) “security questions are a bad idea” as the answer. This was rejected as invalid, with no indication of why. (Length? The spaces? After replacing it with a shorter, random string without spaces it worked.) Complete and utter idiots!

    ***The (HTML) email was so poorly written that it did not even render in my email client, appearing to be entirely empty; I was forced to save the email to a text file and to open it manually in a browser. The actually needed contents where several lines of text and a link; the actually provided contents were an order larger due to the inclusion of various information about who was the CEO and whatnot; the actual size of the HTML code was 61406 (!) characters, compared to 1657 for the actual text. (The latter, imprecisely, measured through copying the text from my browser and copying it into the Linux “wc” tool; the former not including several external images, which are incidentally a big “no no” when using HTML emails.) Running the HTML through tidy, a HTML validator, gave no less that 159 (!) warnings.

  9. After navigation through the visually horrifyingly designed pages, with their illogical structure, dodging repeated annoying and uninteresting messages that Unitymedia had wonderful new offers for me, and generally being on the very, very end of my patience, I finally found instructions for how to use the hotspots—with smart phones. A use with computers, even notebooks, is apparently not on the agenda (but I assume that the instructions are sufficiently adaptable that it will be possible).

    However, before use I had to activate the functionality, set a password, and whatnot. Before submitting the corresponding form, I clicked on the link for the Terms-and-Conditions—only to unexpectedly find myself looking at a PDF document within Chromium. I closed it to download and reopen it in a proper PDF viewer—only to find that the tab with my data was gone. (Apparently, the PDF had opened in the same tab.) I re-opened the tab and went back to the original page—only to find that the data I had entered were gone. At this point, I just gave up, wanting to save my blood pressure from a complete disaster.

    (This is of course only partially the fault of Unitymedia. Most of it likely falls on a weird default behavior from Chromium, which incidentally proved to be very frustrating and limiting in other regards too, e.g. in the use of annoying animations and filling the “new tab page” with a redundant Google search page, neither of which appeared to be possible to deactivate through the main settings.)

The web pages of Unitymedia could basically be used as an example for aspiring web designers of how not to do it. I will not attempt a detailed analysis (because that would require me to go back and look at them in corresponding detail, for which I have neither the time nor the patience). However, I do note especially on the visual side the need for excessive scrolling to reach any content, any screen typically containing just a few lines of text—and large, uninteresting images or large swatches of even less interesting empty space. Technically, they provide an excellent example of why Ajax/DHTML/whatnot are rarely a good idea and why it is almost always better to develop regular HTML pages, using vanilla forms, and possibly some very minor piece of JavaScript for some special tasks. Content-wise, the pages are confusing, making it hard for even a very experienced surfer to find the right information. By and large, I would liken the visit to trying to find useful product information in a supermarket flyer.

Written by michaeleriksson

March 22, 2018 at 5:31 pm

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

Tabbed browsing

leave a comment »

One of my pet peeves is sites that screw up tabbed browsing. I have already written an article on How incompetent webdesign breaks tabbed browsing, and will not repeat this discussion here.

However, I am currently in a less than brilliant mode after having added two pages to my blog, despite the anti-tab behaviour of WordPress, and I tend to get rid of my annoyance at things by writing about them:

Carelessly, I clicked on “Add new post” when I wanted to add the first. I soon realized my mistake, and moved on to “Add new page”, keeping the old tab open to copy the contents of the title and main text. So far so good.

Next I proceeded to add the second page, making sure to use “Add new page” to begin with. I made some previews and corrections, was about to hit “Publish”—and noticed that I am somehow on the “Add new post” page again! (Notably, my first attempt at a preview somehow started to reload the wrong tabs.) Now somewhat annoyed, I repeated again, making very, very sure to click on “Add new page”, made another preview, published, and proceeded to make sure that all links are as they should be in the various link listings. To my surprise they were not. I investigated further—and found that the page was somehow published as a post… I delete everything, start over again, and, fortunately, the third time was the charm.

Add to this that the “Preview” functionality is somewhat annoying, using an explicit target page in a manner that also breaks tabbed browsing. Notably, the natural way to open it for an experienced surfer is to manually open a separate background tab and only switch to that tab when (the lengthy) loading is over. The resulting page will, however, not share the target id, which makes for chaos. It would be better to leave these decisions to the user.

(The action names used above are a little approximative, for simplicity.)

Written by michaeleriksson

March 25, 2010 at 10:08 pm