Fixing Web Login

Dual elevator door buttons

You know the conventional wisdom that the "close" button in elevators isn't really hooked up to anything. That it's just there to make you feel good? "Keep me logged in" is digital identity's version of that button. Why is using authenticated service on the web so unpleasant?

Note that I'm specifically talking about the web, as opposed to mobile apps. As I wrote before, compare your online, web experience at your bank with the mobile experience from the same bank. Chances are, if you're like me, that you pick up your phone and use a biometric authentication method (e.g. FaceId) to open it. Then you select the app and the biometrics play again to make sure it's you, and you're in.

On the web, in contrast, you likely end up at a landing page where you have to search for the login button which is hidden in a menu or at the top of the page. Once you do, it probably asks you for your identifier (username). You open up your password manager (a few clicks) and fill the username and only then does it show you the password field1. You click a few more times to fill in the password. Then, if you use multi-factor authentication (and you should), you get to open up your phone, find the 2FA app, get the code, and type it in. To add insult to injury, the ceremony will be just different enough at every site you visit that you really don't develop much muscle memory for it.

As a consequence, when most people need something from their bank, they pull out their phone and use the mobile app. I think this is a shame. I like the web. There's more freedom on the web because there are fewer all-powerful gatekeepers. And, for many developers, it's more approachable. The web, by design, is more transparent in how it works, inspiring innovation and accelerating it's adoption.

The core problem with the web isn't just passwords. After all, most mobile apps authenticate using passwords as well. The problem is how sessions are set up and refreshed (or not, in the case of the web). On the web, sessions are managed using cookies, or correlation identifiers. HTTP cookies are generated by the server and stored on the browser. Whenever the browser makes a request to the server, it sends back the cookie, allowing the server to correlate all requests from that browser. Web sites, over the years, have become more security conscious and, as a result, most set expirations for cookies. When the cookie has expired, you have to log in again.

Now, your mobile app uses HTTP as well, and so it also uses cookies to link HTTP requests and create a session. The difference is in how you're authenticated. Mobile apps (speaking generally) are driven by APIs. The app makes an HTTP request to the API and receives JSON data in return which it then renders into the screens and buttons you interact with. Most API access is protected by an identity protocol called OAuth.

Getting an access token from the authorization server
Getting an access token from the authorization server (click to enlarge)
Using a token to request data from an API
Using a token to request data from an API (click to enlarge)

You've used OAuth if you've ever used any kind of social login like Login with Apple, or Google sign-in. Your mobile app doesn't just ask for your user ID and password and then log you in. Rather, it uses them to authenticate with an authentication server for the API using OAuth. The standard OAuth flow returns an authentication token that the app stores and then returns to the server with each request. Like cookies, these access tokens expire. But, unlike cookies, OAuth defines a refresh token mechanism that the app can be use to get a new access token. Neat, huh?

The problem with using OAuth on the web is that it's difficult to trust browsers:

  • Some are in public places and people forget to log out.
  • A token in the browser can be attacked with techniques like cross-site scripting.
  • Browser storage mechanisms are also subject to attack.

Consequently, storing the access token, refresh token, and developer credentials that are used to carry out an OAuth flow is hard—maybe impossible—to do securely.

Solving this problem probably won't happen because we solved browser security problems and decided to use OAuth in the browser. A more likely approach is to get rid of passwords and make repeated authentication much less onerous. Fortunately, solutions are at hand. Most major browsers on most major platforms can now be used as FIDO platform authenticators. This is a fancy way of saying you can use the the same mechanisms you use to authenticate to the device (touch ID, face ID, or even a PIN) to authenticate to your favorite web site as well. Verifiable credentials are another up and coming technology that promises to significantly reduce the burdens of passwords and multi-factor authentication.

I'm hopeful that we may really be close to the end for passwords. I think the biggest obstacle to adoption is likely that these technologies are so slick that people won't believe they're really secure. If we can get adoption, then maybe we'll see a resurgence of web-based services as well.


  1. This is known as "identifier-first authentication". By asking for the identifier, the authentication service can determine how to authenticate you. So, if you're using a token authentication instead of passwords, it can present the right option. Some places do this well, merely hiding the password field using Javascript and CSS, so that password managers can still fill the password even though it's not visible. Others don't, and you have to use your password manager twice for a single login.

