Proposing a centralized fallback for Webfinger.

[Michiel de Jong]

Some people have their own domain name. For them, we provide things like our WordPress plugin and our ownCloud app. But many people rely on one of the big three email providers (Hotmail, Yahoo, Gmail) for their user address. There is also a possibility that people's Facebook profiles, rather than their smtp addresses, will become their main user address in a near future.

We could encourage people to get an additional user address; one they use specifically for their remote storage. But that's not very user friendly. So given that we already defined the open way to link remote storage to your user address (namely, via webfinger), we can, without loss of openness (and that's the big discussion point, obviously), define a fallback option. This is an approach that BrowserId already uses with browserid.org, and that has its friends and its enemies, but that may make sense for our situation, too.

I propose a centralized registry where people can announce their remoteStorage whenever their user address doesn't have a webfinger file, or when their webfinger file is not user-editable. To edit your records at useraddress.net, simply log in with BrowserId, and link to a URL where you host your own lrdd or jrd file. All useraddress.net stores are these links. We would then recommend to application that they support useraddress.net as a fallback whenever webfinger fails, but never as a replacement for webfinger. That way, openness of the protocol stack is still guaranteed, and the only centralized registries we actually /rely/ on, will still only be DNS and TLS.

So the application will always try to check your webfinger first, but fall back to useraddress.net whenever webfinger fails.

yes, it's a centralized registry, and if it gets hacked then you get a big phishing risk, so it's not something we want to do just for the fun of it. But from the user's point of view, it might be the only option that would work well (at least i don't see any others right now; alternatives, anyone?).

one alternative would be to simply not support 99% of people's existing user addresses. but that's probably the easiest route to letting our entire project fail to ever achieve critical mass. I remember the words of Ade at fsw-2011 "be linux, not herd" - as in, don't let design perfectionism become the enemy of actually building something.

i would say it could easily take 5 years before everybody has their own user-editable webfinger file. So we can try out the useraddress.net fallback as a temporary measure, keep campaiging for webfinger adoption, and plan like a 5-year deprecation track.

but postponing our revolution until after webfinger files are user-editable is not a viable option, i think.

Opinions, anyone?


cheers!
Michiel

[Ben Adida]

Michiel,

This is something Mozilla's been thinking about doing: providing a
centralized bootstrap for profile registry. WebFinger is obviously high
on the list, although I would prefer to keep it as the protocol for
truly public info, wherever possible (given its otherwise unattractive
privacy properties.)

This may be a good simple place of first collaboration?

-Ben

On 1/2/12 8:32 PM, Michiel de Jong wrote:
> Some people have their own domain name. For them, we provide things like
> our WordPress plugin and our ownCloud app. But many people rely on one
> of the big three email providers (Hotmail, Yahoo, Gmail) for their user
> address. There is also a possibility that people's Facebook profiles,
> rather than their smtp addresses, will become their main user address in
> a near future.
>
> We could encourage people to get an additional user address; one they
> use specifically for their remote storage. But that's not very user
> friendly. So given that we already defined the open way to link remote
> storage to your user address (namely, via webfinger), we can, without
> loss of openness (and that's the big discussion point, obviously),
> define a fallback option. This is an approach that BrowserId already

> uses with browserid.org <http://browserid.org>, and that has its friends

> and its enemies, but that may make sense for our situation, too.
>
> I propose a centralized registry where people can announce their
> remoteStorage whenever their user address doesn't have a webfinger file,
> or when their webfinger file is not user-editable. To edit your records

> at useraddress.net <http://useraddress.net>, simply log in with

> BrowserId, and link to a URL where you host your own lrdd or jrd file.

> All useraddress.net <http://useraddress.net> stores are these links. We

> would then recommend to application that they support useraddress.net

> <http://useraddress.net> as a fallback whenever webfinger fails, but

> never as a replacement for webfinger. That way, openness of the protocol
> stack is still guaranteed, and the only centralized registries we
> actually /rely/ on, will still only be DNS and TLS.
>
> So the application will always try to check your webfinger first, but

> fall back to useraddress.net <http://useraddress.net> whenever webfinger

> fails.
>
> yes, it's a centralized registry, and if it gets hacked then you get a
> big phishing risk, so it's not something we want to do just for the fun
> of it. But from the user's point of view, it might be the only option
> that would work well (at least i don't see any others right now;
> alternatives, anyone?).
>
> one alternative would be to simply not support 99% of people's existing
> user addresses. but that's probably the easiest route to letting our
> entire project fail to ever achieve critical mass. I remember the words
> of Ade at fsw-2011 "be linux, not herd" - as in, don't let design
> perfectionism become the enemy of actually building something.
>
> i would say it could easily take 5 years before everybody has their own
> user-editable webfinger file. So we can try out the useraddress.net

> <http://useraddress.net> fallback as a temporary measure, keep

[elf Pavlik]

Excerpts from Michiel de Jong's message of 2012-01-03 04:32:08 +0000:

> useraddress.netfallback as a temporary measure, keep campaiging for

> webfinger adoption,
> and plan like a 5-year deprecation track.
>
> but postponing our revolution until after webfinger files are user-editable
> is not a viable option, i think.
>
> Opinions, anyone?

if it will depend on browserid teaming up with browserid.org folks might make sense...
still i hope you will put emphasis on clearly recommending indy way with self hosted webfinger =)

