tommorris.org

There has been a great hullabaloo in the last few months about the rise of chatbots, and discussions of “conversational UIs” or, even more radically, the concept of “no UI”—the idea that services might not need a UI at all.

This latter concept is quite interesting: I’ve written in the past about one-shot interactions. For these one-shot interactions, UI is clutter. But chatbots aren’t the answer to that problem: because chatbots are UI, just a different sort of UI. Compare…

Scenario 1: App

1. Alice hears an amazing song playing in a club.
2. Alice pulls out her iPhone and unlocks it by placing her finger on the TouchID sensor.
3. Alice searches on the homescreen for the Shazam app.
4. Alice opens Shazam, then presses the button to start the process of Shazam identifying the song that is currently playing.
5. Alice waits.
6. Alice is told what the song is and offered links to stream it or download it from a variety of streaming and download services that vary depending on the day of the week, the cycle of the moon, and how Shazam’s business development team are feeling this week.

Scenario 2: Chat

Someone at Shazam decides that apps are a bit old-fashioned and decides to build a chatbot. They have read an article on Medium.com that tells them that chatbots are better, and decide to build one based solely on this advice rather than any actual empirical evidence.

1. Alice hears an amazing song playing in a club.
2. Alice pulls out her iPhone and unlocks it by placing her finger on the TouchID sensor.
3. Alice searches on the homescreen for the Facebook Messenger app.
4. Alice opens Facebook Messenger, then locates the existing chat session with the Shazam bot.
5. Alice scrolls back up the chat to work out what the magic phrase she needs to type in to trigger the chatbot into listening to music.
6. Alice waits.
7. Alice is told what the song is and offered whatever extra rich data the chat UI is allowed to show.

As you can see, this is a vast improvement, not because it makes the process less involved or elaborate, but because someone on Medium.com told them that it is new and exciting.

Scenario 3: Idealised One-Shot Interaction

1. Alice hears an amazing song playing in a club.
2. Alice taps a button on her smartwatch. Everything else happens in the background. Alice continues partying and enjoying herself rather than being the saddo staring at her phone all night.

For those without a smartwatch, a lockscreen button on the phone could be substituted.

Anyway, this is a slight distraction from the broader point: chatbots are a bit of a silly fashion and a fad and that they seem to be adopted based on fashion rather than based on any actual utility.

But, but, there’s this awesome chatbot I use, and I really like it!

Great. I’m not saying that they have no purpose, but that chatbots are being adopted even though they often are worse at what they do than the alternative. They also come with considerable downsides.

First of all, chatbot UIs are poor at letting a user compare things. When someone browses, say, Amazon or eBay or another e-commerce service, they will often wish to compare products. They’ll open up competing products in different tabs, read reviews, check up on things on third-party sites, ask questions of their friends via messaging apps and social media sites like Facebook. Chatbot UIs remove this complexity and replace it with a linear stream.

Removing complexity sounds good, but when someone is ordering something, researching something or in any way committing to something, navigating through the complexity is a key part of what they are doing.

Imagine this scenario. Apple have 500 different iPhones to choose from. And instead of calling them iPhones, they give them memorable names like UN40FH5303FXZP (Samsung!) or BDP-BX110 (Sony!). Some marketing manager realises the product line is too complex and so suggests that there ought to be a way to help consumers find the product they want. I mean, how is the Average Joe going to know the difference between a BDP-BX110, a BDP-BX210, and a BDP-BX110 Plus Extra? You could build a chatbot. Or, you know, you could reduce the complexity of your product line. The chatbot is just a sticking plaster for a broader business failure (namely, that you have a process whereby you end up creating 17 Blu-Ray players and calling them things like BDP-BX110 rather than calling them something like “iPhone 7” or whatever).

