Writing up IotMark, part 2 of 2

I said on twitter that I’d do a write up of the Friday IoTMark workshop last week:

I’ve had enough people fave it to give me a reason to write it, but over the weekend, I realised that giving context and backstory to the event took up more than 1500 words already. I’ve split that out into a separate post, so here’s how the day went down and the key things I learned.

Much less than 60 people this time around

Previous events have been relatively large affairs, taking over entire venues, with breakout rooms, and culminating in a somewhat chaotic mob-editing of a google doc, to come up with either a bill of rights style document, or some kind of spec or set of principles to inform the creation of a certification mark for connected products.

This time round, there was a handful of people, in person, in a room for the whole day in central Mitte instead – albeit one with a nice view from the tenth floor, and a few people skyped in, in anm iPhone in a glass, to make them easier to hear.


What we were going for

The goal of the day, as I understood it, was to get the ideas in the most recent document in better shape for being used as a basis for a certification mark.

This included:

  1. tidying up the language and trying to make it as accessible as possible without losing the substance of the initial document
  2. reconciling it with the issues raised on github, and feedback when presenting it at Mozfest in November 2017.

There was also a move to make the IoTMark something people and organisations of all sizes could realistically commit to adhering to – when setting up a certification mark can easily cost more than 40k USD, it makes sense make it something that actually could be adopted.

A bit like Energy Star, for IoT


One strategy to follow if you want a diverse set of people to commit to a set of ideas, is to introduce levels of commitment, so you aren’t asking for people to make a binary all in/ all out choice.

There was already some implicit sense of grading here in the normative language (a MUST  is non-negotiable, but a SHOULD for example, is not absolutely mandatory), so started with that, to come up with a rough set of three groupings.

I say groupings here, because it’s really, really hard to have a single axis when discussing these products, that goes from, say, bad to good. It’s much more complicated than that, and different people value different qualities – some people might value openness of software and hardware over the supply chain transparency, and some might treat being explicit about how personal data is used as more important than marketing to a specific group of people.

That said, one grouping was considered a bare minimum – something considered reasonable to expect anyone wanting a connected product that follows the principles to follow. It felt important to have something everyone could have as some shared values, before focusing on diverging areas.

Relating GDPR to IoT

The other thing that came out of the day was just how far reaching the GDPR is when it comes to thinking about about connected products, and why it made sense to think about it in the context of IoT.

It’s a common refrain that the tech industry needs to improve when it comes to it’s cavalier attitude to people’s data – often deeply personal data secured in dangerously careless ways, and used in ways that definitely aren’t in the interests of the consumer.

I also think it’s safe to say that there is appetite for change, and well… from my perspective at least, GDPR feels like change for the tech industry in the same way that a giant asteroid might have represented change to wildlife around the end of the Cretaceous period on Earth.

To be clear, this change isn’t necessarily bad – asteroids can sometimes get rid of dinosaurs and make life easier for us humans, after all.

Why you might care about GDPR for IoT

I often point people to these posters from the co-up to help understand the ideas behind the GDPR, and why it’s a big deal – for many consumers, the ideas in the GDPR don’t sound like unreasonable things to ask for, especially when there often seems to be no real penalty for bad behaviour, from lawmakers.

Chaos Monkeys for your data pipeline, otherwise known as Europeans

In addition, if you are building a connected product the the changes to privacy law are extraterritorial, as in – if any citizens of EU member states end up in your data pipeline, or data is proceeded in the EU these laws still apply. I think Heather Burns, covers this really well in a recent piece aimed at web developers, and much of it applies for IoT too:

In May of 2018, a major upgrade to Europe’s overarching data protection framework becomes enforceable. This will be followed by a companion piece of legislation pertaining to data in transit. The extraterritorial nature of these two frameworks — they protect the privacy rights of people in Europe regardless of where their data is collected — means that they will become the de facto standard for privacy around the world.

Enforcement may be another issue, but given that for 300 million people at least, the biggest changes to privacy law in 25 years are coming into effect this year, and will force changes anyway, ignoring it seemed short-sighted, as well as being against many of the ideas in original document.

Overlap between IoT principles and GDPR

I’ll end this section with one thing that struck me – it’s totally possible to build connected products that comply with the ideas of the GDPR, and there are very large companies doing exactly this. In fact, there’s some great stuff by Matt Webb, on how privacy can be a competitive advantage for IoT services that’s worth reading if you’re interested in this field.