Photo Credit: Dual elevator door buttons from Nils R. Barth (CC0 1.0)

Transferable Accounts Putting Passengers at Risk

A Buenos Aires taxi ride

Bolt is a hired-car service like Uber or Lyft. Bolt is popular because its commissions are less than other ride-sharing platforms. In Bolt drivers in Nigeria are illicitly selling their accounts, putting passengers at risk Rest of World reports on an investigation showing that Bolt drivers in Nigeria (and maybe other countries) routinely sell verified accounts to third parties. The results are just what you'd expect:

Adede Sonaike is another Lagos-based Bolt user since 2018, and said she gets frequently harassed and shouted at by its drivers over even the simplest of issues, such as asking to turn down the volume of the car stereo. Sonaike said these incidents have become more common and that she anticipates driver harassment on every Bolt trip. But on March 18, she told Rest of World she felt that her life was threatened. Sonaike had ordered a ride, and confirmed the vehicle and plate number before entering the car. After the trip started, she noticed that the driver’s face didn’t match the image on the app. “I asked him why the app showed me a different face, and he said Bolt blocked his account and that [he] was using his brother’s account, and asked why I was questioning him,” she recalled. She noticed the doors were locked and the interior door handle was broken, and became worried. Sonaike shared her ride location with her family and asked the driver to stop, so she could end the trip. He only dropped her off after she threatened to break his windows.
From Bolt drivers in Nigeria are illicitly selling their accounts
Referenced 2022-06-09T09:44:24-0400

The problem is accounts are easily transferable and reputations tied to transferable accounts can't be trusted since they don't reflect the actions of the person currently using the account. Making accounts non-transferable using traditional means is difficult because they're usually protected by something you know (e.g., a password) and that can be easily changed and exchanged. Even making the profile picture difficult to change (like Bolt apparently does) isn't a great solution since people may not check the picture, or fall for stories like the driver gave the passenger in the preceding quote.

Verifiable credentials are a better solution because they're designed to not be transferable1. Suppose Bob wants to sell his Bolt account to Malfoy. Alice, a rider wants to know the driver is really the holder of the account. Bolt issued a verifiable credential (VC) to Bob when he signed up. The VC issuing and presenting protocols cryptographically combine an non-correlatable identifier and a link secret and use zero-knowledge proofs (ZKPs) to present the credential. ZKP-based credential presentations have a number of methods that can be used to prevent transferring the credential. I won't go into the details, but the paper I link to provides eight techniques that can be used to prevent the transfer of a VC. We can be confident the VC was issued to the person presenting it.

Bolt could require that Bob use the VC they provided when he signed up to log into his account each time he starts driving. They could even link a bond or financial escrow to the VC to ensure it's not transferred. To prevent Bob from activating the account for Malfoy at the beginning of each driving period, Alice, and other passengers could ask drivers for proof that they're a legitimate Bolt driver by requesting a ZKP from the Bolt credential. Their Bolt app could do this automatically and even validate that the credential is from Bolt.

Knowing that the credential was issued to the person presenting it is one of the four cryptographic cornerstones of credential fidelity. The Bolt app can ensure the provenance of the credential Bob presents. Alice doesn't have trust Bob or know very much about Bob personally, just that he really is the driver that Bolt has certified.

The non-transferability of verifiable credential is one of their super powers. A lot of the talk about identity in Web 3 has focused on NFTs. NFTs are, for the most part, designed to be transferable2. In that sense, they're no better than a password-protected account. Identity relies on knowing that the identifiers and attributes being presented are worthy of confidence and can be trusted. Otherwise, identity isn't reducing risk the way it should. That can't happen with transferable identifiers—whether their password-based accounts or even NFTs. There's no technological barrier to Bolt implementing this solution now...and they should for the safety of their customers.


  1. I'm speaking of features specific to the Aries credential exchange protocol in this post.
  2. Recently Vatalik el. al. proposed what they call a soul-bound token as a non-transferable credential type for Web3. I'm putting together my thoughts on that for a future post.

Photo Credit: A Buenos Aires taxi ride from Phillip Capper (CC BY 2.0)

Twenty Years of Blogging

Macbook Air keyboard

Leslie Lamport said "If you think you understand something, and don’t write down your ideas, you only think you’re thinking." I agree wholeheartedly. I often think "Oh, I get this" and then go to write it down and find all kinds of holes in my understanding. I write to understand. Consequently, I write my blog for me. But I hope you get something out of it too!

