Maxi
I've been thinking about this problem as well. Another approach is for one
or more Diaspora users/sites to create well known Search Bots that users
voluntarily choose to submit their information to - Their name, high
school, email address, hobbies, interests, or which ever combination of
personal information they're willing to share with that search bot.
When users initially 'friend' the search bot, they establish their personal
information, perform searches based on information others have already
submitted, and sign up for periodic or opportunistic searches.
On the plus side, the design of Diaspora wouldn't have to change much to
accommodate this kind of model - the network API would have to define each
of the types of messages passed to and from search bots, but they would
still be end-to-end types of messages. Another advantage is that if a user
decides that she no longer trusts a search bot with her personal
information, she can choose another one.
The down sides are pretty obvious. Searches on the Diaspora network would
be a little split brained, since there wouldn't be one authority for
user search data.
--
Dan White
I don't think it's within Diaspora's capabilities to prove that any given
Diaspora ID matches up with a person.
>With PGP you would always only trust a key if you have other ways to
>contact the person and make sure it is his key, but without asking for
>a mobile number, email or something like that how could you ever be
>sure that the person you found in that diaspora directory is the one
>you met in reality ?
I agree. It's best to have a key signing party with individuals you wish to
have a strong online trust with, but users will still want to search for
that friend they knew in high school, who may have gotten married and
changed their last last.
On Facebook, I'm willing to accept that if I search for and send a friend
request to someone I haven't seen in 10 years, that person might not really
be who I think they are. I can usually develop *some* level of trust after
a few postings, seeing who our mutual friends are, and after seeing their
pictures.
>According submitting information to search bots... i thought diaspora
>is about keeping control over your information... if you commit
>information to bots/synced directories you even have less controll
>about your information then you currently have at facebook.
Well, you only submit what you want to give to a search bot. You only
control information as long as you don't give it out (regardless of whether
it's a search bot or a friend). If you only want to provide a name
association with your Diaspora ID, that works.
>How would you update the directory if you move your page? How would
>you make sure nobody else can update the entry? What could someone do
>against imposters in those directories ?
When you establish a friendship with the search bot, your search bot has
your public key, which prevents anyone else from updating your information.
If you move to a new server (however that would happen), you can still use
your private key to update your information.
The key is to make sure that someone else cannot impersonate your Diaspora
ID. I think that's about the only assurance you could have with a search
bot. Anyone else, of course, could claim to be you and post your pictures
in their own profile, under the guise of another Diaspora ID.
I don't know how Diaspora could provide any kind of assurance that Dan
White, of 1234 East Johnson Street, is dwh...@olp.net, without using some
3rd party trust, such as having a government entity tying your Diaspora ID
to something like a Driver's License database.
--
Dan White
Maxi
Maxi
My understanding of your original proposal was to have a group of pgp key
servers that synchronized with each other and could be used by end users to
retrieve keys by name, pod url, or webfinger address.
I think a problem to consider is how to define what invalid keys are and
prevent them from entering one of the pgp key servers and getting
propagated. For example, how would you prevent someone from introducing an
invalid or nefarious (full name, pod url) key?
My approach also suffers from this problem, which is why I think it's best
to more tightly integrate it into diaspora so that it can use some
pod-to-pod authentication/authorization or end-to-end semantics (whatever
they may be) to prevent invalid keys from being seen.
>> On the plus side, the design of Diaspora wouldn't have to change much to
>> accommodate this kind of model - the network API would have to define
>> each of the types of messages passed to and from search bots, but they
>> would still be end-to-end types of messages. Another advantage is that
>> if a user decides that she no longer trusts a search bot with her
>> personal information, she can choose another one.
>
>I do not think that any search bot should be able to access personal
>information. Every information a search engine gets has to be considered
>as public. I don't know the diaspora source well enough to know whether
>it would be simple to extend the friending mechanism in a way that the
>friend only gets the full name and perhaps (this should be configurable)
>the hometown, but nothing else. And I think the diaspora interface
>should provide separate interfaces for submitting information to a user
>directory and for friending users, otherwise someone searching for this
>functionality will never guess right how to do it.
After considering it some more, I think the idea of friending a search bot
should just be the same function of two identities friending each other,
and giving the ability of a new friend to share your information with his
or her friends, restricted in some way by the information you shared with
that new friend, and by information you're authorizing them to share with
their other friends.
A search bot could just be an approximation of diaspora user who's got a
huge friend list.
That way you don't have to have a user directory. You can use your Aspects
(say, Jefferson Highschool, Justin Beiber Fan Club, Underwater Basket
Weaving, and Gothom City Computer Club) to find others with those
interests. Maybe your Jefferson Highscool aspect has a couple of friends
who are really popular and introduce you to new classmates, or maybe
Jefferson Highschool decides to create a seed itself that all classmates
friend, and use to search for other classmates.
Diaspora would have to create some capability to share friends lists with
other friends, and in a secure way.
On 24/10/10�18:00�+0200, Anders Feder wrote:
>In the spirit of doing one thing and doing it well, I would much prefer if
>this functionality was external to Diaspora itself. Pods would be free to
>link in various ways to directories, of course, but the directories ought to
>exist on separate web servers and not rely on significant integration with
>the main Diaspora distribution code base.
If it's external, then it becomes more difficult (but probably not
impossible) to validate the information in a directory.
It becomes a bit easier if you allow a pod for a domain, such as
example.net, to be authoritative in some way for the public keys for all
users in its pod/domain.
>Maybe Diaspora could have an API for exporting a list of the users hosted on
>the pod. The owner of the pod (or someone else) could then submit the
>address of the pod to an directory, and the directory would take care of
>importing the list of users on the pod via the API. It would then be up to
>the directory to make this information available in the most useful fashion
>- perhaps it would upload it to an even bigger "upstream" directory, perhaps
>it would combine the information with user lists from Facebook and other
>social networks, perhaps it would publish the information on a P2P network,
>etc. This should not be up to us to dictate.
>
>If this is basically what you had in mind, consider this my "+1"
With a per-aspect approach, you'd have the ability to provide more fine
grained information, or perhaps even conflicting information to persons who
are attempting to search for you via a classmate as opposed to a
professional contact.
For instance, you might tell Jefferson Highschool Class of 2000 that you're
divorced, with interests in computers, hiking and reading. You might
neglect to tell professional contacts what your marriage status is, and that
your interests are Open Source, Linux, and that you're looking for a job.
--
Dan White
Privacy-aware doesn't mean we can't talk with strangers, or make
public information about ourselves in a form that helps others find
us. Just that the UI and engineering story is put together in a way
that leaves users in control, gives them sufficient understanding of
the risks and benefits, and treats users primarily as humans rather
than as inventory in an advertising network.
The Web is a wonderful thing in large part because it allows strangers
to meet, collaborate, share, connect and all that good stuff. Helping
users avoid accidental over-sharing, rather than pushing them towards
it, is the harder-than-it-looks problem here. Especially when those
users are teens or early 20s who feel immortal, have never had to
worry, have never done anything seriously wrong or made serious
enemies.
cheers,
Dan
Privacy, in my opinion, means that you can send a private message to any
given Diaspora user id with the expectation of privacy... that is, that
your (sha...@dev.null) communication with a given user (dwh...@domain.com)
will not be intercepted by another party or other diaspora
user/administrator.
>I know it's been pointed out that after chatting with someone for a
>while you can get a feeling if the person is the one you remember, but
>that's an out-of-band thing. I'm not saying it doesn't work -- I done
>it myself -- just that you can do it in Facebook, and Diaspora is
>supposed to be more "privacy aware" than Facebook...
>
>One approach, I guess, is to say that Diaspora should facilitate
>authentication between individuals if they want it, but shouldn't
>insist on it.
If the system can't guarantee privacy between any two given diaspora users
(who perhaps have never met each other), then diaspora probably becomes
something unfriendly on a large scale (like email with GPG), because you
can't really boot strap the system in a secure way without some other way
for two users to establish trust.
I think there's value in reputation in a social network... that is, friends
of my friends have some level of trust value with me. The more friends we
have in common (or the more friends we have in common that matter), the
more value I may choose to place in their claimed identity.
--
Dan White
Maxi
I would propose that public keys of any given diaspora user are retrieved
from that user's pod, and that pods are judged to be authoritative for any
public keys of it's users. E.g. the pod for example.net would be trusted to
provide a valid public key for user jsm...@example.net.
When rsm...@domain.com wants to send an invite to jsm...@example.net, it
(or it's pod) would ask the pod of example.net for jsm...@example.net's
public key. It could sign a trust on that key (to prove it's own
identity) and send a friend request to jsm...@example.net.
The pod for example.net, after receiving the friend request, would retrieve
rsm...@domain.com's public key and verify that the friend request really
was sent from him, then present the friend request to it's own
jsm...@example.net. If jsm...@example.net approves, then he signs a trust
on rsm...@domain.com's key.
Both rsm...@domain.com and jsm...@example.net could then announce (if they
wish to) their friendship to their other friends by transmitting both
trust signs to prove it.
If either of them wishes to unfriend the other, they'd issue a trust revoke
on the other's key, and distribute to those it wants to know.
>> After considering it some more, I think the idea of friending a search
>> bot should just be the same function of two identities friending each
>> other, and giving the ability of a new friend to share your information
>> with his or her friends, restricted in some way by the information you
>> shared with that new friend, and by information you're authorizing them
>> to share with their other friends.
>>
>> A search bot could just be an approximation of diaspora user who's got a
>> huge friend list.
>>
>> That way you don't have to have a user directory. You can use your
>> Aspects (say, Jefferson Highschool, Justin Beiber Fan Club, Underwater
>> Basket Weaving, and Gothom City Computer Club) to find others with those
>> interests. Maybe your Jefferson Highscool aspect has a couple of friends
>> who are really popular and introduce you to new classmates, or maybe
>> Jefferson Highschool decides to create a seed itself that all classmates
>> friend, and use to search for other classmates.
>>
>> Diaspora would have to create some capability to share friends lists
>> with other friends, and in a secure way.
>
>But this approach does not solve the "met in the train" problem. It has
>some other advantages, for example it can be used to implement a "friend
>suggest" function, and I don't object that something like this should be
>integrated in diaspora. My approach is more like a traditional telephone
>book, that has a right to exist on its own since it solves a slightly
>different problem.
I think it solves the same problem, but in a slightly different way :)
With my solution, those two train passengers just exchange diaspora ids,
which would be just like exchanging email addresses today. As long as
diaspora can provide an expectation of privacy between any two diaspora
users, then that works. Those two passengers have just completely a key
signing party, of sorts.
>> If it's external, then it becomes more difficult (but probably not
>> impossible) to validate the information in a directory.
>>
>> It becomes a bit easier if you allow a pod for a domain, such as
>> example.net, to be authoritative in some way for the public keys for all
>> users in its pod/domain.
>
>I think for my approach, it is more simple to make it external, since
>the sks server is written in ocaml and I will use parts of it, and
>because I think validation would not become simpler even if I would
>integrate it into diaspora.
>
>I do however not see either how integrating will make validation simpler
>for your approach.
My proposal would be to make all key exchanges based on GPG (OpenPGP)
protocols.
--
Dan White