He cites Hoxton Analytics as a good example – by building privacy into their product from the beginning, they could be deployed in places more invasive systems couldn’t, helping them against competitors – there’s a lot of FUD about GDPR, but it’s also an opportunity to rethink the playing field, something lots of companies already invested in one way of working seem to miss.

RFCs versus principles

Another thing that came up thing during the day, was the difference between a spec using specific normative language as described by the IETF, which you typically validate programmatically based on the MUSTs and SHOULDs, and a set of principles which tend to have more fuzzy edges, and are more open to interpretation.

It’s relatively old now, there’s some really great thinking in Lawrence Lessig’s book Code, about different ways of enforcing behaviour, which I think is relevant.

I don’t have the book handy, but Danah Boyd’s blog summarises one of the key ideas nicely :

In his seminal book “Code”, Larry Lessig argued that social systems are regulated by four forces: 1) the market; 2) the law; 3) social norms; and 4) architecture or code.

I think it’s easy to conflate these. When you’re trying to bring about a specific kind of behaviour you want people to follow, it’s worth thinking in these terms, so you don’t try to make one force act as it’s another.

Embodied thinking in physical space


Finally, in the afternoon, after re-reading through the the principles as described in the original Open IoT documents, referring to the Github issues, and Mozilla versions, and deduping them, we spent a bunch of time finding ways to group these principles, to make it easier to follow a meaningful amount of them if you can’t follow all of them.

If you have a load of people in a room, and you need to help build a shared understanding, one strategy to help people to this is use some physical token represent an idea, and let people use the physical space to communicate how ideas relate to each other.

Given we had spent a bunch of time already checking our understanding of the ideas in isolation, I found it useful to help communicate positions for people in the room to discuss more effectively.

The downside here when you are skyping people in, is that they’re not able to move things around themselves – and by doing this, you’re making a specific decision to favour collaboration in the room, over those who are remote. In most cases, I think this is the right call, as the alternative is often to collaborate at speed of the person with the lowest bandwidth connection, which reduces what you can get done in a limited amount of time.

I’d love to hear suggestions for finding a way around this – while you can use tools like realtimeboard to create a whiteboard-like experience, you’re still reducing the richness of your interactions in the room to what the software lets you do with a piece of backlit glass.

How to get involved in this in future

If you’re interested in any of this, I’d suggest heading to the iotmark website – from there you can see the current version of the principles, join the slack workspace, or subscribe for updates over email, or follow the IotMark on twitter.

As ever, comments on this post are welcome, and if you prefer you can contact me directly.




Writing up IoTmark – 1 of 2

I went to last Friday’s IoTMark follow-up event from last summer’s Open IoT Definition, partly because I figured I’d learn a lot, also because whether I like it or not, the evolution of the Internet of Things (IoT) is something I feel I should have a handle on as someone working in tech.

The day was more productive than I had expected it to be, and I learned loads – but before I could put together a writeup, it seemed worth giving some more context here if this was new to you. There’s another post where I do the write up of the day itself.

My background, and disclaimers

I am definitely not an IoT expert. I write this from the perspective who is paid to write code, but also paid to run workshops, and help product development teams work more effectively together.

The one system I put into production in 2009 with my first company that you might describe as vaguely IoT-y was a system where we were inferring utilisation by co-workers in a couple of co-working spaces, based on detecting people’s devices connected to wifi.

We then monitored energy used in a building, and then tracked the energy mix on the national grid to work out the carbon footprint per person per hour of the space.

The idea was to help the owner make an argument that you could have a greener office, by shaping demand and making better use of the space available. I’m happy to chat about the lessons learned here, but that’s another post.

It was some of my first python programming, it was buggy as hell, a source of incredible stress for me, and commercially ruinous for my company, but I learned about failure modes, security, and all the weird ways things can fail, at the worst possible time. In fact, it was enough for me to flee from anything to do with hardware, for years. As such, there may be errors, and I might get terminology wrong – please contact me direct if you see any, and I’ll change them.

I share this to give some background of where I’m coming from, if my viewpoint seems different to yours.

The background of the Open IoT events and IoTMark

In 2012 – the Open Internet Of Things Assembly

In 2012, along with a bunch of other nerds, I went to the Open IoT Definition event on 17th June 2012, at the Google Campus in Shoreditch, organised by Alexandra Deschamps-Sonsino, and ended up at a fascinating, if somewhat chaotic event. Over the day, 60-70 people ended up forming groups to talk about various aspects of how IoT were affecting our lives, how the incentives seemed to reward all wrong kinds of behaviour, and how we feel a more humane version of this might look.