I started blogging in May 2002, twenty years ago today. I'd been thinking about blogging for about a year before that, but hadn't found the right tool. Jon Udell, who I didn't know then, mentioned his blog in an InfoWorld column. He was using Dave Winer's Radio Userland, so I downloaded it and started writing. At the time I was CIO for the State of Utah, so I garnered a bit of noteriety as a C-level blogger. And I had plenty of things to blog about.

Later, I moved to MovableType and then, like many developers who blog, wrote my own blogging system. I was tired of the complexity of blogging platforms that required a database. I didn't want the hassle. I write the body of each post using Emacs using custom macros I created. Then my blogging system generates pages from the bodies using a collection of templates. I use rsync to push them up to my server on AWS. Simple, fast, and completely under my control.

Along the way, I've influenced my family to blog. My wife, Lynne, built a blog to document her study abroad to Europe in 2019. My son Bradford has a blog where he publishes short stories. My daughter Alli is a food blogger and entrepreneur with a large following. My daughter Samantha is an illustrator and keeps her portfolio on her blog.

Doc Searls, another good friend who I met through blogging, says you can make money from your blog or because of it. I'm definately in the latter camp. Because I write for me, I don't want to do the things necessary to grow an audience and make my blog pay. But my life and bank account are richer because I blog. Jon, Dave, and Doc are just a few of countless friends I've made blogging. I wouldn't have written my first book if Doug Kaye, another blogging friend, hadn't suggested it. I wouldn't have started Internet Identity Workshop or been the Executive Producer of IT Conversations. I documented the process of creating my second startup, Kynetx on my blog. And, of course, I've written a bit (402 posts so far, almost 10% of the total) on identity. I've been invited to speak, write, consult, and travel because of what I write.

After 20 years, blogging has become a way of life. I think about things to write all the time. I can't imagine not blogging. Obviously, I recommend it. You'll become a better writer if you blog regularly. And you'll better understand what you write about. Get a domain name so you can move it, because you will, and you don't want to lose what you've written. You may not build a brand, but you'll build yourself and that's the ultimate reward for blogging.

Photo Credit: MacBook Air keyboard 2 from TheumasNL (CC BY-SA 4.0)

Using a Theory of Justice to Build a Better Web3


Philosophy discussions are the black hole of identity. Once you get in, you can't get out. Nevertheless, I find that I'm drawn to them. I'm a big proponent of self-sovereign identity (SSI) precisely because I believe that autonomy and agency are a vital part of building a new web that works for everyone. Consequently, I read Web3 Is Our Chance to Make a Better Internet with interest because it applied John Rawls's thought experiment known as the "veil of ignorance1," from his influential 1971 work A Theory of Justice to propose three things we can do in Web3 to build a more fair internet:

  1. Promote self-determination and agency
  2. Reward participation, not just capital
  3. Incorporate initiatives that benefit the disadvantaged

Let's consider each of these in turn.

Promoting Self-Determination and Agency

As I wrote in Web3: Self-Sovereign Authority and Self-Certifying Protocols,

Web3, self-sovereign authority enabled by self-certifying protocols, gives us a mechanism for creating a digital existence that respects human dignity and autonomy. We can live lives as digitally embodied beings able to operationalize our digital relationships in ways that provide rich, meaningful interactions. Self-sovereign identity (SSI) and self-certifying protocols provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. When we dine at a restaurant or shop at a store in the physical world, we do not do so within some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. Web3, built in this way, allows people to act as full-fledged participants in the digital realm.

There are, of course, ways to screw this up. Notably, many Web3 proponents don't really get identity and propose solutions to identity problems that are downright dangerous and antithetical to their aim of self-determination and agency. Writing about Central Bank Digital Currencies (CBDCs), Dave Birch said this:

The connection between digital identity and digital currency is critical. We must get the identity side of the equation right before we continue with the money side of the equation. As I told the Lords' committee at the very beginning of my evidence, "I am a very strong supporter of retail digital currency, but I am acutely aware of the potential for a colossal privacy catastrophe".
From Identity And The New Money
Referenced 2022-05-18T16:14:50-0600

