Just a month ago I wrote here about my reservations concerning the use of mobile phones as hotel room key. A hotel I will be staying at in the near future yesterday started sending me multiple (unasked) SMS’s to download their hotel app to ‘make my stay smarter’. Sure, I will trust download links in unrequested SMS! Today as I’ve ignored their messages I received an e-mail imploring me to do the same.

The app they ask me to use is called Aeroguest, and their pitch to me is about easier check-in/out, using chat to contact staff, and using my phone as door key. The first two I’d rather do in person, and the last one is not a good idea as explained in the above link.

Why such an app might be seen as attractive to the hotel, becomes clear if you look at the specifications of the app. A clear benefit is direct repeat bookings, saving the expensive middle men that booking sites are. In my case I almost always book through the hotel’s website directly. And if I enjoyed my stay I usually book the same hotel in a city for my next visit. I do use booking sites to find hotels. In this case I’ve stayed in this hotel several times before.

The stated benefits for the guest (key, chat, check-in/out, choosing your room) are a small part of the listed benefits for hotels in using the app, such as up-selling you packages before and during your stay. An ominous one, when seen from the guest’s perspective, is ‘third party services’ access presumably meaning potential access to your booking / stay history and maybe even payment / settlement information, requested preferences etc. Another, more alarming one, is “advanced indoor mapping” which I take means tracking of guests through the hotel which can yield information on time spent in hotel facilities, time spent in the room, how often / when the key was used, and by matching it with other guests, whom you might be meeting with that is also staying in the hotel. In Newspeak on the apps website in the data and analytics section this is described as “With transparency, you can proactively accommodate your guests’ needs.” Note that the guest is the one who is being made transparant. That is quite a price in exchange for being able to choose your specific room when checking in with the app.

I’ve replied to the hotel my reasons for not wishing to use the app (linking to my previous blogpost), and told them I look forward to checking in at reception in person when I arrive. When I arrive I am curious to hear more about their usage of the app. For now “making my stay smart” reads like the “smart cities” visions of old, it may be smart, but not for the individuals involved, merely for the service provider.

Many (news(y)) websites have become highly irritating to browse: when you scroll down towards the end of an article you’re reading they append a next article underneath it, and if you scroll past the end of the article change the URL in your browser’s address bar. Below is an example I encountered today.

That is highly irritating, as the browser is my tool, not theirs.

  • It regularly frustrates bookmarking (if you hit a bookmarklet at the end of an article it saves the url of the next article),
  • it creates an endless scroll experience (a dark pattern copied from the likes of FB), where news sites get an opportunity to present content they selected by algorithm that you weren’t looking for.
  • it doesn’t influence the back button. Hitting that brings you to an unexpected place therefore, as you may not realise you’re in an endless timeline and think you somehow landed in a different article,
  • if you use your browser’s default setting you won’t have noticed that the URL has changed as the address bar will only show the domain, not the full URL.

This behaviour is based on HTML5 pushstate, which allows a site to interact with your browser history. This can be used to e.g. decrease load times of additional pages and content. The endless scrolling however feels like a dark pattern usage of this possibility to me.

In keeping with Doc Searls’ Castle Doctrine of browsers, I’d like to block this behaviour.

Options that are available seem to be:

  • Use a reader view. This seems to break bookmarklets though, which is one of the nuisances I’m trying to fix
  • Block all javascript and use a whitelist. Seems drastic, though it’s something I’m increasingly leaning towards over the past few years. Alternatively I could use a blacklist.
  • Use ad blockers by adding rules for the specific scripts causing this.

Reader view is useful, but not for this specific issue. Adding rules to my adblocker might be feasible, but assumes that I can easily spot a) which sites do this b) which script on their site is doing it, in order to block it. Using a blacklist for Javascript only needs me to spot sites that do this, which is half the hassle of adding filters to my adblocking. Blacklisting some sites for javascript is also less inconvenient than blocking all javascript and whitelist exceptions. So for now that’s the way forward. Bloomberg, the source of the example given above, is now on the blacklist.

Since the summer I am holding three questions that are related. They all concern what role machine learning and AI could fulfil for an individual or an everyday setting. Everyman’s AI, so to speak.

The first question is a basic one, looking at your house, and immediate surroundings:

1: What autonomous things would be useful in the home, or your immediate neighbourhood?

The second question is more group and community oriented one:

2: What use can machine learning have for civic technology (tech that fosters citizen’s ability to do things together, to engage, participate, and foster community)?

The third question is perhaps more a literary one, an invitation to explore, to fantasise:

3 What would an “AI in the wall” of your home be like? What would it do, want to do? What would you have it do?

(I came across an ‘AI in the wall’ in a book once, but it resided in the walls of a pub. Or rather it ran the pub. It being a public place allowed it to interact in many ways in parallel, so as to not get bored)