This culminated in something like 50 different people, trying to use google docs to simultaneously author a sort of bill of rights, the Open Internet of Things Definition, to encapsulate this.

Amazingly, there’s still a storify available of the day that does a fairly good job of capturing what it all felt like.

The day felt nice, and I met loads of really interesting people, but I’d be lying if I said we all left the day, and rebuilt everything we did along the principles written up in that Open IoT document.

Fast forward 2017 – The Internet of Things Mark

Last year, I heard from Alex and Usman, letting me know that they were planning to do a follow-up event, and asking whether I’d be interested in coming back to help moderate one of the sessions.

The goal of the day was to come up with a kind of trustmark for IoT products, and we needed to agree on what the trustmark stood for, before we could go through the process of registering trademarks, and all the necessary legal bits.

The venue they had found was London Zoo, and it dovetailed (sorry) nicely with a good friend’s birthday.

So, I booked a train from Berlin to London and headed over for June 17th 2017 – 5 years to the day of the last event.

What, someone did something with those principles?

One of the things that really surprised me at the event, was that some larger companies had been paying attention to the work going into these principles as a way to carve out a competitive advantage.

In particular, we saw Stefan Ferber from Bosch talking about many of the same principles we had written about, and how they were applying them in their work.

In particular, he was talking about the benefits of trust when thinking about IoT – optimising for trust as response to an ever more complex world.

If I can trust the service or the product I’m using, rather than having an adversarial relationship (i.e. like I might with many low cost flight airlines, or ad-tech providers, or much of retail banking in the US, etc.), then it follows that I’m more likely to want to use offerings from the company making it over others.


Moderating the life cycle group

Shortly after some intros, we ended up splitting into interest groups, and I ended up helping moderate one of the sessions around the environmental and life-cycle aspects of IoT.

In our group, we had quite a wide mix of people, from young founders building VC-backed IoT startups, to people from the Restart Project talking about repair and design for remanufacture, and embedded programming specialists concerned with the end of life of IoT hardware.

We were looking at planned obsolescence, end of life support – for example, when hardware is literally embedded in your house, and you sell your house, but can’t transfer ownership of the devices, you have new kinds of problems we haven’t really had to deal with before.

Or when your phone works, but through software update policy is left dangerously vulnerable to hackers, to the extent it’s irresponsible to put data on it, you have the kinds of problems we were exploring that effectively make it unusable for many of the common use-cases you might associate with a typical smartphone.

We also looked into the embodied carbon, and fairness of the supply chains – where the minerals like coltan come from that make up your computer chips, and the conditions in which they’re made, and where hardware is assembled.

So, all the easy problems, then.

Our goal was to come up with some principles we could all agree to in our group, and would be prepared follow in this absolute discussion minefield of topics. As you imagine, getting someone in a VC-backed hardware startup set up for hyper growth to find common ground with a design for repair campaigner is not easy, but we ended up with a few principles we could take the the final session of the day.

One day we will learn

Usman, once again, trying to get 60 people to agree in a google document

And once again, we tried to get 60 people to agree to principles, but this time, we were trying to get something more concrete to put on a product, so it was even harder to find consensus.

Even after the back and forth within my group, we found that loads of the stuff we had settled on as uncontroversial had others pushing back hard – so we ended up with much more watered down set of ideas in the lifecycle section.

The Open IoTMark RFC

Like the last event, the culmination was a group of people, essentially yelling at poor Usman, as he and other people tried to write a document to capture all the ideas in the principles.

But this time round, given the number of engineers in the audience, someone came up with idea of describing these principles using the normative language you’d see from the IETF.org, with very specific, precise meanings applied to the words like MUST, SHALL, SHOULD, and so on.

I’ll be honest – this entire process was exhausting and not very satisfying.

This shouldn’t be news though, and it wasn’t isn’t a reflection on Usman’s skill as a facilitator – I think it’s very hard to avoid in cases like this.

As you move from principles you care about when it’s not your job to own the supply chain and deliver the returns an investor is expecting, to actually having to publicly say you’re prepared adopt these principles, of course you’re going to get push-back.

That said, Usman pushed on, and before we had to leave, we somehow ended up with a document that if everyone wasn’t happy with, they were prepared to co-sign it.