Now, whether you see a role for CBDCs in Web3 or see them as the last ditch effort of the old guard to preserve their relevance, Dave's points about identity are still true regardless of what currency systems you support. We don't necessarily want identity in Web3 for anti-money laundering and other fraud protection mechanisms (although those might be welcomed in a Web3 world that isn't a hellhole), but because identity is the basis for agency. And if we do it wrong, we destroy the very thing we're trying to promote. Someone recently said (I wish I had a reference) that using your Ethereum address for your online identity is like introducing yourself at a party using your bank balance. A bit awkward at least.

Rewarding Participation

If you look at the poster children of Web3, cryptocurrencies and NFTs, the record is spotty for how well these systems reward participation rather than rewarding early investors. But that doesn't have to be the case. In Why Build in Web3, Jad Esber and Scott Duke Kominers describe the "Adam Bomb" NFT:

For example, The Hundreds, a popular streetwear brand, recently sold NFTs themed around their mascot, the "Adam Bomb." Holding one of these NFTs gives access to community events and exclusive merchandise, providing a way for the brand's fans to meet and engage with each other — and thus reinforcing their enthusiasm. The Hundreds also spontaneously announced that it would pay royalties (in store credit) to owners of the NFTs associated to Adam Bombs that were used in some of its clothing collections. This made it roughly as if you could have part ownership in the Ralph Lauren emblem, and every new line of polos that used that emblem would give you a dividend. Partially decentralizing the brand's value in this way led The Hundreds's community to feel even more attached to the IP and to go out of their way to promote it — to the point that some community members even got Adam Bomb tattoos.
From Why Build in Web3
Referenced 2022-05-17T14:42:53-0600

NFTs are a good match for this use case because they represent ownership and are transferable. The Hundreds doesn't likely care if someone other than the original purchaser of an Adam Bomb NFT uses it to get a discount so long as they can authenticate it. Esber and Kominers go on to say:

Sharing ownership allows for more incentive alignment between products and their derivatives, creating incentives for everyone to become a builder and contributor.

NFTs aren't the only way to reward participation. Another example is the Helium Network. Helium is a network of more than 700,000 LoRaWAN hotspots around the world. Operators of the hotspots, like me, are rewarded in HNT tokens for providing the hotspot and network backhaul using a method called "proof of coverage" that ensures the hotspot is active in a specific geographic area. The reason the network is so large is precisely because Helium uses its cryptocurrency to reward participants for the activities that grow the network and keep it functioning.

Building web3 ecosystems that reward participation is in stark contrast to Web 2.0 platforms that treat their participants as mere customers (at best) or profit from surveillance capitalism (at worst).

Incorporating Initiatives that Benefit the Disadvantaged

The HBR article acknowledges that this is the hardest one to enable using technology. That's because this is often a function of governance. One of the things we tried to do at Sovrin Foundation was live true to the tagline: Identity for All. For example, we spent a lot of time on governance for just this reason. For example, many of the participants in the Foundation worked on initiatives like financial inclusion and guardianship to ensure the systems we were building and promoting worked for everyone. These efforts cost us the support of some of our more "business-oriented" partners and stewards who just wanted to get to the business of quickly building a credential system that worked for their needs. But we let them walk away rather than cutting back on governance efforts in support of identity for all.

The important parts of Web3 aren't as sexy as ICOs and bored apes, but they are what will ensure we build something that supports a digital life worth living. Web 2.0 didn't do so well in the justice department. I believe Web3 is our chance to build a better internet, but only if we promote self-determination, reward participation, and build incentives that benefit the disadvantaged as well as those better off.


  1. The "veil of ignorance" asks a system designer to consider what system they would design if they were in a disadvantaged situation, rather than their current situation. For example, if you're designing a cryptocurrency, assume you're one of the people late to the game. What design decisions would make the system fair for you in that situation?

Photo Credit: Artists-impressions-of-Lady-Justice from Lonpicman (CC BY-SA 3.0)

Decentralizing Agendas and Decisions

Opening Circle at IIW 34

Last month was the 34th Internet Identity Workshop (IIW). After doing the last four virtually, it was spectacular to be back together with everyone at the Computer History Museum. You could almost feel the excitement in the air as people met with old friends and made new ones. Rich the barista was back, along with Burrito Wednesday. I loved watching people in small groups having intense conversations over meals, drinks, and snacks.

Also back was IIW's trademark open space organization. Open space conferences are workshops that don't have pre-built agendas. Open space is like an unconference with a formal facilitator trained in using open space technology. IIW is self-organizing, with participants setting the agenda every morning before we start. IIW has used open space for part or all of the workshop since the second workshop in 2006. Early on, Kaliya Young, one of my co-founders (along with Doc Searls), convinced me to try open space as a way of letting participants shape the agenda and direction. For an event this large (300-400 participants), you need professional facilitation. Heidi Saul has been doing that for us for years. The results speak for themselves. IIW has nurtured many of the ideas, protocols, and trends that make up modern identity systems and thinking.

Welcome to IIW 34!
Welcome to IIW 34! (click to enlarge)
mDL Discussion at IIW 34mDL Discussion at IIW 34
mDL Discussion at IIW 34 (click to enlarge)
Agenda Wall at IIW 34 (Day 1)
Agenda Wall at IIW 34 (Day 1) (click to enlarge)

Last month was the first in-person CTO Breakfast since early 2020. CTO Breakfast is a monthly gathering of technologists in the Provo-Salt Lake City area that I've convened for almost 20 years. Like IIW, CTO Breakfast has no pre-planned agenda. The discussion is freewheeling and active. We have just two rules: (1) no politics and (2) one conversation at a time. Topics from the last meeting included LoRaWAN, Helium network, IoT, hiring entry-level software developers, Carrier-Grade NATs, and commercial real estate. The conversation goes where it goes, but is always interesting and worthwhile.

When we built the University API at BYU, we used decentralized decision making to make key architecture, governance, and implementation decisions. Rather than a few architects deciding everything, we had many meetings, with dozens of people in each, over the course of a year hammering out the design.

What all of these have in common is decentralized decision making by a group of people that results in learning, consensus, and, if all goes well, action. The conversation at IIW, CTO Breakfast, and BYU isn't the result a few smart people deciding what the group needed to hear and then arranging meetings to push it at them. Instead, the group decides. Empowering the group to make decisions about the very nature and direction of the conversation requires trust and trust always implies vulnerability. But I've become convinced that it's really the best way to achieve real consensus and make progress in heterogeneous groups. Thanks Kaliya!

Is an Apple Watch Enough?

Apple iPhone and Watch

Last week, I conducted an experiment. My phone battery needed to be replaced and the Authorized Apple Service Center was required to keep it while they ordered the new battery from Apple (yeah, I think that's a stupid policy too). I was without my phone for 2 days and decided it was an excellent time to see if I could get by using my Apple Watch as my primary device. Here's how it went.

  • First things first. For this to be any kind of success you need a cellular plan for your watch and a pair of Airpods or other bluetooth earbuds.
  • The first thing I noticed is that the bathroom, standing in the checkout line, and other places are boring without the distraction of my phone to read news, play Wordle, or whatever.
  • Siri is your friend. I used Siri a lot more than normal due to the small screen.
  • I'd already set up Apple Pay and while I don't often use it from my watch under normal circumstances, it worked great here.
  • Answering the phone means keeping your Airpods in or fumbling for them every time there's a call. I found I rejected a lot of calls to avoid the hassle. (But never your's, Lynne!) Still, I was able to take and make calls just fine without a phone.
  • Voicemail access is a problem. You have to call the number and retrieve them just like it's 1990 or something. This messed with my usual strategy of not answering calls from numbers I don't recognize and letting them go to voicemail, then reading the transcript to see if I want to call them back.
  • Normal texts don't work that I could tell, but Apple Messages do. I used voice transcription almost exclusively for sending messages, but read them on the watch.
  • Most crypto wallets are unusable without the phone.
  • For the most part, I just used the Web for banking as a substitute for mobile apps and that worked fine. The one exception was USAA.
  • The problem with USAA was 2FA. Watch apps for 2FA are "companion apps" meaning they're worthless without the phone. For TOTP 2FA, I'd mirrored to my iPad, so that worked fine. I had to use the pre-set tokens for Duo that I'd gotten when I set it up. USAA uses Verisign's VIP. It can't be mirrored. What's more, USAA's recovery relies on SMS. I didn't have my phone, so that didn't work. I was on the phone with USAA for an hour trying to figure this out. Eventually USAA decided it was hopeless and told me to conduct banking by voice. Ugh.
  • Listening to music on the watch worked fine.
  • I read books on my Kindle, so that wasn't a problem.
  • There are a number of things I fell back to my iPad for. I've already mentioned 2FA, another is maps. Maps don't work on the watch.
  • I didn't realize how many pictures I take in a day, sometimes just for utility. I used the iPad when I had to.
  • Almost none of my IoT services or devices did much with the watch beyond issuing a notification. None of the Apple HomeKit stuff worked that I could see. For example, I often use a HomeKit integration with my garage door opener. That no longer worked without a phone.
  • Battery life on the watch is more than adequate in normal situations. But hour long phone calls and listening to music challenge battery life when it's your primary device.
  • I didn't realize how many things are tied just to my phone number.

Using just my Apple Watch with some help from my iPad was mostly doable, but there are still rough spots. The Watch is a capable tool for many tasks, but it's not complete. I can certainly see leaving my phone at home more often now since most things work great—especially when you know you can get back to your phone when you need to. Not having my phone with me feels less scary now.

Photo Credit: IPhone 13 Pro and Apple Watch from Simon Waldherr (CC BY-SA 4.0)

We Need a Self-Sovereign Model for IoT

Insteon isn't keeping the lights on!

Last week Insteon, a large provider of smart home devices, abruptly closed its doors. While their web site is still up and advertises them as "the most reliable and simplest way to turn your home into a smart home," the company seems to have abruptly shut down their cloud service without warning or providing a way for customers to continue using their products, which depend on Insteon's privacy cloud. High-ranking Insteon execs even removed their affiliation with Insteon from their LinkedIn profiles. Eek!

Fortunately, someone reverse-engineered the Insteon protocol a while back and there are some open-source solutions for people who are able to run their own servers or know someone who can do it for them. Home Assistant is one. OpenHAB is another.

Insteon isn't alone. Apparently iHome terminated its service on April 2, 2022. Other smarthome companies or services who have gone out of business include Revolv, Insignia, Wink, and Staples Connect.

The problem with Insteon, and every other IoT and Smarthome company I'm aware of is that their model looks like this:

Private Cloud IoT Model
Private cloud IoT model; grey box represents domain of control

In this model, you:

  1. Buy the device
  2. Download their app
  3. Create an account on the manufacturer's private cloud
  4. Register your device
  5. Control the device from the app

All the data and the device are inside the manufacturer's private cloud. They administer it all and control what you can do. Even though you paid for the device, you don't own it because it's worthless without the service the manufacturer provides. If they take your account away (or everyone's account, in the case of Insteon), you're out of luck. Want to use your motion detector to turn on the lights? Good luck unless they're from the same company1. I call this the CompuServe of Things.

