#IoTMark, shaping better connected products => Slides http://www.tamberg.org/thingscon/2018/IoTMarkThingsConCgn.pdf tamberg@yaler.net, 06.04.2018, licensed under CreativeCommons, CC BY-SA 4.0, iotmark.org 1) Thanks for the introduction and hi everybody! I'm an engineer and a maker, so please forgive me the pragmatic design of my slides. I'll post them on my Twitter, @tamberg 2) Today I'll talk about the Open Internet of Things Certification Mark, or short: #iotmark. We're on Twitter as well, under @iot _ _ mark 3) #iotmark is a community effort for shaping better connected products. If you read about IoT today, it's mostly bad news. We thought it's time to define a more ethical approach. 4) #iotmark was initiated by Alexandra Deschamps-Sonsino and Usman Haque. Alex is the organiser of the IoT London Meetup and probably the most connected person in IoT. 5) I organise the IoT Meetup group in Zurich, Switzerland. When I heard about the #iotmark, or rather it's predecessor in 2012, the Open IoT Assembly, I joined them in London to see what it's all about. That's how I ended up becoming a contributor. 6) The basic idea of #iotmark is defining a trustmark for IoT, similar to the Fair Trade label. A sticker for your connected product, to help people make informed decisions when buying a product. 7) Of course IoT is more complex than a Banana, so a more fine grained approach might be required. As Peter points out, finding a meaningful scheme turns out to be quite a challenge. 8) The groundwork for #iotmark was laid in June last year at the London Zoo. Over 60 people from the UK and all over Europe came together, we formed working groups and collaboratively edited a first draft. 9) The current editing process could be described with @jaromil's "square of virtuose creation". By sharing and distributing our work under an open license, everybody can use and build upon intermediate results. 10) To find a common language, we introduced a simple reference model based on this picture from the Eclipse foundation. Devices are connected to the cloud, services and apps use the collected data. 11) A connected product includes the devices, the backend and the service it represents. We use device rather than thing or product, to be more specific. 12) The main result of #iotmark so far is a number of about 30 principles covering topics from privacy to product lifecycle. 13) A detailed version of the principles is published on Github. The content is still quite rough and sometimes inconsistent. You're welcome to comment or propose changes on Github or in our Slack. 14) In March we met in Berlin to clean up the first draft. We also tried to sort the principles into three groups. Here you see the "must have" principles We'll take a closer look in a minute. 15) Besides "must have", there's a "nice to have" and a "best case" category. This allows product companies to focus on the essential principles first, and shows a way to the ideal connected product, if such a thing exists. 16) Of course, priorities differ from users to manufacturers. Alex designed some nice cards with a principle each, so people can discuss and set their own priorities. 17) Shortly after publishing the cards under Creative Commons BY-SA, an slightly nicer version emerged. 18) Ok, let's look at some principles. When it comes to privacy, here in Europe, your product has to comply with the new General Data Protection Regulation, GDPR. 19) What does that mean? The right to download all your personal data; to migrate it to another service; The right to be forgotten; to limit how your data is used; and so on. Check Chris Adams talk at ThingsConSalon Salon Berlin. 20) All those things are more or less common sense, if you put humans in the center. 21) I just added a privacy policy to our IoT cloud service. At Yaler we try to keep it simple and not gather personal data in the first place. 22) Another important topic is interoperability. If APIs are documented, devices can talk to other backends and vice versa. 23) Here's the API documentation for the Hue connected lamp, or rather its gateway. I found it quite easy to build a custom adapter. 24) If a device API is public, you can do physical mashups. The OpenAPS project connects a blood sugar (CGM) sensor with an insulin pump. The glue code runs on the Edison or a Raspberry Pi. 25) The OpenAPS algorithm helps Type 1 diabetics keep their values in check. Such closed loop systems are not yet on the market. Maybe in 5 years. Dana and the OpenAPS community are not waiting. 26) As the medical industry is conservative, device APIs and communication protocols are not open. This patient interest group crowd-funds the reverse engineering, or hacking of additional pump models. 27) JDRF, a non-profit funding diabetes research, started lobbying for open protocols. Companies started taking note. The unthinkable became the new normal. 28) FDA, the US government food and drug administration swallowed the pill, and just authorised the first interoperable blood sugar sensor. They even promised a faster path through certification for open devices. 29) When we talk about openness, in addition to interoperability through "open" APIs, we mean open source. 30) A great success story is The Things Network, a global, open and free long range radio network for IoT. Their product includes sensor devices, a gateway and a backend which connects to custom apps. 31) If you prefer to use your own sensor devices instead of theirs, just create an account to get your API keys. The same holds for gateways. The software is open source, setting up your own is a matter of minutes. 32) The hardware designs, firmware and even the backend source code is open source. This reduces dependencies to the project initiators. 33) The Things Network uses the liberal MIT license, which works even for enterprise customers. For documentation and physical designs, we recommend using Creative Commons. 34) Through their transparency and openness, The Things Network attracted a huge, global community in just 2 years. 35) Here you see the number of gateways, a measure for network coverage. 36) Of course, open source does not equal financial success. My friend Juerg Lehni, an artist engineer and creator of Paper.js, has to take other jobs to make a living. 37) Safecast, a citizen sensing project, found a sustainable way to provide an open source connected product. They are a foundation. 38) During the Fukushima disaster, hackers started collecting their own radiation data. In the meantime normal citizens are covering the entire country with connected sensor devices. 39) The collected data is in the public domain. Even if individuals do not trust each other the sheer amount of redundant measurements creates trust in the collected data. 40) Of course users should be able to get their data. Not just personal data covered by GDPR. Connected products should also provide a way to switch them off. And they should not turn into bricks. 41) Defining which data is yours, is a hard problem. A humidity sensor knows when you shower, but the measurements belong to the bathroom rather than you as a specific resident. 42) Here, personal data from a fitness sensor lead to loss of insurance payments. The woman reportedly trained too much. 43) Sometimes there are unintended consequences. Strava, published 700 million running traces and other fitness data. Everything was anonymised. The map is interactive. 44) A Twitter user interested in open source intelligence found out that the traces highlight secret army bases. If you're the only runner on an uninhabited island, anonymising your data does not help. 45) To keep in control, switching off is sometimes the only option. Here, a user tries to find out if the Amazon Echo really cuts the connection when pressing the mute button. 46) Connected products are other people's computers in your home. When Sonos decided to integrate their product with the Amazon Echo, this had catastrophic consequences for existing users. 47) We also think it's important to keep a products core functionality intact. Jared might be talking about apps or UIs, but his points certainly hold as well for connected products. 48) Another aspect of interoperability and a consequence of the GDPR is the right to migrate your connected device to another backend provider. 49) For example, the blood sugar sensors mentioned before connect to proprietary clouds. The Tidepool project tries to change this, and liberate the patient data. They provide an alternative backend to store your data. 50) Current medical devices come with wireless remote controls, like this one. Tidepool collects the same data in a better way. 51) Once patient data was available through a well designed API, engaged users teamed up with developers to build beautiful apps and nicely designed wearable interfaces. Interoperability and ownership fosters innovation. 52) Device manufacturers get free PR by providing a well documented device API and accessible protocols. Patients prefer to own their data. 53) Connected products mean you depend on a service provider of some sort. Transparency becomes a must. 54) If an action creates unexpected cost, users should get notified. Just like the roaming SMS warning you get when you step out of the plane and switch on your phone in a new country. 55) Designers should take into account that users take their connected products with them when moving. 56) Sometimes there are no good options. When Koubachi was bought, the new owner decided to discontinue their connected plant sensor. Philip, the founder, managed to at least provide a generous grace period for existing customers. 57) It's not always obvious what is needed to keep a connected product running. Here's an attempt to reverse engineer the backend of Nabaztag, an early IoT Bunny. 58) When the owner of Nabaztag went out of business, people tried to build alternative backends, with various success. 59) A huge topic is of course security. It's easy to say what's wrong, but quite hard to provide actionable guidance without getting too technical. 60) Here's a start. 61) This blog post by a UK security firm does a great job stating what's wrong. 62) They also have a great blog, detailing possible attacks. 63) We found quite some best practice documents for different fields. 64) Governments are also mounting the pressure. Existing actors like IoT Security Foundation provide guidance to show how their advice maps to new regulation. 65) This document by Microsoft is on a high but still useful level, even if you're not a Microsoft person. 66) There have been attempts to design physically secure computers, like ORWL, who deletes everything if somebody tampers with it. 67) The last topic in our list is the product life-cycle. Let users know, where it comes from and how to fix it. 68) The premium example of sustainable design in electronics is probably the Fairphone. It got the highest repairability score on iFixit, a Website helping people fix devices. 69) Safecast has a simple approach to provide repairability: let users build their own product, from standard modules. Once you built something, repairing it becomes trivial. 70) And here's a great example of providing support during the lifetime of a product. 71) During our work on #iotmark we found about 30 similar initiatives. The time definitely has come for ethics in IoT. 72) The issues are mainstream and urgent and if we don't act, we'll end up with even more Silicon Valley surveillance-capitalism or a social credit system "with Chinese characteristics". 73) Check out our wiki for references and background information on similar and complementary efforts. 74) We tried to sort the initiatives by focus area. There's still some work to do. 75) An early example from the ThingsCon family is the IoT Design Manifesto. 76) Another nice project ist Better Things, which started as a diploma project of a design student. 77) And my personal favourite is this principles document by Consumers International. It's very consistent focused on the users best interest. 78) What next? Alex and all of us will try to spread the word and get as much feedback as possible. As it's a community-led effort, there's no fixed roadmap. 79) Personally I'm interested in a lean approach, and if possible automated assessment of compliance. This project by IF tries to automate understanding terms and conditions. 80) SSL Labs provides automated security checking of Web APIs, at least of certain important aspects. 81) And the Dowse project provides a home gateway that increases transparency by showing when your toaster calls home. 82) Yeah, that was it. Consider joining the discussion. We're on Slack. My slides will be on Twitter @tamberg. Thank you very much.