It’s your data, but what about the URLs? #myData #myURLs
Owning your own data is great, owning your own URLs also is even better. Let's start asking web app developers for this feature.
Gone is the initial love affair I had with the web. Those early days when I believed that Google actually could do no evil and when the web was an open frontier of boundless potential built by those who naively and bravely toiled to further the plight of humanity are in the past.
The It’s your data, but what about the URLs? #myData #myURLs article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Replaced, are they, by the grey (OK, pastel) reality of commercial silos that grant users varying degrees of access to their own data while trying to gleam as much information about them as they can to sell to their advertisers and other interested third parties. And what freedoms remain are under grave threat from legislation like SOPA and PROTECT IP.
How's that for overly-dramatic?
Yes, that was overly-dramatic!
Of course, it's not all doom and gloom.
There is a thriving web standards community actively building, evolving, and furthering the open web, and bodies like the EFF who are campaigning to keep the web open. People–at least in the geekier circles–are becoming more aware of the importance of owning their own data. And, in all fairness, many web services now allow users to backup or export their data.
But what about the URLs used for public pieces of user data?
Who owns those?
Who owns your URLs?
The norm today is that URLs belong to the web service provider.
Case in point: I'm closing my Flickr account in response to Yahoo! hiring PayPal's president as CEO and that means that the URLs for all my photos and sets will now go dead. Anyone who has linked to a photo will now get a broken link. In short, this will break (a teeny, tiny, probably imperceptible) part of the Internet. Regardless of its impact, however, breaking links breaks the Internet.
So what can we do about it?
#myData #myURL
Just like we are beginning to understand the value of owning our own data, we need to understand the value of owning our own URLs.
And by this, I don't mean that we should all host all of our own data. We don't all want to run a mini Flickr, a mini YouTube, etc. We don't all have the technical expertise or the financial means to do so. It's just not practical.
It does mean, however, that I should be able to use my own URLs with third-party services. So, if I have a domain name (e.g., aralbalkan.com), I should be able to tell Flickr to use, say, photos.aralbalkan.com as the root of all URLs to my images and sets. In other words, I should be able to tell web services to use my own URLs as the canonical URLs to represent my own data.
If Flickr had allowed this, for example, I could have uploaded the photos I exported from it either to photos.aralbalkan.com under the same URL scheme or to somewhere else completely different (and used redirects, etc.) without breaking the Internet.
Owning your own data is great, owning your own URLs also is even better.
Let's start demanding that web application developers implement this feature.
The It’s your data, but what about the URLs? #myData #myURLs article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
That. would. be. wonderful.
Good idea and needs to be done, companies may get a bit funny however about their own users being able to have their own data elsewhere…
Really fantastic idea!
What about implementing / using an URL-dispatcher similar like we use shorteners today instead of trying to force others to use our service?
This way at least URLs posted by oneself would stay intact.
The redirects thing would work, obviously, but I wonder what percentage of the web’s users would be able to set that up. Or, from the business perspective, what percentage of paying customers would be able to set that up and would consider it a compelling feature of the service.
I think my main concern, however, is around security. At the basic level, SSL certificates wouldn’t work as they are commonly used. I would not only not be able to use one of the certificates that identified by business (as GitHub do, for example) but I would not even be able to use the most basic wildcard certificate.
Putting that aside for a moment, there are even bigger problems. Let’s say that Flickr implemented this, and when I saw your photo on the Interestingness page, and I clicked through, the domain changed. It’s reasonable to assume that users would get used to this behaviour. Presumably, if I clicked on any of the navigation elements in the header I would end up on the main Flickr domain. Not a problem so far. However, what is to stop you from creating a site local to your domain that looks a lot like Flickr, but which actually performs a man-in-the-middle attack on me when it tricks me in to signing in? Obviously, you’d have to get me on to your site first, but that wouldn’t be a hard. A simple comment with a link through to your site should do. As a user, I would have been conditioned not to think too hard about the fact that the domain had changed.
Any thoughts about how these problems could be addressed? It works for silos like WordPress or Tumblr, so maybe there are some lessons to be learnt there. But sites like Flickr, Twitter, or Facebook are a lot more interlinked, a lot more complex.
I find that a good way to deal with this is to build a sort of wrapper on your own domain. We do this with YouTube clips on one of our sites: http://www.klasse.be/tvklasse/20059-Man-voor-de-klas
We used to have JW Player as our video player, until we realised that YouTube actually generates quite a lot of organic views for our content, and that maintaining our own player was too much hassle for what it’s worth.
If YouTube decides to go evil on us, we can fairly easily switch to a different video service or player and maintain our urls. We will lose the direct YT traffic, but that would also happen in your Flickr example (presumably your photos would also still have a flickr.com url).
On our childrens’ site, we even use the YT ids as post/page ids: http://www.yeti.be/yetitv/RSoutjyaihE
Good point! I was thinking about this like two days ago.
And maybe the “solution” lies in the link shorteners. Or at least, that could be a solution. Having a “main domain” that “serves” all the links by redirecting or proxying through them might be a solution to our problem.
It occurred to me frequently to have 404, or to have “The page has been moved to…” in that case, if no one informs the owner of the page the link will soon break, and we won’t have any chance to recover it, even if it DOES still exist.
Another thing that might solve the problem might be a “scanning” of links that are changing (in the internet), but this would require a LOOOOT of work and would solve just a SMALL part of the problem.
I hope one day we’ll have a solution for this ;) (and as a Developer and a UX Designer, I would hope for that ;) )
Anyway, good post!
You could use the Handle System (handle.net) to establish persistent identifiers/links to your things. You’d need some additional tools to automatically generate the permanent links/URLs and tag your data with them.
That is a smashing Idea. Good one. how to implement it though?
This is one of the things I like most about BitBucket, a competitor to GitHub. You can point a subdomain at it. So I pointed code.tommorris.org to it. If they turn evil, I can repoint it elsewhere.
Flickr turning evil? I’m so glad I store my photos in a popular free online encyclopedia instead. ;-)