The alternative is what I call the self-sovereign IoT (SSIoT) model:

Self-Sovereign IoT Model
Self-sovereign IoT model; grey box represents domain of control

Like the private-cloud model, in the SSIoT model, you also:

  1. Buy the device
  2. Download an app
  3. Establish a relationship with a compatible service provider
  4. Register the device
  5. Control the device using the app

The fact that the flows for these two models are the same is a feature. The difference lies elsewhere: in SSIoT, your device, the data about you, and the service are all under your control. You might have a relationship with the device manufacturer, but you and your devices are not under their administrative control. This might feel unworkable, but I've proven it's not. Ten years ago we built a connected-car platform called Fuse that used the SSIoT model. All the data was under the control of the person or persons who owned the fleet and could be moved to an alternate platform without loss of data or function. People used the Fuse service that we provided, but they didn't have to. If Fuse had gotten popular, other service providers could have provided the same or similar service based on the open-model and Fuse owners would have had a choice of service providers. Substitutability is an indispensable property for the internet of things.

All companies die. Some last a long time, but even then they frequently kill off products. Having to buy all your gear from a single vendor and use their private cloud puts your IoT project at risk of being stranded, like Insteon customers have been. Hopefully, the open-source solutions will provide the basis for some relief to them. But the ultimate answer is interoperability and self-sovereignty as the default. That's the only way we ditch the CompuServe of Things for a real internet of things.


  1. Apple HomeKit and Google Home try to solve this problem, but you're still dependent on the manufacturer to provide the basic service. And making the administrative domain bigger is nice, but doesn't result in self-sovereignty.