~ elf pavlik~
--
(living strictly moneyless already for over 2 years)
http://wwelves.org/perpetual-tripper
http://moneyless.info
http://hackers4peace.net

[Michiel de Jong]

Hi Ben,

On Tue, Jan 3, 2012 at 9:41 PM, Ben Adida <b...@adida.net> wrote:

Michiel,

This is something Mozilla's been thinking about doing: providing a centralized bootstrap for profile registry. WebFinger is obviously high on the list, although I would prefer to keep it as the protocol for truly public info, wherever possible (given its otherwise unattractive privacy properties.)

This may be a good simple place of first collaboration?

-Ben

Absolutely! Great. I started by writing down my own thoughts on the topic, here:

https://github.com/unhosted/website/wiki/webfinger-fallback

I agree with you that webfinger should not be used for restricted data, and therefore does not solve the whole "online profile" case. I think we can distinguish five kinds of data discovery schemes:
- hyperlinked data
- content-addressable data
- public per-user,
- restricted per-user,
- private per-user.

The web in itself is only good at the first kind of data discovery. Portals and search engines solved the second scheme. Webfinger is useful for adding the third kind. Right now we don't have this on the web (except for users who are lucky enough to be on a webfinger-enabled domain). In general, we have to rely on a combination of the first two schemes if we want to discover public per-user data.

I agree with you that Webfinger could be more versatile if it also solved the fourth scheme, or even the fifth one. I think this is why open web discovery (owd) is getting some traction in some corners of the web (mainly microsoft and enterprise intranet folk, i heard), as a competitor to webfinger. Obviously, competing standards are by definition undesirable, the owd people should have proposed an extension of some kind to webfinger.

Now that i think about it, i do agree with you that we should give people a way to put public, as well as restricted, as well as private data in machine-discoverable locations. But since resource discovery is transitive i think the best way to do this is to respect the webfinger standard as-is, and put a link in the webfinger record which points to the restricted "only for friends" profile(s) as well as to the location of the user's private data.

Note that publishing such a record does not give away any information about whether the user address even exists. A domain may simply respond with the same templated lrdd file for any user address you throw at it. And then only if you provide credentials, you would get access to the restricted and/or private per-user data.

Would such a setup be an option from Mozilla's point of view?


Cheers, this is exciting! :)
Michiel

[Michiel de Jong]

Hi Pavlik,

On Tue, Jan 3, 2012 at 11:15 PM, elf Pavlik <perpetua...@wwelves.org> wrote:

> Opinions, anyone?

if it will depend on browserid teaming up with browserid.org folks might make sense...
still i hope you will put emphasis on clearly recommending indy way with self hosted webfinger =)