And that’s the background. Here’s the actual write up of the day.

On fairphone, and sustainable electronics

I’ve been a Fairphone user since 2013, when the first phone came out, and I’ve been a user of the FP2, the first phone the company designed fully themselves. In this post, I explain the process of updating it to extend its life, compared with buying a new one, and how hard doing sustainable electronics is.

A bit of background around Fairphone

It’s nice having things like smartphones, and handy electronics, but if you spend any time thinking about what really goes into getting them over to us, you’ll quickly realise there are some very ugly sides to doing so. Many of the minerals going into the electronics we use come from areas wracked by conflict, and conditions inside some factories making them can often be awful, and beyond the human cost, and it’s fair to say that if we do know about it, most of us are either in a state of denial or depression amount of waste created by digging this stuff out of the ground, turning it into chips and so on, and shipping it around the world to us.

Once hardware is with us, it’s often so hard to repair, that’s often cheaper or simpler to buy a new piece of hardware and send the old one to landfill than try to fix this, and the trend across the industry, is generally one that’s making this worse.

In the face of it’s, nice to know there are some companies looking at the problem, and trying to design a solution as if people, and well… the rest of the world mattered, and one of these companies is Fairphone. Coming from roots as a pressure group campaigning about the human cost of the electronics industry, Fairphone is now one of the mist interesting companies making electronics, and I’ve been an owner of both generations of the Fairphone FP1,  and Fairphone FP2 since I first heard of the company in 2012.

Aiming for sustainability through modularity and openness in phones

You can tell Fairphone is a product coming from a group of service designers – one thing I like about it is the attention to the entire lifecycle of the product, as well as how it’s used, to provide alterantive so needing to buy a new phone if you want benefit from the designers of the product learning more about how to improve it.

I’ll give a couple examples below:

Replaceable cases

If you want a phone to last, it’s common to put a handset in some kind of protective case. Of course for many phones this ruins the lines, and as a result it’s common to have a phone exposed to damage, largely to keep it looking comparative sleek and fit well in your pocket.

Fairphone’s approach is to design the phone so the outer casing already is slightly ruggedised to do the job of protecting it, and crucially, easy to replace, so when you DO inevitably drop it or damage it through wear and tear, you can buy just that part. By designing the case with this in mind, you don’t end up needing a bulky protective case that make the phone feel so much larger and awkward to handle.

It might be a stretch to refer to this as modular, but you can see this idea of having replacement parts in the cases. Over the last year and a half, I’ve managed to wear out part of my case, largely by dropping it and general abuse. So, I ended up buying a replacement case the new iterations of the FP2 are now released with. It was easy to replace at home, and it feels like the design is informed by actual user feedback since the original launch – the shape is slimmer making the phone feel smaller and fit better in my pocket, and the new case uses a different, higher quality plastic that is slightly rough, making it feel less slippery making it feel safe in my hand.


Better cameras

I think I’ve had my FP2 for about two years now, and over that time, I’ve been largely happy with it, for what I use it for – the GPS works well for way-finding and exercise, and it’s more or less fast enough to be a good working device. The camera hasn’t been great though, and the battery life has been a pain at times.

The new generation of the phone has a better set of cameras, but for existing owners like me, Fairphone have made the camera modules available to order separately.

I ordered them, and replacing them turned out to be straight forward. I know have a new camera, and new case, and the phone largely feels like a new handset, extending the useful life by at least a year or so.

You can see the difference in two somewhat similar photos below:

The limits of this approach

The camera works better now, and I’m a much happier with the case but there are limits. When it was first announced, the Fairphone was released with Android 5. This was okay, but newer versions of the Android operating system have improvements  to how your permissions and privacy work. This year, Fairphone managed to release an update to Android 6, but in many new phones, there’s a new version of the operating system with further improvements.

From what I can tell, the because of some details in the chipset used by the FP2, it either can’t be upgraded to Android 7, or it’s going to be a pain to do so. It’s not a concern right now, but shortens the phone’s useful life.

This is really, really hard

I guess the point of this post was that even Fairphone, one of the world leaders in building electronics in an open, sustainable, largely planet friendly way, have a hard time making a business out of building complex physical product this way, but it still feels worth aiming for, because well… we only have one planet left, and people matter.

If this interests you, you might be interested in the IoTMark project, that came out of the Open Internet of things Certification Mark event run this summer and DotEveryone’s efforts to make a Trustworthy techmark.