Chatbots aren’t removing complexity as much as recreating it in another form. I called my bank recently because I wanted to enquire about a direct debit that I’d cancelled but that I needed to “uncancel” (rather than setup again). I was presented with an interactive voice response system which asked me to press 1 for payments, 2 for account queries, 3 for something else, and then each of those things had a layer more options underneath them. Of course, I now need to spend five minutes listening to the options waiting for my magic lucky number to come up.

Here’s another problem: the chatbot platforms aren’t necessarily the chat services people use. I’m currently in Brazil, where WhatsApp is everywhere. You see signs at the side of the road for small businesses and they usually have a WhatsApp logo. WhatsApp is the de facto communication system for Brazilians. The pre-pay SIM card I have has unlimited WhatsApp (and Facebook and Twitter) as part of the 9.99 BRL (about USD 3) weekly package. (Net neutrality? Not here.) The country runs on WhatsApp: the courts have blocked WhatsApp three times this year, each time bringing a grinding halt to both business and personal interactions. Hell, during Operação Lava Jato, the ongoing investigations into political corruptions, many of the leaks from judges and politicians have been of WhatsApp messages. Who needs Hillary Clinton’s private email servers when you have WhatsApp?

WhatsApp is not far off being part of the critical national telecoms infrastructure of Brazil at this point. Network effects will continue to place WhatsApp at the top, at least here in Brazil (as well as most of the Spanish-speaking world).

And, yet, WhatsApp does not have a bot platform like Facebook Messenger or Telegram. To get those users to use your chatbot, you need to convince them to set up an account on a chat network that supports your bot. For a lot of users, they’ll be stuck with WhatsApp, the app they use to talk to their friends, and Telegram, the app they use to talk to weird, slightly badly programmed robots. Why bother? Just build a website.

Now, in fairness, WhatsApp are planning to change this situation at some point, but you still have an issue to deal with: what if your users don’t have an account on the messaging service used by the bot platform?

One of the places chatbots are being touted for use is in customer service. “They’ll reduce customer service costs”, say proponents, because instead of customers talking to an expensive human you have to employ (and pay, and give breaks and holidays and parental leave and sick days and all that stuff) to, you just talk to a chatbot which will answer questions.

It won’t though. Voice recognition is still in its infancy, and natural language parsing is still fairly primitive keyword matching. If your query is simple enough that it can be answered by an automated chatbot, it’s simple enough for you to just put the information on your website, which means you can find it with your favourite search engine. If it is more complicated than that, your customer will very quickly get frustrated and need to talk to a human. The chatbot serves only as a sticking plaster for lack of customer service, or business processes that are so complicated that the user needs to talk to customer service rather than simply being able to complete the task themselves.

You know what else will suffer if there were a widespread move to chatbots? Internationalisation. Currently, the process of internationalising and localising an app or website is reasonably understandable. In terms of language, the process isn’t complex: you just replace your strings with calls to gettext or a locale file, and then you have someone translate all the strings. There’s sometimes a bit of back and forth because there’s something that doesn’t really make sense in a language so you have to refactor a bit. There’s a few other fiddly things like address formats (no, I don’t have a fucking ZIP code) and currency, as well as following local laws and social taboos.

In chatbot land, you have the overhead of parsing the natural language that the user presents. It’s hard enough to parse English. Where are the engineering resources (not to mention linguistic expertise) going to come from to make it so that the 390 million Spanish speakers can use your app? Or the Hindi speakers or the Russian speakers. If your chatbot is voice rather than text-triggered, are you going to properly handle the differences between, say, American English and British English? European Portuguese, Brazilian Portuguese and Angolan Portuguese? European Spanish and Latin American Spanish? Français en France versus Québécois? When your chatbot fucks up (and it will), you get to enjoy a social media storm in a language you don’t speak. Have fun with that.

And you can’t use the user’s location to determine how to parse their language. What language should you expect from a Belgian user: French, Dutch or German?

If you tell a user “here’s our website, it’s in English, but we’ve got a rough German translation”, that’s… okay. I use a website that is primarily in German everyday, and the English translation is incomplete. But I can still get the information I need. If, instead, your service promised to understand everything I say, then completely failed to speak my language, that’d be a bit of a fuck you to the user.