John Oliver on Surveillance Capitalism

Surveillance capitalism is a serious subject that can be hard to explain, let alone make interesting. I believe that it threatens our digital future. The question is "what to do about it?"

John Oliver's Last Week Tonight recently took on the task of explaining surveillance capitalism, how it works, and why it's a threat. I recommend watching it. Oliver does a great job of explaining something important, complex, and, frankly, a little boring in a way that is both funny and educational.

But he didn't just explain it. He took some steps to do something about it.

In researching this story, we realized that there is any number of perfectly legal bits of f—kery that we could engage in. We could, for example, use data brokers to go phishing for members of congress, by creating a demographic group consisting of men, age 45 and up, in a 5-mile radius of the U.S. Capitol, who had previously visited sites regarding or searched for terms including divorce, massage, hair loss and mid-life crisis.

The result is a collection of real data from their experiment that Oliver threatens to reveal if Congress doesn't act. The ads they ran were Marriage shouldn't be a prison, Can you vote twice?, and Ted Cruz erotic fan fiction. I'm not sure it will actually light a fire under so moribund an institution as Congress, but it's worth a shot!

Easier IoT Deployments with LoraWan and Helium

Helium Discharge Tube

I've been interested in the internet of things (IoT) for years, even building and selling a connected car product called Fuse at one point. One of the hard parts of IoT is connectivity, getting the sensors on some network so they can send data back to wherever it's aggregated, analyzed, or used to take action. Picos are a good solution for the endpoint—where the data ends up—but the sensor still has to get connected to the internet.