Much easier than regulating to break up Facebook, just regulate to force them to make an API for us to get data in and out. We can break them up ourselves once we have that. (source)

Neil is right, an effective way to break-up big tech monopolies is requiring they have API‘s. (Much like key government data sets across the EU will be required to have API’s from 2021 based on the 2019 PSI Directive)

A monopolistic platform that has an API will be effectively broken up by its users and by app builders as they will interact with bits and pieces from various platforms as they see fit.

That FB and Twitter e.g. have been on a path over steadily reducing public API access over time shows you the truth of that.

(Adversarial) interoperability and standards are key elements in avoiding vendor lock-ins. This is true for ‘smart home’ appliance silos just as much as for webservices.

If you don’t have an API you’re not a platform (platforms are after all bases to build/grow things on, if you stunt that ability you’re not a platform). If you’re not a platform, you’re fully liable for your user uploaded content. How’s that for a trade-off?

All platforms should be required to join the API family…

2019-07-16_04-51-20
Picture taken earlier this month at La Folie de Finfarine in Poiroux

This from Wendy Grossman hits the nail quite precisely on its head.

The problem isn’t privacy,” the cryptography pioneer Whitfield Diffie said recently. “It’s corporate malfeasance.”

This is obviously right. Viewed that way, when data profiteers claim that “privacy is no longer a social norm”, as Facebook CEO Mark Zuckerberg did in 2010, the correct response is not to argue about privacy settings or plead with users to think again, but to find out if they’ve broken the law.

I think I need to make this into a slide for my stock slide deck. It’s also I think why the GDPR focuses on data protection and the basis for data usage, not on privacy as such.

(Do add Wendy Grossman’s blog net.wars to your feedreader.)

Read net.wars: Hypothetical risks

Hotel keys
Hotel keys, photo by Susanne Nilsson, license CC BY-SA

Everybody hates the keycard, says the NYT, and talks about using your phone instead. There are a few reasons why using your phone as a hotel key is not something I do, or would do.

One reason is provided by the hotels promoting this themselves:

And, since the keys are downloaded electronically through a hotel app, the host has a presence on the guests’ phones, and can offer other exclusive services, like promotions and a chat feature.

Presence on my phone, that sounds rather ominous. Let me count the hotel apps I currently allow on my phone…. 0.

Unless there’s an opt-in for each single additional ‘service’ as part of a hotel’s ‘presence’ on my phone, it is in breach of the GDPR wherever I travel. Do hotel chains really want to expose up to 4% of their annual turnover to liability risks?

The ones I’ve encountered worked through bluetooth. That opens up a wide range of potential vulnerabilities. I never have bluetooth switched on (nor wifi when not in active use, for that matter), and there are very good reasons for that. There might be other bluetooth devices nearby pretending to be my hotel door to get access to my phone, or piggyback on my room door’s communication. A plastic card and a room door never have that issue. NFC based ones have less of these issues, but still bring their own issues.

A vulnerability in a hotel’s mobile app now also becomes a vulnerability for your hotel key as well as for your phone. It also means a phone will contain data traces of any hotel you may have used it as a key. That is a privacy risk in itself, not only to yourself, but potentially as well to people you have encountered. (E.g. investigative journalists would be risking the anonymity and privacy of their sources that way.)

Another reason is, also when I travel alone I have 2 plastic key cards. I keep them in different places, so I have a back-up if one of them gets out of my hands. Having just my phone is a single point of failure risk. Phones get left in hotel bars. Phones slip out of pockets in taxi back seats. Phone batteries die.

That is the third reason, that phone batteries die, especially on intensive work days abroad. Already that is sometimes problematic for mobile boarding passes for e.g. a second leg of a trip after a long haul flight (such as last month on a trip to Canada), or an evening flight home.
When staying in a hotel, after a long day, I sometimes need to leave a phone to charge in my room (sometimes the room safe has a convenient power outlet), while I go have a coffee in the lobby. This month during holidays I left my phone charging during dinner in a hotel in Rouen, as well as in an apartment on the Normandy coast, while we headed out for a walk on the beach.
So when I read in the article “What is also great is that I don’t find myself forgetting my key in the room as I always have my phone with me“, I take that to mean “you can’t leave your room when your phone needs charging” and “you can’t return to your room if your phone battery died”.

Phones and hotel keys all have their vulnerabilities. Putting a key card on your phone doesn’t remove the existing vulnerabilities of existing key card systems, but transfers and adds them to the vulnerabilities of your phone, while also combining and increasing the potential negative consequences of one of those vulnerabilities becoming actualised.

Read Everybody Hates the Key Card. Will Your Phone Replace It? (nytimes.com)

Technology that allows hotel guests to use their phones as room keys is expanding, taking aim at those environmentally unfriendly plastic cards.