In the chatbot future, the engineering resources go into making it work in English, and then we just ignore anyone who speaks anything that isn’t English. World Wide Web? Well, if we’re getting rid of the ‘web’ bit, we may as well get rid of the ‘world’ and ‘wide’ while we’re at it.

Siri and Cortana are still a bit crap at language parsing, even with the Herculean engineering efforts of Apple and Microsoft behind them. An individual developer isn’t going to do much better. Why bother? There’s a web there and it works.

There’s far more to “no UI” or one-shot interactions than chat. But I’m cynical as to whether we’re ever going to reach the point of having “no UI”. We measure our success based on “engagement” (i.e. how much time people spend staring at the stuff we built). But the success criteria for the user isn’t how much time they spend “engaging” with our app, but how much value they get out of it divided by the amount of time they spend doing it. The less time I spend using your goddamn app, the more time I get to spend, oh, I dunno, looking at cat pictures or snuggling with my partner while rewatching Buffy or writing snarky blog posts about chatbots.

But so long as we measure engagement by how many “sticky eyeballs” there are staring at digital stuff, we won’t end up building these light touch “no UIs”, the interaction models of set-it-and-forget-it, “push a button and the device does the rest”. Because a manager won’t be able to stand up and show a PowerPoint of how many of their KPIs they met. Because “not using your app” isn’t a KPI.

Don’t not build a chatbot because of my snarkiness. They may solve a problem that your users have. They probably don’t but they might. But please don’t just build a chatbot because someone on a tech blog or a Medium post told you to. That’s just a damn cargo cult. Build something that delivers value to your users. That may be a chatbot, but most likely, it’s something as simple as making your website/app better.

I’ve just switched over to Let’s Encrypt. My paid-for SSL certificate expires today. I don’t object too much to having to pay the €11 or whatever to renew it, but having to remember to do it every year is a huge faff. The process of making a CSR, logging into the SSL supplier website and all that is just boring.

Let’s Encrypt is nice not only because you don’t have to pay the (not very expensive) SSL certificate tax, but because ideally, it automates the renewal process. Instead of being an annual arse-ache, it’s hopefully set-it-and-forget-it.

For your personal or hobby site, if you currently do the annual certificate dance, switch to Let’s Encrypt when your SSL certificate expires. If you don’t currently do SSL, Let’s Encrypt takes one of the pain points out of it. There’ll still be a market for SSL certificates for businesses (especially for wildcard and EV certificates), but Let’s Encrypt lowers the bar to using SSL significantly.

Git fuzzy branch finder relying on the awesome fzf. This is fantastic if your job makes you use silly things like ticket or story IDs from a project management app in your branch names. Because nobody deserves to suffer because of JIRA.

When debugging hairball web dev problems, occasionally you’ll end up sending HSTS headers to yourself while on localhost. These are surprisingly tricky to remove from Google Chrome. Quite sensibly, the Chrome developers store HSTS hosts hashed.

The standard answer you read online is to go to chrome://net-internals/#hsts. You can check to see if there’s an entry in Chrome’s HSTS database, and you can remove it. But I sit there and type every version of localhost, localhost:3000, 192.168.0.1, 127.0.0.1, ::1 and so on that I can think of and yet the problem remains. (The query form works whether you prefix the query with and without the https scheme and :// separator. So https://en.wikipedia.org and en.wikipedia.org will both search for the same entry. The query form is quite useful if you need to debug your own site’s HTTPS/HSTS setup, so I recommend it.)

The unfortunate result of having screwed up your localhost HSTS entry in Chrome is you then spend the next few days having to use some other browser you aren’t familiar with to work on localhost. This isn’t ideal.

A rather brute force solution to a polluted HSTS database is to delete the database completely. It isn’t a great solution, but if you’ve polluted the database such that you can’t remove localhost from it despite numerous attempts, sometimes needs must. So here’s how you do it.