Wifi, Bluetooth, and cellular are the traditional answers. Each has their limitations in IoT.

  • Wifi has limited range and, outside the home environment, usually needs a separate device-only network because of different authentication requirements. If you're doing a handful of devices it's fine, but it doesn't easily scale to thousands. Wifi is also power hungry, making it a poor choice for battery-powered applications.
  • Bluetooth's range is even more limited, requiring the installation of Bluetooth gateways. Bluetooth is also not very secure. Bluetooth is relatively good with power. I've had temperature sensor on Bluetooth that ran over a year on a 2025 battery. But still, battery replacement can end up being rel maintenance headache.
  • Cellular is relatively ubiquitous, but it can be expensive and hard to manage. Batteries for for cell phones because people charge them every night. That's not reasonable for many IoT applications, so cellular-based sensors usually need to be powered.

Of course, there are other choices using specialized IoT protocols like ZWave, Zigbee, and Insteon, for example. These all require specialize hubs that must be bought, managed, and maintained. To avoid single points of failure, multiple hubs are needed. For a large industrial deployment this might be worth the cost and effort. Bottom line: Every large IoT project spends a lot of time and money designing and managing the connectivity infrastructure. This friction reduces the appeal of large-scale IoT deployments.

Enter LoraWAN, a long-range (10km), low-power wireless protocol for IoT. Scott Lemon told me about LoRaWAN recently and I've been playing with it a bit. Specifically, I've been playing with Helium, a decentralized LoRaWAN network.

Helium is a LoRaWAN network built from hotspots run by almost anyone. In one of the most interesting uses of crypto I've seen, Helium pays people helium tokens for operating hotspots. They call the model "proof of coverage". You get paid two ways: (1) providing coverage for a given geographical area and (2) moving packets from the radio to the internet. This model has provided amazing coverage with over 700,000 hotspots deployed to date. And Helium expended very little capital to do it, compared with building out the infrastructure on their own.

I started with one of these Dragino LHT65 temperature sensors. The fact that I hadn't deployed my own hotspot was immaterial because there's plenty of coverage around me.

LHT65 Temperature Sensor
LHT65 Temperature Sensor (click to enlarge)

Unlike a Wifi network, you don't put the network credentials in the device, you put the devices credentials (keys) in the network. Once I'd done that, the sensor started connecting to hotspots near my house and transmitting data. Today I've been driving around with it in my truck and it's roaming onto other hotspots as needed, still reporting temperatures.

Temperature Sensor Coverage on Helium
Temperature Sensor Coverage on Helium (click to enlarge)