yes, of course, that should be a very clear basis of this whole endeavour. See also the 'without loss of openness' paragraph in https://github.com/unhosted/website/wiki/webfinger-fallback

[Forbes Lindesay]

Has there been any progress in this?  I'd love to start supporting remote-data within my applications, but it would need to be mind bogglingly simple to set up for users and at the moment, it doesn't work at all unless you give people a separate remote-data e-mail (which is a non-starter).

I'd be happy to collaborate in the effort to produce a fall-back site if we're going ahead with it?

[Michiel de Jong]

hi!

we asked Blaine Cook for advice, and he said it would be "a terrible
mistake". So we came up with something else.

Now, the remoteStorage.js will always first check webfinger, and then
if there is none, it will fall back to a built-in list of defaults. By
distributing this list as part of a free software tool
(remoteStorage.js) instead of hosting it a service, we decentralize
power in a better way.

At the same time, it means that it will only be usable for a limited
number of domains. For instance, we wanted to link Google Drive
accounts to their corresponding gmail addresses. That's of course,
only as a stopgap, until Google itself starts to support "personal
data services" discovery in the way(s) that are currently being
discussed on mailing lists like appsawg, oauth, and webfinger.

At the same time, I think a focus on early end-users in the academic
world will solve a big part of the problem.

I was talking to people at UX Camp and we discussed the option to only
focus on end-users who receive remoteStorage from their existing email
provider (i.e., either their university, or their employer, or their
personal Indie Web domain).

So that would move focus away from our current 3 main providers (Iris
Couch, OwnCube, 5apps), and more towards students in the Netherlands
and other European and overseas countries to come as they are added
over the next year.

The argument is mainly that we need app developers and these apps need
end users. The app developers can use PageKite or 5apps or OwnCube.
People who are already on OwnCube, ownCloud, Diaspora, or Locker
project will also be happy to use those existing accounts as
remoteStorage. But we're not thinking of those people now. We're
thinking of the end-user market for apps. "All European students" is
easily a large enough target group to develop specific apps for. So by
hard-coding the domain names of these universities into the app, we
can make it work without needing Webfinger.

So for Dutch universities who don't have webfinger, we point them to
surfnet (NL). And over the next 12 months we hopefully will do the
same with 4 or 5 other European countries. Then we are working with
Terena TF-Storage for the European-level fallback (20 or so countries
who don't have their own server). I think Melvin suggested at some
point that maybe data.fm could become a remoteStorage server for
csail, or maybe even all of MIT, which would be a great foothold to
have across the pond, obviously.

So we improve end-user usability by selectively picking our (first)
end-users. :D We'll not be relying on the freemium provider setup
anymore for broad end-user bases. While still obviously supporting it
for developers, power users, and whoever wants to.

Does that make sense?

Cheers,
Michiel

[Melvin Carvalho]

Pros and cons to discovery.

With webfinger as it is today, the control lies with the data monopolies, but you get massive adoption.

With fallback, you get user freedom, but introduce centralization.
 
With a registry lookup you get tight coupling of the user identifier and the data storage, but it saves a round trip.  But under open source you always have freedom to change the entries.

It's possible also to have a combination of these three.  I think what's important is that some people wont know about data freedom, some wont care, but some will demand it.  For those that care there should in the long term be the option for them to store their data wherever they want, whether that be on the gdrive, dropbox, desktop pc or even smartphone.  

Cheers,
Michiel

[Michiel de Jong]

On Tue, May 29, 2012 at 2:56 PM, Melvin Carvalho
<melvinc...@gmail.com> wrote:
> Pros and cons to discovery.
>
> With webfinger as it is today, the control lies with the data monopolies,

I'm not so worried about that, you are the only person i know who
feels this way about webfinger. i think (from previous discussions)
that what you're saying is that the webfinger spec would be more
trustworthy if it were at the w3c, because of copyright issues like
the ones that are reportedly linked to ActivityStreams. if any of the
commercial stakeholders in webfinger and in the web in general would
get bought by Oracle and start trying to claim copyright on the spec,
then we would just rename it LibreFinger and continue business as
usual. Treat copyright as damage, and route around it. :)