1. Close Chrome. It caches the HSTS database in memory, so if you just remove the file, it’ll get rewritten.
2. Find where Chrome stores the database. On Mac OS X, using the Chrome that’s in use as of today (August 2, 2016), this is in ~/Library/Application Support/Google/Chrome/Default/ in a file called TransportSecurity. Older versions of Chrome store it in a file called StrictTransportSecurity. If you are using Chrome Canary, substitute “Chrome” for “Chrome Canary” in the paths. If you are using Chromium, substitute “Chromium” for “Google/Chrome”. On Linux, check out .config/google-chrome/Default/ or .config/chromium/Default as appropriate. On Windows, ask Cthulhu.
3. Replace the TransportSecurity file with an empty JSON object: {}. On OS X, echo "{}" > ~/Library/Application\ Support/Google/Chrome/Default/TransportSecurity
4. Restart Chrome.

Now, be aware that resetting your HSTS database /does/ undermine the security benefits of having HSTS in your browser. After doing it, you should keep an eye out for spoofing, MITM attacks, phishing attempts and so on until Chrome picks up replacement HSTS headers from the sites you visit frequently. This /is/ pretty much the last resort and you shouldn’t be doing it routinely. Don’t do it unless you absolutely have to. If you are going to run an app on localhost that might try and force HTTPS, do the testing in an Incognito window or in a browser whose profiles/cache you can fully nuke after you are done.

Incidentally, I haven’t had any similar issue in Firefox because Firefox’s HSTS database is tied into the browser history, meaning that you simply find an entry in history and tell Firefox to forget about the site, and it removes the HSTS entry.

BBC: Desktop banking use falls, as users switch to apps.

This might be because most online banking websites are bloody awful and need the sort of UX love and seamless security that the apps have.

Two fantastic recent BBC radio documentaries: Mighty Real: Sylvester James, and The House of the Windy City - Dance Music’s Forgotten Heroes.

Good news: iOS apps must use HTTPS for API calls from January 2017. Also, Apple is butchering Flash’s corpse some more.

🎵 Currently playing: Samba Brazilian House Music mix by JaBig

Paypal email me to say a subscription payment failed (due to a replaced card). I click the link in the email that PayPal sent me and it takes me to the “outdated version of PayPal”. PayPal is a fucking hot mess of a service.

🎵 Currently playing: DEEPINSIDE presents RICHARD EARNSHAW (Exclusive Guest Mix)

Why GDS / GOV.UK bet on the web rather than apps. All of which is eminently sensible. Imagine the alternative: the UKGOV app. You download it and it has everything you need to be a citizen. Okay, every week there’d need to be new updates to the functionality. It’d have to be available on every single platform.

And you’d end up downloading and storing a lot of that binary blob for functionality that you use once in a blue moon (renewing your passport? That’s a once every ten years problem. Driving licence renewals are the same. Some of the business-oriented stuff that’s done on government websites will affect only half a percent of a country’s citizens.) and you then have the moral risk of having taken app permissions (notifications, location etc.)

Apps have downsides too. A big problem in the tech industry at the moment is too many people count up the negative sides of the web, and the positive sides of apps and don’t consider the other side of both balance sheets. Still, the current ridiculous app trend is great for keeping iOS and Android devs in full employment.

Startups can’t explain what they actually do. I disagree with the contention that it’s because the owners can’t think clearly: it is all a scam to get money. It’s all hype. Saying “cloud-based disruptive P2P content-driven platform” hoodwinks coked-up investors in a way that “it’s a website where you can upload your photos and we’ll show them to you in a different way” doesn’t.

Also, the article assumes that the customer is the end user. In Silicon Valley land, that’s rarely if ever true any more.

TIL: the Royal Mail Group have a registered trade mark on “the colour red”. Take that, refraction.

Solved the “open in app” nuisance by uninstalling the app.