Transmitting data on the Helium network costs money. You pay for data use with data credits (DC). You buy DC with the Helium token (HNT). Each DC costs a fixed rate of $0.00001 per 24 bytes of data. That's about $0.42/Mb, which isn't dirt cheap when compared to your mobile data rate, but you're only only paying for the data you use. For 100 sensors, transmitting 3 packets per hour for a year would cost $2.92. If each of those sensors needed a SIM card and cellular account, the comparable price would be orders of magnitude higher. So, the model fits IoT sensor deployments well. And the LHT65 has an expected battery life of 10 years (at 3 packets per hour) which is also great for large-scale sensor deployments.

Being able to deploy sensors without having to also worry about building and managing the connection infrastructure is a big deal. I could put 100 sensors up around a campus, a city, a farm, or just about anywhere and begin collecting the data from them without worrying about the infrastructure, the cost, or maintenance. My short term goal is to start using these with Picos and build out some rulesets and the UI for using and managing LoRaWAN sensors. I also have one of these SenseCAP M1 LoRaWAN gateways that I'm going to deploy in Idaho later (there are already several hotspots near my home in Utah). I'll let you know how all this goes.

Photo Credit: Helium discharge tube from Heinrich Pniok (CC BY-NC-ND 3.0). Image was cropped vertically.

The Ukrainian War, PKI, and Censorship

Flag of Russia with HTTPS bar overlaid

Each semester I have students in my distributed systems class read Rainbow's End, a science fiction book by Vernor Vinge set in the near future. I think it helps them imagine a world with vastly distributed computing infrastructure that is not as decentralized as it could be and think about the problems that can cause. One of the plot points involves using certificate authorities (CA) for censorship.

To review briefly, certificate authorities are key players in public key infrastructure (PKI) and are an example of a core internet service that is distributed and hierarchical. Whether your browser trusts the certificate my web server returns depends on whether it trusts the certificate used to sign it, and so on up the certificate chain to the root certificate. Root certificates are held in browsers or operating systems. If the root certificate isn't known to the system, then it's not trusted. Each certificate might be controlled by a different organization (i.e. they hold the private key used to sign it), but they all depend on confidence in the root. Take out the root and the entire chain collapses.

Certificate validation path for
Certificate validation path for (click to enlarge)

The war in Ukraine has made hypothetical worries about the robustness of the PKI all too real. Because of the sanctions imposed on Russia, web sites inside Russia can't pay foreign CAs to renew their certificates. Modern browsers don't just shrug this off, but issue warnings and sometimes even block access to sites with expired certificates. So, the sanctions threaten to cripple the Russian web.

In response, Russia has established its own root certificate authority (see also this from KeyFactor). This is not merely a homegrown CA, located in Russia, but a state-operated CA, subject to the whims and will of the Russian government (specifically the Ministry of Digital Development).

This is interesting from several perspectives. First, from a censorship perspective, it means that Russia can effectively turn off web sites by revoking their certificates, allowing the state to censor web sites for any reason they see fit. Hierarchical networks are especially vulnerable to censorship. And while we might view state-controlled CAs as a specific problem, any CA could be a point of censorship. Recall that while SWIFT is a private company, it is located in Belgium and subject to Belgian and European law. Once Belgium decided to sanction Russia, SWIFT had to go along. Similarly, a government could pass a law mandating the revocation of any certificate for a Russian company and CAs subject to their legal jurisdiction would go along.

From the perspective of users, it's also a problem. Only two browsers support the root certificate of the new Russian CA: the Russian-based Yandex and open-source Atom. I don't think it's likely that Chrome, Safari, Firefox, Brave, Edge, and others will be adding the new Russian root CA anytime soon. And while you can add certificates manually, most people will find that difficult.

Lastly, it's a problem for the Russian economy. The new Russian CA is a massive single point of failure, even if the Russian government doesn't use it to censor. Anonymous, state actors, and other groups can target the new CA and bring large swaths of the Russian internet down. So, state-controlled and -mandated CAs are a danger to the economy they serve. Russia's actions in response to the exigency of the war are understandable, but I suspect it won't go back even after the war ends. Dependence on a single state-run CA is a problem for Russia and its citizens.

State-controlled CAs further balkanize the internet. They put web sites at risk of censorship. They make life difficult for users. They create centralized services that threaten economic stability and vibrancy. In general, hierarchies are not good architectures for building robust, trustworthy, and stable digital systems. PKI has allowed us to create a global trust framework for the web. But the war in Ukraine has shone a light on its weaknesses. We should heed this warning to engineer more decentralized infrastructures that give us confidence in our digital communications.

Photo Credits: