Will tying web IDs to hosters create lock-in?


#1

Just saw this question over on Google+ about whether tying Solid identities to hosters might lock end-users into big players over time. Any insights here? I ask as someone who is trying to explain the platform to others.

Tim Berners-Lee’s Solid Project: Can It Save the Web?

Since the location of your POD is stored in your ID, it is easy to relocate your POD as needed. However, the proposed WebIDs include the domain name of the identity provider. For example, if you get your WebID from Berners-Lee’s own Solid startup, Inrupt, it will be of the form <userid>@inrupt.net. So you can’t easily move your WebID. To make matters worse, it’s likely that if Solid becomes successful most users will get their WebIDs the easiest possible way — from one of the places they already have an identity like Google or Facebook. Those companies would then still have leverage over them, and also would have full knowledge of queries made about the ID. I suspect they’d also be the major provider of POD storage as well, meaning they’ll have fairly complete audit trails of your activity on the web.


#2

I think Solid would have to offer the same thing facebook, google, apple and the like are agreeing to do, the ability to export your data ready to go to a pod provider of choice.


#3

This is less about the data though, and more about your identity. Let’s say that I’ve invested deeply in Solid and there are lots of pointers from various apps to my inrupt profile. What happens if I decide to switch pod providers and, as a result, change my profile address? How are third party apps notified that my address has changed?


#4

https://solid.inrupt.com/docs/intro-to-solid-spec “Authentication of that identity is provided using WebID-TLS and WebID-OIDC right now, but other strategies, such as key fobs, or two factor authentication, could be added to depending on system needs.” so lets say you switch providers, with two factor you should be able to authenticate to your apps that the new provider is authorized by you.


#5

It’s not really an authentication problem though. It’s an address problem. Let’s say your email address is currently first.last@gmail.com and you want to switch away from Google to some future inrupt-hosted email where your new email address would be first.last@inrupt.com. You need to tell all your contacts to switch and probably back that up by Google agreeing to some sort of mail forwarding capabilities.

Contrast that with web hosting, in which case you have a domain name that can be more or less easily moved to a new hoster without having to notify the world of your new address.

So, the question I’m raising here is whether Solid is adopting the email addressing convention and the problems that seems to have or something more portable like web hosting. And yes, it’s true that you can use Gmail with your own custom domain. Perhaps that is the solution here.


#6

It is a solution, but as with email, not for many. Using the existing domain system is a weakness, and with it come some of the means to capture users and make it hard for them to move. I’m interested to hear from Inrupt and others what they regard as the weaknesses of Solid as well as its strengths. When I’ve voiced related issues which I think will lead to centralisation, the impression I have is that they aren’t taken seriously.


#7

Seems like it all boils down to having chosen “Linked Data Protocol” as the means for storing and referencing data. Once you have made that choice, it is hard to do anything about the fact that resource identifier (your POD’s name) and resource location (Your POD’s data location) is one and same thing - you cannot change one without changing the other.

You would need some kind of shared peer-to-peer database mapping from “my POD’s identifier” to “my POD’s actual data location” … which, on the other hand, is what the domain name system does already - mapping from names to IP-numbers. So it’s more a matter of the business model around domain names than a technicality - or what?

I mean, if the POD hosting providers allowed you to choose you own hostname (as if they were a “real” web hosting company) then you wouldn’t have any problems … right? You could easily move your POD data from one host to another as your hostname would move with you. All it requires is for the POD hosters, like inrupt, to accept that user needs more freedom than “my-pod.inrupt.com” … but that would have to be a paid service since personal hostnames cost an anual fee. Again - its a matter of the business model: you can get .inrupt.com for free or simply <anything.anything> for a price.

On the other hand, if you got tired of “wack-a-valkyrie.com” and wanted “wack-a-mole.com” instead, you would still be stuck.

@Happybeing, reading some of your comments make me believe that SAFE, which I do not know anything of, has an answer to this?


#8

Some technical ideas for migration here

and for POD encryption here so that host provider doesn’t read your data


#9

It does indeed, which is why I’m an advocate for Solid on SAFE. By eliminating servers, creating a decentralised DNS, one login for everything, end to end encryption, the weak points of Solid can be dealt with, and the strengths brought to SAFE. The two projects could have been made for each other.


#10

Good questions. I do think its important for people to be able to easily move their Pods around, between providers, regions if they trave/move, etc. Even if they want to download onto a local hard drive or USB drive, be offline for a while, then come back. Solid drives should be easy to move like that.

The moving/linking could be accomplished a few ways:

  • SAFE / Holo / IPFS - Distributed hosting is an ideal option, for sure.

  • Alternate domain system and DNS, I am all for, and in the exploring stage for my main business - a traditional domain / hosting company. This way everybody could have a permanent domain, forever - no expiry or silly annual fees - and the files are relative to that, perhaps would need to have some sort of ipv4/6 A/AAAA record following it around. But it’s really going to be years until this approaches mainstream.

  • After a move or porting to a new server, the old server can leave a new relative link, like a 301 page, that rewrites/redirects. Maybe some sort of link updating functionality/service in here.


#11

Hi,

  1. Encryption is critical, not just TLS. Just as it would’ve been nice if https (with improvements) had been adopted from the start, it will be important here. Likewise, it should be done at the protocol level because when each project/app/whatever tries to do it themselves, there will be mistakes - roll your own crypto is always a bad idea. People won’t store medical information if they have to rely on the host to protect their data (and backups of their data), and they would be dumb to do so.
  2. Distributed DNS is important too, even better, do encrypted DNS to help protect against man-in-the-middle, eavesdropping etc. Something like Namecoin / .bit would help to keep the centralization out of it. (Not necessarily .bit, but leveraging the code and merged mining with bitcoin since that helps to provide security for the namecoin blockchain).
  3. Ensure that DNS uses DNSSEC or something like it.
  4. Distributed PODs are critical too. If inrupt were to get a takedown notice and go offline immediately or the server were to somehow be destroyed, everyone’s PODs located on that server shouldn’t be lost. Yes, people should backup, but they don’t or they don’t often enough.
  5. Using something similar to twister’s mining/blockchain/DHT so that one could register an identity without it being tied to a specific provider is important too.
  6. Encryption is also important so that providers aren’t forced to censor based on content of PODs.