> but you get massive adoption.

That's not necessarily true. Google and Yahoo offer webfinger
services, but they don't announce any remoteStorage (yet).

> With fallback, you get user freedom,

freedom of the user from the laziness of their systems administrator, yes.

> but introduce centralization.

Indeed, a fallback service would be bad, and as far as i'm concerned,
it's off the table.

>
> With a registry lookup you get tight coupling of the user identifier and the
> data storage, but it saves a round trip.  But under open source you always
> have freedom to change the entries.

yes, that's what is currently implemented, since v0.5.3 of
remoteStorage.js
https://github.com/unhosted/remoteStorage.js/blob/master/CHANGELOG.txt

> It's possible also to have a combination of these three.  I think what's

i'm now against using a fallback service (even though i previously
proposed it as an option)

> important is that some people wont know about data freedom, some wont care,
> but some will demand it.  For those that care there should in the long term
> be the option for them to store their data wherever they want, whether that
> be on the gdrive, dropbox, desktop pc or even smartphone.

well, if you are a dropbox user, and you care about being able to use
dropbox as remoteStorage, then i agree, but all we can offer is a
proxy to it. if you want proper dropbox support, you'll have to put in
a feature request with their user support department. Same for GDrive.

For desktop pc there's PageKite. For smartphone and plug server you
would probably also want to use PageKite or similar in the end.

if you care about data freedom and are on the Indie Web, then you
should use ownCloud or similar.


Cheers!
Michiel

[Melvin Carvalho]

On 29 May 2012 15:18, Michiel de Jong <mic...@unhosted.org> wrote:

On Tue, May 29, 2012 at 2:56 PM, Melvin Carvalho
<melvinc...@gmail.com> wrote:
> Pros and cons to discovery.
>
> With webfinger as it is today, the control lies with the data monopolies,

I'm not so worried about that, you are the only person i know who
feels this way about webfinger. i think (from previous discussions)
that what you're saying is that the webfinger spec would be more
trustworthy if it were at the w3c, because of copyright issues like
the ones that are reportedly linked to ActivityStreams. if any of the
commercial stakeholders in webfinger and in the web in general would
get bought by Oracle and start trying to claim copyright on the spec,
then we would just rename it LibreFinger and continue business as
usual. Treat copyright as damage, and route around it. :)

> but you get massive adoption.

That's not necessarily true. Google and Yahoo offer webfinger
services, but they don't announce any remoteStorage (yet).

I'm unsure that I actually said this, or the relation to activity streams in this context. 

The point I was trying to make is that most users are trained log in with there email address.  This is very often one of the big webmail providers.  And consequently the webfinger record will be under that control.  You have previously said to me that you dont ever expect services such as gmail to let you edit your record.

I'm not saying this is a bad thing, in fact in the apps I write you can login with gmail, yahoo, facebook, browserid, webid, or even as an anonymous user.  But bear in mind, that while you get many more users this way, the provider they use has an element of control over the record.  As I tried to point out there's pros and cons with the different choices. 

I wasnt necessarily trying to frame things in terms of "good" and "bad".
 

[Michiel de Jong]

On Tue, May 29, 2012 at 4:16 PM, Melvin Carvalho
<melvinc...@gmail.com> wrote:
> The point I was trying to make is that most users are trained log in with
> there email address.  This is very often one of the big webmail providers.
> And consequently the webfinger record will be under that control.

ah right. yes, if you want to avoid a small number of domains to play
a big role in identity space, then you have to force people to
register an Indie Web domain. I think the freedombox should come with
a domain name included in the price, and force people to register one.
unless you want to overhaul DNS.

Another topic that touches on that is migration. It should be easy to
migrate from one account to another, which (unless you own the domain
name) is not so easy once people start linking to you. We could define
a 'move notice' system where you can pro-actively tell your peers that
you're changing to another user address. But even then, people
probably know your user address by heart, which again leads to more
lock-in.

I think the way forward is to use gmail with your own domain, so you
use the product, but you don't use it as your identity provider.