After meeting Rob van Kranenburg (IoT Council, NGI) at the Edgeryders meetup of scifi authors and economists in Brussels last Monday, had a nice chat with him to catch up on Skype today. Looking forward to joining a session he is hosting at ThingsCon next month.
Aaron Parecki has been playing around with sensors in his home. He lists the three principles he applies to how his home automation is set up:
- Manual override: Everything automated has to still have the ability to be controlled manually
- Keep it at home: No “cloud” services unless absolutely necessary (e.g. push notifications to a phone)
- Open: Avoid vendor lock-in, use open source and open protocols where possible
These are three principles that make sense in more contexts, where the second principle “keep it at home” I relate to the “useful on its own, more useful when connected to other instances” element that is important to me in thinking about smart homes.
Rather impressive is that Aaron is dropping technology that has been acquired by silos, and breaks those principles after he started using it, and not just uses them to inform buying decisions.
Silo-imprisonment and closed tools result in a smart home that isn’t smart for you, but smart for the vendors. Like how Smart City TM visions were about dull boring security focused panopticons keeping people in check. Not the vibrant community where ideas, people, capital, goods and artisanship recombine into a total so much more than the sum of its parts, where smart technology aids those serendipitous recombinations.
A smart home to me is one that is not just a dwelling but a productive actor (a “MakerHousehold“), for the people that live in it, for its immediate neighbourhood and for the city it is in. This was what I was interested in when shaping the ‘Smart Stuff That Matters‘ unconference last year.
Aaron got me thinking about potential sensors in our home again. Also because data gathering is the starting point for finding points of action. AI for the rest of us I think needs to be based on self collected data around the house / person, mixed with public data for context.
Over the past few weekends I’ve been overhauling my home automation systems. At the core, as I decide what to buy and how to configure it, there are three primary principles
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.
Technology that allows hotel guests to use their phones as room keys is expanding, taking aim at those environmentally unfriendly plastic cards.
Since shortly after we moved in we have a temperature and humidity sensor in our garden.
This week’s heat wave is breaking records across Europe including here in the Netherlands. So I’ve kept an eye on the temperature in our garden. Our sensor is part of a city wide network of sensors, which includes two sensors nearby. Of the three sensors, ours indicates the lowest temperature at 36.8 (at 16:45), the other two hover just under 40 and at 41.8 respectively. Such differences are caused by the surroundings of the sensor. That ours is the lowest is because it’s placed in a very green garden, while the others are out on the street. In our completely paved and bricked up courtyard the temperature is 42.1 in the shade, due to the radiation heat of sun and stones. Goes to show that greenery in a city is key in lowering temperatures.
Three sensors in our neighbourhood, ours is in the middle, showing the lowest temperature. Note that the color scale is relative, for these 3 sensors running from 36.6 to 41.8.
In the past days since our return from France the temperature has been steadily rising, as per the graph below (which currently ends at the peak of 36.8 at 16:45). Staying inside is the best option, although the also increasingly higher lowest temperatures (from 15 to above 20) mean that the nights are slowly becoming more uncomfortable as the outside temperature will stay above the in house temperature during most or all of the night.
UPDATE as of 26/7 June noon, here you can see how the night minimum jumped 5 degrees in 24 hours, bringing it above the in house temperature for the entire night, except a brief moment around 6 am. At noon the maximum for the day before is already nearly reached.
The way to make this graph yourself is
- Go to meetjestad.net/data, where you can select various data types and time frames. Our sensor is number 51, and I selected a time frame starting at July 19th at midnight. This allows me to download the data as CSV.
- The data in that download is Tab separated, not comma,when you select a comma to be used as decimal point.
- The file contains columns for the sensor number and its latitude and longitude, that are not needed as this is data for just one sensor. Likewise, empty columns for measurement values for which my sensor kit doesn’t contain sensors, such as particulate matter, can be removed. Finally the columns for battery level and humidity are also not needed on this occasion.
- With the remaining columns, time and temperature it is easy to build the graph. In this case I replaced the timestamps with sequential numbers, as I intend to make a sparkline graph with it later.
Some links I thought worth reading the past few days
- A brief overview of how the GDPR and EU PSI-Directive interplay : The PSI directive and GDPR – European Data Portal
- Some discussion on how blockchain and GDPR go together. Says it’s not about the tech but about use case implementation. That emphasises my position that GDPR is a quality assurance tool, not a gate with a sign ‘forbidden’ : EU Blockchain Forum says blockchain, GDPR compatible – Ledger Insights
- A statement like “Therefore, our primary focus is to get millions of Q members registered” makes this initiative sound very spammy and pyramid like, banking like they do on FOMO. Having everyone wait for whatever they plan until they have millions of users is an odd way of getting those users. Why not have something of value now, so that it brings users in? Anyway I have an account, and you are invited. More info on: Initiative Q
- An old posting, although still worth reading (about the need for your own webspace if only to tinker) mostly bookmarked because of the still very useful video of Amber Case outlining the reasoning behind the IndieWeb (independent web): The IndieWeb, Revolution, and Other Reasons You Should Learn to Code
- In terms of privacy it really is not a good idea to use smart home devices that have a centralised web service / data store behind them: Smart Home Surveillance: Governments Tell Google’s Nest To Hand Over Data 300 Times
Some links I thought worth reading the past few days
- Initial circumstances mostly trump intrinsic capabilities. Basically the evolutionary space available. Delayed gratification is based on affluence at the outset, not indicative of doing better in future: Why Rich Kids Are So Good at the Marshmallow Test
- Can’t afford it, society without social contract, techno-determinism, salvationism, denial. Five kinds of stooopid: Umair Haque on The Age of the Imbecility and how not to join it
- “Embrace and Extend” usually means “embrace and smother” in the context of organisations like Microsoft, and I expect lots of devs to head for the exit, though some see it in a positive light: Microsoft buying GitHub
- Allow proper citing of blogs, added to the ‘someday’ project list: Joi Ito adds a citation widget to his blog
- An analysis of the proliferation of Internet of Things Manifestos: A CHI 2018 paper, Calling for a Revolution
- This isn’t about open data, despite the original title, but controlled sharing in defined ecosystems: In Japan, Mitsubishi Estate and Fujitsu put blockchain in the service of shared data
- If you can answer this letter, you can likely handle anything GDPR related: So You Received the Nightmare GDPR Letter
- Why Doc Searls is probably right about GDPR popping the adtech industry, and why consent in the ePrivacy Directive is to be interpreted as GDPR style consent: Personal Data Processing for Behavioural Targeting needs unambiguous consent
- Networked agency is not about enabling individuals but people in their meaningful social context. So yes, open tools need to have the networked effect built in : To bring people to the open web it needs to be the best version of the web.