The recent leak of LinkedIn’s password database shows that passwords remain a fragile part of our security ecosystem. Users are bad at coming up with passwords. They use the same password among multiple services. Enterprise password change policies have been part of the problem: users simply take their existing passwords and stick an incrementing number on the end, or engage in other substitutions (changing the letter o for the number 0, for example). Plus, the regular password change doesn’t really help as a compromised password needs to be fixed immediately, rather than waiting three months for the next expiration cycle. CESG recently issued guidance arguing against password expiration policies using logic that is obvious to every competent computer professional but not quite so obvious to big enterprise IT managers.

Many users, fed up with seeing yet another IT security breach, have switched over to using password managers like KeePass, 1Password, Dashlane and LastPass. This is something CESG have encouraged in their recent password guidance. Password managers are good, especially if combined with two-factor authentication.

For users who are starting to use a password manager, they have the initial hurdle of switching over from having the same password for everything to using the password manager’s generated password approach. They may have a backlog of tens or hundreds of passwords that need changing. The process of changing passwords on most websites is abysmally unfriendly. It is one of those things that gets tucked away on a settings page. But then that settings page grows and grows. Is it ‘Settings’, or ‘My Profile’ or ‘My Account’ or ‘Security’ or ‘Extra Options’? Actually finding where on the website you have to go in order to change your password is the part which takes longest.

Making it easier for a user to change their password improves security by allowing them to switch from a crap (“123456”), reused, dictionary word (“princess”) or personally identifiable password (the same as their username, or easily derived from it: “fred” for the username “fred.jones”) to a strong password that is stored only in their password manager like “E9^057#6rb2?1Yn”.

We could make it easier by clearly pointing the way to the password change form so that software can assist the user to do so. The important part here is assist, not automate. The idea of software being able to automate the process of changing passwords has some potential selling points, but the likelihood of it being adopted is low. Instead, I’m simply going to suggest we have software assist the user to get to the right place.

In the form of a user story, it’d be like this: as a user of a password management application, I’d like to speed up the process of changing passwords on websites where they have been detected to be weak, reused or old. When I’m looking at a password I wish to change, I could click “change password” in the password management application and it’d take me to the password change form on the website without me having to search around for it.

There’s a few ways we could do this. There are some details that would have to be ironed out, but this is a rough first stab at how to solve the problem.

Using a rel link

This is my preferred option. On the website, there is a link, either visible (using an a element) or invisible (a link in the head). It would be marked with a rel attribute with a value like password-change. Software would simply parse the HTML and look for an element containing rel="password-change" and then use the href attribute. The user may have to go through the process of logging in to actually use the password change form, but it’d stop the process of searching.

One issue here is that there are a large number of web apps that rely on JavaScript to render up the page and there is the potential for rogue third-party JavaScript to modify the DOM. A simple way to ameliorate this is to search for the value in the HTML itself and ignore any JavaScript. Another possible solution is to require that the password change form be located on the same domain as the website, or decide whether to trust the URL relative to the base domain based on an existing origin policy like CORS.

Putting JSON in a specified location

Alternatively, have people put some JSON metadata in a file and store it in a known location, similar to robots.txt or the various things spooked away in the .well-known hidey-hole. This is okay, but it suffers from all the usual flaws of invisble metadata, and is also a violation of the “don’t repeat yourself” principle—the links are already on the web in the HTML. Replicating that in JSON when it already exists in HTML increases the likelihood that the JSON version will fall out of sync with the published reality.

Putting the link in a custom HTTP(S) header

Same principle as the JSON one, but using HTTP(S) headers. Same issue of invisible metadata. Same issue with same-origin policies.

Security considerations

As noted above, there are some security issues that would have to be handled:

1. Should a consuming agent (i.e. the password management application) allow third-party (or even same-origin) JavaScript to modify the DOM that contains the link?
2. Should a consuming agent ignore password change form endpoint targets that are on a different domain?
3. Should a consuming agent follow a password change link to a non-HTTPS endpoint?

My rather conservative answers to these three questions are all no, but other people might differ.

Warning on scope

As I said above, this is a very narrowly specified idea: the ecology of web application security is pretty fragile, and the likelihood of radical change is low, so I’m not proposing a radical overhaul. Just a very minor fix that could make it easier for (motivated, security-conscious) users to take steps to transition to better, stronger passwords.

I’ve struggled to find where to report this issue, so I’m putting it on my blog as a canonical copy just in case I forget to jump through whatever hoops are needed to report the bug.¹

The file command that is widely used in UNIX land to detect file types doesn’t seem to detect an SVG file properly if it doesn’t have an XML declaration.

Fine, you might say, but if there’s no XML declaration, then that means it isn’t XML. Not so. §2.8 of XML 1.0 says that documents should have an XML declaration but that an otherwise well-formed XML document remains well-formed even without an XML declaration.

The application I’m working on will check manually to see if the data uploaded smells like an SVG and accept it per Postel’s law. But file and libmagic ought to do the job…

An excellent article on the silly Conversational UI trend: Bots won’t replace apps. Better apps will replace apps.

As the author of the piece notes, there’s plenty that’s wrong with the current trend in app design. Conversational UIs are orthogonal to fixing those problems. Each individual app has become its own silo. The model of “spend a bunch of money to hire a bunch of iOS and Android devs to build out a custom app for each platform, then spend a ton of resources trying to convince people to download those apps” has to wind down at some point. And there will be a point where we want a lot more fluidity between interactions. We still spend an enormous amount of time jockeying data between apps and manually patching pipelines of information into one another like some a telephone operator of old. Conversational UIs don’t fix any of those things. Better UIs, which is often less UIs, fix that. As does more focus on trying to make it so we can more efficiently and seamlessly have single-serving, one shot interactions (which goes against all the metrics: we often measure success by how much time someone spends interacting with something, rather than measuring success by how well that thing hides itself away and doesn’t need to be interacted with).

The Health and Social Care Information Centre is now changing its name to “NHS Digital”.

Actually, the full name is the strikingly memorable “NHS Digital: Information and technology for better health and care”, which sounds more like the name of an academic paper than a healthcare organisation. The first order of business for employees of NHS Digital will be to set up keyboard shortcuts so they can type the full name. We should perhaps breathe a sigh of relief that nobody managed to shoehorn the word “cyber” into the name.

The announcement states that the new name “should help to build public recognition, confidence and trust”. Presumably because when people think of “NHS Digital”, they’ll not associate the new brand with the colossal cascade of cock-ups that is care.data, the plan to share your confidential medical records including alcohol and tobacco use and mental health conditions on a centralised computing system that will undoubtedly be as secure and well-managed as most other central government databases. Rebranding HSCIC seems like a cynical way to distance themselves from this highly controversial scheme.

The latest revelations from GCHQ show them to be even more slippery and untrustworthy than previously thought. And the government want to give them more power rather than hold the leash tightly until they behave within the law? The intelligence services have shown a colossal lack of transparency or accountability that makes a mockery of any claim to being an institution compatible with democratic principles.

In things nobody should be the least bit surprised about, companies like 23andMe are being asked to provide DNA samples from their customers to law enforcement agencies.

There’s a way that the 23andme model could work that wouldn’t require creating a honeypot of DNA data for law enforcement. Instead of centralising the data, decentralise it. Have people send in their DNA sample, sequence it, then send that data back to the customer. Then to provide analysis of that data, give each individual customer a piece of software that runs on their computer and does the analysis on there. Then send back anonymous data, but giving each individual user the choice of what they share back to the centralised server. That would actually put users in real control.

Decentralisation and user empowerment isn’t just a nice idea in this case, it’s potentially the difference between being arrested and not. If companies like 23andMe don’t switch to some kind of decentralised model, it shows they are prioritising other factors above the privacy and security of their customers.