Design: End-to-end encryption?
shadowfirebird
in them, and I'm having difficulty keeping my brain focused on it
all. The one thing I am sure of is that we don't have a consensus.
So I had the dumb idea that maybe we should try and summarise our
thoughts on one specific part of the design. Not the details;
something much higher level. If other people think this is a good
idea perhaps they could pick different aspects of the design.
-----
So, end-to-end encryption. By which I mean: the idea that the pods
only pass encrypted data and the only thing that encrypts or decrypts
is the web browser.
1) Do we want this? If not, why not?
2) If we do, do we want it bad enough to compromise on other parts of
the design? For example, if it turns out to be too difficult to do in
a browser, would we be willing to think about another client?
Obviously no-one is constrained to answer. This is just my dumb idea.
Jakob Keres
E2ee is more difficult (or less efficient) to attack than encrypted
connections between servers (which I see as alternative). In the latter
case a corrupt connection would effect more than one user. Furthermore,
even with a working encrypted server-to-server connection but without
the usage of signing it would be possible to send spam message to any
user. Otherwise the receiver had to check if a message comes from the
server the message is supposed to come from. But OTOH a user should be
allowed to change the server. This is possible to solve, but everything
would become more difficult. Therefore, at least signing is necessary.
To enable (or at least the possibility for) a client-server model -
where the user can have a real secured connection without maintaining a
own server on own hardware - e2ee is necessary.
I don't see any conceptual disadvantages of e2ee even if no
client-server model is used. If it turns out that it is too difficult
for the client to do the de/encryption, use it as diaspora is doing at
the moment.
Not to use e2ee would mean that the security control is completely given
to the server admins. With e2ee and via web of trust, fingerprints etc.
the possibility is given to the single user to check the security status.
Bjarni Rúnar Einarsson
It won't run in your web-browser. Your mom won't use it. Your friends won't use it. Diaspora's stated goal of providing a privacy friendly alternative to Facebook and other centralized social networks won't be met.
You are talking about building something else entirely, which may be justified and a worth building, but it's not Diaspora.
Bjarni R. Einarsson
Founder, CEO and janitor of the Beanstalks Project.
http://beanstalks-project.net/ ~ http://bre.klaki.net/
Raphael Sofaer
eveclatrel
To summarize from the other posts for me:
1) I personally want this, I believe it's the best approach for
security. I don't think that the average user will want to deal with
it, and will stick to a less secure web-browser interface that they
are used to.
2) I think that if we're going to do a client-side solution, we should
compromise and build out a core framework that can be cross ported
either instantly or quickly. That way platforms can design a UI that
leverages their strengths. Better end-user experience will increase
our popularity, and shouldn't drastically increase buil-times.
3) I don't believe we have to choose as implementors which encryption
method to follow, I think we should do both at the same time and let
the user choose ("Your Seed, Your Way"). That scenario can be reposted
in here if it's felt to be appropriate.
Bjarni Rúnar Einarsson
Here is how:
* Build a server that is as secure as possible, and communicates securely with the rest of the world, using open protocols.
* Those that want maximum privacy, install the server on their own hardware.
* When accessing their seed, they use a standard browser's SSL encryption - a self-signed cert is good enough, especially if people are using something like Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/6415/), which the paranoid should of course do.
This means those who want end-to-end encryption can have it using 100% standard infrastructure, either by hosting their own server, or getting someone they really trust to host it for them.
This is both more flexible, and easier than building a custom client.
Since the server has to be trusted anyway, I would personally recommend focusing on strong signatures and transport-layer-encryption. Storing encrypted messages on the servers (with the keys) is really just snake oil which only makes things more complex and more likely to fail.
On the other hand, the easier we make the self-hosting, the more people get to enjoy the "maximum security" option. So by making the software easier to use and set up, we are improving security. How's that for a win-win effort? But those that can't run their own aren't left out in the cold, they still get to enjoy the benefits of decentralization and competition, both of which are arguably more important than encryption anyway - very few of us are being spied on people who know how to sniff packets or hack servers.
That's my 2c anyway.
And I'm not just talking, I am actively working on making self-hosting as easy as possible. It's my day job. So I'm not impartial either. :-P
EagleG33k
cents.
I would love to see end-to-end encryption, however I realize (from
personal experience) that most people simply do not care enough to
deal with anything other than a password.
My immediate reaction is that a (Firefox, Opera, etc) plugin (or
something similar - again - I'm not a security expert) would be the
way to go to get around this. I know this has its own draw backs, but
I don't think it's too much to imagine an extra click or two would be
a pain for most users. Ideally it'd have a built-in way to transfer
the key from one device to another. Yes it'd be a weak spot security
wise (maybe use something similar to a one-time pad for each
transfer?), but it would at least require the user to make that
decision.
My second thought is that we should design for the case where the user
holds their own private key, but provide a graceful fall back solution
for anyone who chooses to opt-in, ie. via a check box on the
registration page where if and only if they ask, is their key stored
on the pod. Ultimately I think this will be the best balance between
being user friendly and secure. It stays true to the project's goal of
being "privacy aware" by providing the most secure option by default,
yet allows a graceful fall back to those who would rather put their
trust in the social side rather than the technological side of
things. That being said - if we do go down this route - I'll be doing
my best to convince my friends to take the extra step and hold their
own private key.
One crazy idea I'll throw out to the lions - if we go the second route
- what would you think of informing a user's friends of their decision
of where to host their key? On the one hand - if someone is lured into
friending a malicious user - this would tell them exactly where to
look to grab their private key. On the other - it would allow a non-
malicious user to potentially place that friend into a separate aspect
and take that choice into consideration when posting. I'd rely on a
friend holding their own private key to tell them I was leaving my
house filled with expensive things alone for a week, but I'd think
twice if it was possible their key could be more easily compromised.
Feel free to tear this idea to shreds - I'm not suggesting one way or
the other, but I'd like to hear what others think of it.
Alex Andrews
-1 for the idea you'll be able to tell this, for the very reasons you've already described.
Jakob Keres
this case you have an email server and a web based client and your
browser. If you prefer you also can use outlook, thunderbird whatever.
Anything is running in your browser if you have a web based client. Even
operating systems. The web client also could be on the same server, so
you never notice that there are two systems.
Jakob Keres
Furthermore it is not understandable why we should force people to use a web frontend. Think of what email would be without POP or IMAP. If someone wants a console client, he should be able to use a console client, those who want a web frontend should be able to use their browser. The world is heterogeneous, we should provide a solution for a heterogeneous world.
If we have an API, we have to secure the access and do authentication and we'll have the same discussion again.
The client-server model provides the highest flexibility and - in conjunction with e2ee - the best security. And in my opinion it also the easiest solution to understand, because we know the scenario from PGP very good.
I think most of us agree that an e2ee would be the best from an technical point of view, but we are worried about the users.
Ten year ago only specialist were using email. Nobody was interested in privacy. Five years ago many people were not using using https for internet shopping. The technical knowledge is growing rapidly and people get used to use private keys for online shopping. This year the german government introduces a new passport with cryptographic functions to enable secure internet transactions. As Raphael said, in the moment it is not practical for non-technical users, but in my opinion it is only a matter of time. Also email was ahead of its time. And the use of social networks just has started.
Furthermore, we already have a lot of more or less technical users that would like to see e2ee. We also should think of them.
For those, who are more non-technical or not so concerned about their privacy, the private key can be encrypted with the user password and stored on the server. This option gives the same security as without e2ee but is more convenient.
Those who don't like the separation of server and client install both on the same machine or use a hybrid implementation. Hotmail also uses a client-server solution, but nobody notices. I can't understand the fear of some guys "if we use client-server nobody will use".
I personally don't see a contradiction between best possible security and usability (if you give the user the option).
Bjarni Rúnar Einarsson
Current browsers cannot encrypt and decrypt message fragments, the only crypto built into them is at the transport layer, called TLS. This cannot be changed in a secure way with just a snippet of javascript or a browser plug-in.
So if you want individual messages encrypted and decrypted, and then displayed in context as part of a pretty web-based UI, then the server has to do the crypto work. This means the server has the keys. This means you are at the mercy of the server admins, which you explicitly said you wanted to avoid. Of course you are right that if you run the server yourself, on your own hardware, then you are the server admin and there are no trust issues. But you also said you wanted to avoid that requirement.
You can't have both, sorry!
The corollary of this is, that the average person who is unable or unwilling to install a Diaspora server on his own hardware (and just wants to point his web-browser at a new page) can not enjoy full end-to-end encryption and has to trust a server admin. Now, before you start talking about installing other clients, keep in mind that that is fundamentally the same thing - you are asking people to install new software. Not everyone will do so and requiring this will exclude people from the network. That is what I meant.
Now, making it optional and possible for those who want the added security is fine. And as I understand it, that's the current strategy. :-)
No, that's totally nonsense. Maybe you have heard about a webmail. In
this case you have an email server and a web based client and your
browser. If you prefer you also can use outlook, thunderbird whatever.
Anything is running in your browser if you have a web based client. Even
operating systems. The web client also could be on the same server, so
you never notice that there are two systems.
Bjarni Rúnar Einarsson
For those, who are more non-technical or not so concerned about their privacy, the private key can be encrypted with the user password and stored on the server. This option gives the same security as without e2ee but is more convenient.
No it doesn't. You are concerned about malicious server admins, and a malicious server admin will modify the system to store the passphrase and the key. They can make this attack at any time and have full access to all you past and future messages.
You might as well not encrypt at all.
Jakob Keres
Current browsers cannot encrypt and decrypt message fragments, the only crypto built into them is at the transport layer, called TLS.
So if you want individual messages encrypted and decrypted, and then displayed in context as part of a pretty web-based UI, then the server has to do the crypto work.
The corollary of this is, that the average person who is unable or unwilling to install a Diaspora server on his own hardware (and just wants to point his web-browser at a new page) can not enjoy full end-to-end encryption and has to trust a server admin.
On Sat, Sep 25, 2010 at 12:13 PM, Jakob Keres <jakob...@googlemail.com> wrote:For those, who are more non-technical or not so concerned about their privacy, the private key can be encrypted with the user password and stored on the server. This option gives the same security as without e2ee but is more convenient.
No it doesn't. You are concerned about malicious server admins, and a malicious server admin will modify the system to store the passphrase and the key. They can make this attack at any time and have full access to all you past and future messages.
Simon B.
private private key" is in the roadmap, but that what Raphael wrote
above sounds like it's not a top priority on his plate. Elsewhere in a
"GPG"somthing thread I've seen him encorage developers to figure out a
way to enable using GPG. Presumably this includes using public key
servers and in turn making e2ee possible for power users.
For now e2ee can be trivially implemented by a power user who runs
their own host with only their own seed on it.
I'm really inspired though about the idea for browser plugins that
could handle decryption & encryption, but I worry that it won't be
possible to use on a public/school/cafe computer or in a smartphone?
Also the users who value a actual e2ee and never type a password into
a public/school/friends computer and who always carry their own
internet machine with them, is simply not the primary target audience
for Diaspora*.
Also e2ee can't be the default option for the average Joe.
Why?
* Joe wants to be able to use their seed on *any* internet-connected
computer. Today people log into facebook from a friends computer, from
public computers (school, library) and internet cafes while on
vacation (all of which might have virus/spyware) and if Diaspora is
harder to use than that, it won't become anything more than a tech:ies
"wet crypto dream" (sorry).
* Joe does not want to have to type (and even less remember) lots of
passwords. One simple password ("ferrari84") will be all that most can
accept. Most users even keep the same (few) password(s) for all web
services, and those kids (and politicians!) are getting their hotmails
etc hacked and leaked.
So those of you who really care about security should sponsor some
developer to build OTP login support into Diaspora. Or some of the
other non-connected security solutions that internet banks are using.
On Sep 25, 4:42 am, Alex Andrews <awgandr...@gmail.com> wrote:
> +1 for the idea that users can easily keep their keys if they want to. I can imagine this would become adopted by power users but Joe user wouldn't care, after all they are primarily after Lord Zuckerberg not spying on them.
>
> -1 for the idea you'll be able to tell this, for the very reasons you've already described.
@Eagle:
> > holds their own private key, but provide a graceful fall back solution
> > for anyone who chooses to opt-in,
key than on the seed host. In 99% of cases the seed host must be
trusted. If one host becomes too big (facebook anew) then there will
be a natural migration off users towards smaller more local or
otherwise more trustable hosts, as well as new efforts into making it
easy and cheap to run your own seed host. So I see no need to design
for "worst case hosting", but rather trust the users to figure things
out for themselves. It's a social network darn it - people are going
to talk about how to use the network safely as well as sharing lolcats.
Simon B.
> Furthermore it is not understandable why we should force people to use a web frontend. Think of what email would be without POP or IMAP. If someone wants a console client, he should be able to use a console client, those who want a web frontend should be able to use their browser. The world is heterogeneous, we should provide a solution for a heterogeneous world.
other hand, it won't be built however much you propagate for it in
here :). You really need to recruit interested developers that want
to / get paid to build native clients. Which platforms do you want to
have clients for?
Diaspora is built on Rails and mongodb, both of which typically
include a RESTful API from the beginning.
> If we have an API, we have to secure the access and do authentication and we'll have the same discussion again.
the core developers. It might require one or some few weeks effort if
it turns out that a new "bindings" ruby-gem must be created.
(Or you could extract or ask help to get an earlier version of the
source code that was using GPG (and so being "e2ee" I presume) and use
that between your private single-seed host and your friends that runs
the same, if you're in a hurry.)
To get the API available to experiment with, it might be that all you
need is to add authentication before the "alpha API" is available.
Check the roadmap and you'll see that an API is being promised, and
was promised already before they started asking money.
Bjarni Rúnar Einarsson
I'm afraid you're still wrong or I didn't get your point :)
The corollary of this is, that the average person who is unable or unwilling to install a Diaspora server on his own hardware (and just wants to point his web-browser at a new page) can not enjoy full end-to-end encryption and has to trust a server admin.
That't true. I never doubted that.But those, who _are_ willing to use a dedicated app or those who are able to maintain a secure web-client in a local network (that is not reachable from outside and less vulnerable to attacks), but are not able to secure a internet-server, can profit from e2ee.It doesn't give better security to everybody, but to those who want it!
OK, sure. This is an incredibly complicated way to achieve this though.
If you just made it a requirement that people who are this concerned about their privacy host their pods and seeds themselves, then you can pretty much forget about most of the encryption stuff and end up with a much simpler and more robust design.
To use the language of the Diaspora security document, all the users (who will be the majority) using the Web Client gain zero security by this e2ee stuff, but the crypto slows everything down and introduces all sorts of new failure modes. A single bit-flip in your key means all your data is gone, forever. That thought bothers me *much* more than the thought of someone snooping a bit.
For those, who are more non-technical or not so concerned about their privacy, the private key can be encrypted with the user password and stored on the server. This option gives the same security as without e2ee but is more convenient.
No it doesn't. You are concerned about malicious server admins, and a malicious server admin will modify the system to store the passphrase and the key. They can make this attack at any time and have full access to all you past and future messages.Why should this be better without e2ee?
Because of complexity and failure modes. Other things being equal, simpler systems are better. The crypto you describe buys almost nothing for the vast majority of users but introduces many, many scary failure modes. It's false security and a real liability.
I'm speaking from experience - I've used GPG in production systems and watched it randomly corrupt messages. I've played with storing all my personal e-mail in encrypted folders, only to discover that the encryption got in my way and drastically reduced the value of the data. I've worked with people managing large data stores, where bit-rot was a real problem that had to be dealt with.
So many people want crypto "just because". I disagree with that. Crypto has very real costs and drawbacks - if you can't do it right, there is a very strong case to be made that you probably shouldn't do it at all. Storing the keys on the same system as the encrypted data, is ALWAYS wrong and a clear sign that your design is broken. Don't do it.
Jakob Keres
It doesn't give better security to everybody, but to those who want it!
OK, sure. This is an incredibly complicated way to achieve this though.
If you just made it a requirement that people who are this concerned about their privacy host their pods and seeds themselves, then you can pretty much forget about most of the encryption stuff and end up with a much simpler and more robust design.
To use the language of the Diaspora security document
, all the users (who will be the majority) using the Web Client gain zero security by this e2ee stuff, but the crypto slows everything down
A single bit-flip in your key means all your data is gone, forever.
Because of complexity and failure modes. Other things being equal, simpler systems are better.
The crypto you describe buys almost nothing for the vast majority of users but introduces many, many scary failure modes. It's false security and a real liability.
So many people want crypto "just because". I disagree with that. Crypto has very real costs and drawbacks - if you can't do it right, there is a very strong case to be made that you probably shouldn't do it at all. Storing the keys on the same system as the encrypted data, is ALWAYS wrong and a clear sign that your design is broken.
Jakob Keres
Am 25.09.2010 um 15:22 schrieb Simon B.:
> Diaspora is built on Rails and mongodb, both of which typically
> include a RESTful API from the beginning.
>
>> If we have an API, we have to secure the access and do authentication and we'll have the same discussion again.
> So, e2ee will be made a possible option, but it will not be a focus of
> the core developers. It might require one or some few weeks effort if
> it turns out that a new "bindings" ruby-gem must be created.
> (Or you could extract or ask help to get an earlier version of the
> source code that was using GPG (and so being "e2ee" I presume) and use
> that between your private single-seed host and your friends that runs
> the same, if you're in a hurry.)
At the moment I'm not interested in the implementation nor in Ruby. Just in getting an impression how everything could work.
Bjarni Rúnar Einarsson
Am 25.09.2010 um 15:33 schrieb Bjarni Rúnar Einarsson:It doesn't give better security to everybody, but to those who want it!
OK, sure. This is an incredibly complicated way to achieve this though.OK, then, please tell us a better one
Forget "internal" crypto, and just make the server (pod, seed, ...) just work. Make its communication with the rest of the world as secure as possible, using crypto where appropriate and basic access controls (if I don't know/trust you, I won't talk to you) and careful control over information flow to avoid "leaks". Trust the server.
Then make the server as easy to install on private computers as that "secure client" you envision. And you're done!
People can choose, if they want perfect privacy they run things themselves. If they want convenience, they trust a third party. Making sef-hosting easy for the average person is of course not easy at all. But it's not impossible either, software packaging is a relatively well understood problem.
If you just made it a requirement that people who are this concerned about their privacy host their pods and seeds themselves, then you can pretty much forget about most of the encryption stuff and end up with a much simpler and more robust design.
1st:I know a lot more people who are concerned about their privacy than people who a able to setup a secure server. In fact, it is not easy to administer a server, even if you know how to install it. Think of firewalls etc.
A "server" is just software. I do not see why your proposed "secure client" should magically be easier to install and use than a well packaged Diaspora Seed. It's just software.
You are right about firewalls though, IP-addresses, domain names, all that. Power users can generally handle this, but this is a hard problem for the average person. Making this easier is actually what I am working on (it's not Diaspora specific, though), so if you want to help test my stuff, feel free to send me a private message. :-)
2nd:It ist not cheap to own a server. Would you consider a virtual sever to be secure? For a secure sever you need privileged access to the hardware.
You already own a computer, you should be able to use that. Or buy a cheap wall-wart server, as described by Eben Moglen.
3rd:From my point of view e2ee make the design easier and more robust. It takes a lot of the complexity.And again: how do you prevent spam? Easy with signed messages but otherwise you need more communication between the servers.
Encrypting messages does not prevent spam. Spammers have plenty of CPU power and can encrypt things too. You are talking about authentication and authorization, both of which can also leverage cryptographic techniques, but they do not require that the data itself be stored encrypted.
To use the language of the Diaspora security documentWhich document?
The one you linked to. :-) And I know it's not official, I just wanted to be sure I was using the same terminology as you, as part of our original confusion stemmed from the fact that you were using "client" in a slightly unusual way.
So many people want crypto "just because". I disagree with that. Crypto has very real costs and drawbacks - if you can't do it right, there is a very strong case to be made that you probably shouldn't do it at all. Storing the keys on the same system as the encrypted data, is ALWAYS wrong and a clear sign that your design is broken.Ot that you trust the admin, and this what you suggest.
But most importantly, don't build a big complicated crypto system where key management is done completely wrong. All that does is provide false security and make things more likely to break.
I'm gonna shut up now, I've stated my opinion.
Ultimately, this is up to the people writing the code, they get to make the choices. :-)
eveclatrel
I propose this, we accept the server-level public/private key system
and call this "less-secure mode", it can be the default for normal
web-
browsers and devices without client-side encryption. However, we also
implement a client-side system and call this "secure mode", either
through the web-browser with a signed java app or a dedicated app (I'm
thinking option two
might be more comfortable all around). This would encrypt with a key
made and stored locally, using a passphrase (or not, since it's
physical security it can be users choice). These encrypted messages
would be stored on the server in that format, and flagged as secure.
Public keys could be exchanged and stored locally and the messages
would be all viewable in the client-based app. Anyone using "less-
secure" would see a message stating "Secure Message, please log in
Secure Mode to view" instead of the post, picture or profile, and
they
would have to log into a secure client to see it. It would allow for
people to choose if they care about their security or not, and
essentially run two networks across Diaspora. It would break people
up
somewhat, but I would hope that folks will get tired of not being
able
to see certain posts, break down and get a client. And it also gives
you the option to hop on your friend's laptop at the beach and post
"hi mom, having a great time!" (albeit insecurely) without
installing
your keys or software on their machine. I should also note that the
"secure mode" would be able to post insecure messages as well.
Running your own server does not give you added security unless
everyone else is running their own server too. Any information you
would allow your friend to see could be seen by the malicious admin as
well, thus compromising your security as well as theirs. No, the only
real secure methodology is to have complete e2ee, but I realize fully
that the bulk of the populace won't want to fiddle with it. I say we
give them a transitional route, so they can talk to insecure friends
if they want and post stuff securely they feel they should. It gives
them time to get used to it and eventually adopt it. I don't think it
would add a lot of burden to our server design either, just add the
secure flag to messages basically.
andy baxter
> Just to not be 100% negative about the e2ee thing - it is possible.
> The impossible (or hopelessly unrealistic) thing is making e2ee where
> the seed-server itself is untrusted.
>
> Here is how:
>
> * Build a server that is as secure as possible, and communicates
> securely with the rest of the world, using open protocols.
> * Those that want maximum privacy, install the server on their own
> hardware.
> * When accessing their seed, they use a standard browser's SSL
> encryption - a self-signed cert is good enough, especially if people
> are using something like Certificate Patrol
> (https://addons.mozilla.org/en-US/firefox/addon/6415/), which the
> paranoid should of course do.
>
> This means those who want end-to-end encryption can have it using 100%
> standard infrastructure, either by hosting their own server, or
> getting someone they really trust to host it for them.
>
> This is both more flexible, and easier than building a custom client.
>
> Since the server has to be trusted anyway, I would personally
> recommend focusing on strong signatures and
> transport-layer-encryption. Storing encrypted messages on the servers
> (with the keys) is really just snake oil which only makes things more
> complex and more likely to fail.
>
The trouble with people hosting their own server comes when someone
makes a public post that becomes really popular. Say you run a server
over adsl, using a freedom box or similar. For communicating with a
small group of friends this could be fine, but if you suddenly get a
load of traffic it won't be able to cope.
The advantage of having a 2 layer client-federated-server system with
encrypted messages on the server is that you could set up a web client
for yourself or a small group of people that you know, but still entrust
the storage and passing of messages to a bigger server with good
bandwidth, that has enough users that it can absorb a few large spikes
on a particular account. I.e. the people you are trusting to keep your
keys need not be the same as the people you are trusting to run the
message passing server. So more people could benefit from the security
of keeping their own keys but still be able to access the system through
a web interface. (which they could access from any computer without
having to carry their private key around with them).
Michiel de Jong
Reposting from another thread:
I propose this, we accept the server-level public/private key system
and call this "less-secure mode", it can be the default for normal
web-
browsers and devices without client-side encryption. However, we also
implement a client-side system and call this "secure mode", either
through the web-browser with a signed java app or a dedicated app (I'm
thinking option two
might be more comfortable all around). [...]
eveclatrel
Actually I would hope every seed was able to do both, it should be
that much of a stretch to enable it
On Sep 25, 1:12 pm, Michiel de Jong <dejong.mich...@gmail.com> wrote:
> Hey sorry man,
>
> I just posted on another thread without having read yours. Like I think all
> of us, I try to read almost all posts, but don't always succeed.
>
> Good points! I just posted a very similar train of thought on the 'Pretty
> Good Diaspora' thread.
>
> The only think I would like to add to your post is that I think we can make
> the less-secure pods PGP-ready, so they can receive PGP-encrypted messages.
> Thus secure and less-secure become interoperable. What would you think of
> that option?
>
> Cheers,
eveclatrel
Actually I would hope every server/node was able to do both, it
shouldn't be that much of a stretch to enable it
and as a slight elaboration, the "2 networks" is just the passing of
less secure messages that everyone can read regardless of their viewer
and the passing of secure messages that only secure clients can read.
It's just like webmail. I can read any regular message in my webmail
interface, but if I want to see my PGP messages I need to use my
Mail.app or Thunderbird. The server wouldn't really have to care,
since it'll serve up all your messages and either you can see them
outright/decrypt them or you can't. The secure flag is more so we can
tailor the web-based interface to look nicer for those who can't
decrypt messages, otherwise they'd get a lot of nasty looking stuff,
get confused and probably drop Diaspora, thinking "eh, it's just going
to corrupt my messages." I think one flag and a quick UI if-then-else
statement to get around apathetic users is a fair price to pay. Let
their friends motivate them by using the system securely and
preventing them from getting to all those juicy posts and pictures.
Allow the technology to create a social solution to a social problem.
Heck, we might even see a general uptake on SSL/PGP encryption in
other walks of life if we get enough users on e2ee.
shadowfirebird
not giving you mine.
On Sep 25, 12:27 am, Bjarni Rúnar Einarsson <b...@beanstalks-
> The only way to do this sort of thing is with a dedicated, custom written
> client.
>
> It won't run in your web-browser. Your mom won't use it. Your friends won't
> use it. Diaspora's stated goal of providing a privacy friendly alternative
> to Facebook and other centralized social networks won't be met.
>
> You are talking about building something else entirely, which may be
> justified and a worth building, but it's not Diaspora.
>
shadowfirebird
> crypto built into them is at the transport layer, called TLS. This cannot be
> changed in a secure way with just a snippet of javascript or a browser
> plug-in.
http://en.wikipedia.org/wiki/Hushmail
It's not perfect, and maybe not the way we want to go. But it is, in
fact, possible.
shadowfirebird
to mean the browser in this context.
The client is the thing that the user interacts with directly.
Diaspora's user interface is accessed through a web browser; the seed
need not be present on the same computer.
Also, a client is a thing that interacts with a different, server
program. If the browser is the client, it's clear that the seed is
the server in that context. If the seed is the client, what is the
server?
So I think I'm right in saying that in normal usage we wouldn't call a
seed a "client".
shadowfirebird
provide privacy-awareness in that case.
Since the Diaspora team have said what their plans are for this design
element, it may be that there is little point in discussing this
further (although, nothing says we can't continue this for our own
purposes).
Perhaps someone would like to suggest another aspect of the design?
On Sep 25, 12:30 am, Raphael Sofaer <raph...@joindiaspora.com> wrote:
> Our view on this is that end-to-end encryption, while it would be cool,
> isn't practical, and isn't possible as a result.
>
> In order for such a system to work, every user would have to have a private
> key that they kept with them at all times. If they keep it on a computer of
> their own, it is susceptible to loss and only usable from home. The tools
> that might make it practical for non-technical users just don't exist yet,
> and nobody knows how to build them.
>
> That said, every Diaspora user created right now has his own encryption key.
> We'd like for it to be possible for that rare technical user to hold his
> private key himself, and render his data unreadable by his server, without
> creating inconvenience for those he communicates with.
>
> Open to suggestions as always,
> Raphael Sofaer
>
eveclatrel
and private keys are always stored on the server. I may be a little
biased, but my thoughts on a dual system (using the current encryption
direction *and* a standalone non-browser client) still seem sound.
Michiel de Jong
[...] We'd like for it to be possible for that rare technical user to hold his private key himself, and render his data unreadable by his server, without creating inconvenience for those he communicates with.
Open to suggestions as always,Raphael Sofaer
Braedon Vickers
Braedon
Dan White
>The only way to do this sort of thing is with a dedicated, custom written
>client.
>
>It won't run in your web-browser. Your mom won't use it. Your friends
>won't use it. Diaspora's stated goal of providing a privacy friendly
>alternative to Facebook and other centralized social networks won't be
>met.
>
>You are talking about building something else entirely, which may be
>justified and a worth building, but it's not Diaspora.
Does everyone use Microsoft Outlook Web Access to email each
other? Do users have a preference in what software they use? Do
implementations have vulnerabilities that influence choices in software?
There should be lots of implementations of the Diaspora protocol. I'm not
interested in participating in a cathedral replacement for facebook. I'm
interested in helping establish a new state of the art in an open source
social bazaar, so to speak.
On 24/09/10�16:30�-0700, Raphael Sofaer wrote:
>Our view on this is that end-to-end encryption, while it would be cool,
>isn't practical, and isn't possible as a result.
>
>In order for such a system to work, every user would have to have a
>private key that they kept with them at all times. If they keep it on a
>computer of their own, it is susceptible to loss and only usable from
>home. The tools that might make it practical for non-technical users just
>don't exist yet, and nobody knows how to build them.
On the flip side, a web server implementation would require that the server
have the key available at all times. I trust my own security and backup
procedures more than I would a server operator that I don't know, but I do
recognize that I might be in the minority in that opinion.
>That said, every Diaspora user created right now has his own encryption key.
> We'd like for it to be possible for that rare technical user to hold his
>private key himself, and render his data unreadable by his server, without
>creating inconvenience for those he communicates with.
>
>Open to suggestions as always,
>Raphael Sofaer
On 24/09/10�16:36�-0700, eveclatrel wrote:
>To summarize from the other posts for me: 1) I personally want this, I
>believe it's the best approach for security. I don't think that the
>average user will want to deal with it, and will stick to a less secure
>web-browser interface that they are used to.
>
>2) I think that if we're going to do a client-side solution, we should
>compromise and build out a core framework that can be cross ported either
>instantly or quickly. That way platforms can design a UI that leverages
>their strengths. Better end-user experience will increase our popularity,
>and shouldn't drastically increase buil-times.
>
>3) I don't believe we have to choose as implementors which encryption
>method to follow, I think we should do both at the same time and let the
>user choose ("Your Seed, Your Way"). That scenario can be reposted in here
>if it's felt to be appropriate.
+1
On 24/09/10�23:57�+0000, Bjarni R�nar Einarsson wrote:
>Just to not be 100% negative about the e2ee thing - it is possible. The
>impossible (or hopelessly unrealistic) thing is making e2ee where the
>seed-server itself is untrusted.
>
>Here is how:
>
> * Build a server that is as secure as possible, and communicates securely
>with the rest of the world, using open protocols.
> * Those that want maximum privacy, install the server on their own
>hardware.
> * When accessing their seed, they use a standard browser's SSL encryption -
>a self-signed cert is good enough, especially if people are using something
>like Certificate Patrol (
>https://addons.mozilla.org/en-US/firefox/addon/6415/), which the paranoid
>should of course do.
>
>This means those who want end-to-end encryption can have it using 100%
>standard infrastructure, either by hosting their own server, or getting
>someone they really trust to host it for them.
End-to-end encryption and network transport encryption are not the same
thing, and I believe mixing the two can increase security, of course, but
can also confuse users into believing that they have end-to-end encryption
when they may not. I think users and operators will want a layered
approach, where SSL is used to further protect network transmissions, which
I would like to see supported, as long as the protocol does not require SSL
to ensure its security.
On 24/09/10�19:11�-0700, EagleG33k wrote:
>I am by no means an expert on security or rails, but here's my two cents.
>
>I would love to see end-to-end encryption, however I realize (from
>personal experience) that most people simply do not care enough to deal
>with anything other than a password.
End-to-end encryption may not need to be complex, or much more complicated
that having a password, if properly designed.
>My immediate reaction is that a (Firefox, Opera, etc) plugin (or something
>similar - again - I'm not a security expert) would be the way to go to get
>around this. I know this has its own draw backs, but I don't think it's
>too much to imagine an extra click or two would be a pain for most users.
>Ideally it'd have a built-in way to transfer the key from one device to
>another. Yes it'd be a weak spot security wise (maybe use something
>similar to a one-time pad for each transfer?), but it would at least
>require the user to make that decision.
I think you may be mixing the client -> server authentication step, where
one time passwords might be appropriate, with the message encryption and
exchange step. I can't think of a way for one time passwords to be used to
access or decrypt the private key, but I might be misunderstanding where
you're going.
>My second thought is that we should design for the case where the user
>holds their own private key, but provide a graceful fall back solution for
>anyone who chooses to opt-in, ie. via a check box on the registration page
>where if and only if they ask, is their key stored on the pod. Ultimately
>I think this will be the best balance between being user friendly and
>secure. It stays true to the project's goal of being "privacy aware" by
>providing the most secure option by default, yet allows a graceful fall
>back to those who would rather put their trust in the social side rather
>than the technological side of things. That being said - if we do go down
>this route - I'll be doing my best to convince my friends to take the
>extra step and hold their own private key.
>
>One crazy idea I'll throw out to the lions - if we go the second route -
>what would you think of informing a user's friends of their decision of
>where to host their key? On the one hand - if someone is lured into
I don't think it's necessary to do so.
>friending a malicious user - this would tell them exactly where to look to
>grab their private key. On the other - it would allow a non- malicious
>user to potentially place that friend into a separate aspect and take that
>choice into consideration when posting. I'd rely on a
I think that no matter what approach a user takes in sending and receiving
messages on the Diaspora network, they're always vulnerable to being
compromised, either on the server end or via a client running on their
desktop. We can't really design around that, but should consider having an
easy way to un-friend a compromised accounts.
>friend holding their own private key to tell them I was leaving my house
>filled with expensive things alone for a week, but I'd think twice if it
>was possible their key could be more easily compromised. Feel free to
>tear this idea to shreds - I'm not suggesting one way or the other, but
>I'd like to hear what others think of it.
On 25/09/10�12:40�+0000, Bjarni R�nar Einarsson wrote:
>I guess I wasn't clear enough.
>
>Current browsers cannot encrypt and decrypt message fragments, the only
>crypto built into them is at the transport layer, called TLS. This cannot
>be changed in a secure way with just a snippet of javascript or a browser
>plug-in.
I've found an AES javascript implementation, and an OpenPGP javascript
implementation via google searches. Are you sure they cannot be practically
used?
BTW, does anyone know how browsers generate random data? Do any browsers
give access to the /dev/[u]random devices (or their Windows equivelent) via
a javascript call?
On 25/09/10�06:04�-0700, Simon B. wrote:
>+1 @Alex; I even beleive that "allow power users to use a truly private
>private key" is in the roadmap, but that what Raphael wrote above sounds
>like it's not a top priority on his plate. Elsewhere in a "GPG"somthing
>thread I've seen him encorage developers to figure out a way to enable
>using GPG. Presumably this includes using public key servers and in turn
>making e2ee possible for power users.
>
>For now e2ee can be trivially implemented by a power user who runs their
>own host with only their own seed on it. I'm really inspired though about
>the idea for browser plugins that could handle decryption & encryption,
>but I worry that it won't be possible to use on a public/school/cafe
>computer or in a smartphone?
A smart phone user could install a yet-to-be-developed app to perform
encryption.
>Also the users who value a actual e2ee and never type a password into a
>public/school/friends computer and who always carry their own internet
>machine with them, is simply not the primary target audience for
>Diaspora*.
There are a lot more mobile phones [1] in the world than Desktops, which is
a pretty big market for internet machines that get carried around.
>On Sep 25, 4:42 am, Alex Andrews <awgandr...@gmail.com> wrote:
>The average Joe's computer is a less secure place to store a private
>key than on the seed host. In 99% of cases the seed host must be
Why? I actually trust my own (email) users more than that. Average Joe's
just use what ever software they like, and that software might well provide
more security on a Desktop than the server that they connect to provides.
>trusted. If one host becomes too big (facebook anew) then there will
>be a natural migration off users towards smaller more local or
>otherwise more trustable hosts, as well as new efforts into making it
>easy and cheap to run your own seed host. So I see no need to design
Or users dump Diaspora and move on to something else.
>for "worst case hosting", but rather trust the users to figure things
>out for themselves. It's a social network darn it - people are going
>to talk about how to use the network safely as well as sharing lolcats.
I agree with letting users figure things out for themselves, as long as we
give them good options.
On 25/09/10�06:22�-0700, Simon B. wrote:
>On Sep 25, 2:13�pm, Jakob Keres <jakob.ke...@googlemail.com> wrote:
>> Furthermore it is not understandable why we should force people to use a
>> web frontend. Think of what email would be without POP or IMAP. If
>> someone wants a console client, he should be able to use a console
>> client, those who want a web frontend should be able to use their
>> browser. The world is heterogeneous, we should provide a solution for a
>> heterogeneous world.
>
>Nothing stops anybody from building a native client, right? On the other
>hand, it won't be built however much you propagate for it in here :). You
>really need to recruit interested developers that want to / get paid to
>build native clients. Which platforms do you want to have clients for?
A secure and simple API encourages such development. Developers will always
scratch an itch and implement for their own platform, given a big enough
itch and an approachable enough API.
>Diaspora is built on Rails and mongodb, both of which typically include a
>RESTful API from the beginning.
I don't think a discussion of Rails and mongodb should even come in to play
when talking about an API. In my opinion, the API should just define data
structures in XML and/or JSON, and how they are transported, like with REST
or XMPP.
Serializing mongodb data over the network probably isn't a good idea.
On 25/09/10�13:33�+0000, Bjarni R�nar Einarsson wrote:
>On Sat, Sep 25, 2010 at 1:03 PM, Jakob Keres <jakob...@googlemail.com>wrote:
>
>> I'm afraid you're still wrong or I didn't get your point :)
>>
>The corollary of this is, that the average person who is unable or unwilling
>> to install a Diaspora server on his own hardware (and just wants to point
>> his web-browser at a new page) can not enjoy full end-to-end encryption and
>> has to trust a server admin.
>>
>> That't true. I never doubted that.
>> But those, who _are_ willing to use a dedicated app or those who are able
>> to maintain a secure web-client in a local network (that is not reachable
>> from outside and less vulnerable to attacks), but are not able to secure a
>> internet-server, can profit from e2ee.
>> It doesn't give better security to everybody, but to those who want it!
>>
>
>OK, sure. This is an incredibly complicated way to achieve this though.
>
>If you just made it a requirement that people who are this concerned about
>their privacy host their pods and seeds themselves, then you can pretty much
>forget about most of the encryption stuff and end up with a much simpler and
>more robust design.
>
>To use the language of the Diaspora security document, all the users (who
>will be the majority) using the Web Client gain zero security by this e2ee
>stuff, but the crypto slows everything down and introduces all sorts of new
>failure modes. A single bit-flip in your key means all your data is gone,
>forever. That thought bothers me *much* more than the thought of someone
>snooping a bit.
So how do you keep Diaspora from making the same mistakes at SMTP? How do
you prevent spam if you don't encrypt or sign data?
>So many people want crypto "just because". I disagree with that. Crypto has
>very real costs and drawbacks - if you can't do it right, there is a very
>strong case to be made that you probably shouldn't do it at all. Storing the
>keys on the same system as the encrypted data, is ALWAYS wrong and a clear
>sign that your design is broken. Don't do it.
I don't want crypto 'just because'. I honestly believe that Diaspora is
untenable without it.
--
Dan White
shadowfirebird
> > his private key himself, and render his data unreadable by his server,
> > without creating inconvenience for those he communicates with.
> make Diaspora* in some way 'PGP-ready'.
more secure? If those messages are being read through other users
seeds which are externally hosted, is there any point?
Braedon Vickers
Supported security levels, or a way to seamlessly integrate new ones later, needs to be introduced from the get go to make sure that well behaved seeds/clients can tell what security level they should be operating in, and what they should be doing given that level.
Braedon
davidsv
> work. Make its communication with the rest of the world as secure as
> possible, using crypto where appropriate and basic access controls (if I
> don't know/trust you, I won't talk to you) and careful control over
> information flow to avoid "leaks". Trust the server.
>
> Then make the server as easy to install on private computers as that "secure
> client" you envision. And you're done!
alternative to
the problems facing Diaspora at the moment.
The issue with privacy is one of trust. We know for certain that the
user can
trust themself. That's why E2EE would be acceptable if it worked
perfectly and
was easier than making toast. We know that the user cannot trust
Zuckerberg.
That is why Diaspora exists in the first place.
Hence, the question that faces us is where we draw the line of trust.
I see two
solutions to this: trusting only the user (this becomes the E2EE
idea); or
trusting other people.
If we trust others to host our data, we can't know for certain if they
would be
ethical and respect privacy. But, we can build in the ability for the
user to
change between different hosters, in the event that a breach of
privacy occurs.
If data can be migrated seed to seed then any problem with privacy
could be
mitigated. The end user is then faced with two alternatives; trusting
with no choice or trusting a chosen hosting company or friend hosting
a Diaspora
node.
The latter scenario is how email is organised today. One can host
one's own
email server or use a friend to host it; or trust a site like GMail or
Yahoo
Mail or Hotmail to host emails. There are no complaints about email as
a system
as users can migrate from one provider to another.
Of course, with a social network, the output is more prolific, going
to all
pertinent friends rather than just the sender and receiver. Yet, a
culture of
privacy, perhaps with legally binding privacy documents, and refusing
to share
data with a non-free system (helpfully, there is only one major site
in
existence now, and thus every alternative is part of a free network)
would help
to allay concerns.
And finally, if the seed is easy to install at home, many of these
concerns
become moot.
This is not the most pure solution. But it is to my mind the most
practical.
Just my $0.02.
Bjarni Rúnar Einarsson
On 25/09/10 12:40 +0000, Bjarni Rúnar Einarsson wrote:
I've found an AES javascript implementation, and an OpenPGP javascriptI guess I wasn't clear enough.
Current browsers cannot encrypt and decrypt message fragments, the only
crypto built into them is at the transport layer, called TLS. This cannot
be changed in a secure way with just a snippet of javascript or a browser
plug-in.
implementation via google searches. Are you sure they cannot be practically
used?
Yes. I chose my words carefully when I said "cannot be changed in a secure way" - certainly you can do crypto in the browser, using javascript or a plugin. But for this to be secure, the entire resulting page must be 100% generated by the browser, and the javascript must come from a trusted source.
The normal model of "fetch a web-page, fetch some javascript, let the browser render it" includes many, many channels whereby the server delivering the page (or fragments thereof) can subvert any cryptographic actions that take place in the browser. The most obvious is to deliver backdoored crypto code, but there are many others.
If any fragment of the displayed page comes from a remote server, then that fragment can include code which simply waits for the decryption to finish, grabs the decrypted data from the DOM, grabs the *keys as well*, and uploads everything back to the malicious server. Silently, without you ever noticing. This is NOT a difficult attack.
This is why I say a true end-to-end encrypted system can not realistically use a browser as a client. Browsers just aren't designed for this sort of thing.
Jakob Keres
>> Why that? The client (not the browser) can do that.
>
> Just the clarify, I think the rest of us are using the word "client"
> to mean the browser in this context.
>
> The client is the thing that the user interacts with directly.
> Diaspora's user interface is accessed through a web browser; the seed
> need not be present on the same computer.
>
> Also, a client is a thing that interacts with a different, server
> program. If the browser is the client, it's clear that the seed is
> the server in that context. If the seed is the client, what is the
> server?
I get confused. Never meant the seed to be the client. In my language
"server" refers to the seed and the client to any client (web client,
secure client) like described in Security-Architecture-Proposal.
How would you call the "web client" in contrast to the browser?
shadowfirebird
Well, I think the problem is we talk about about client and server,
but we're really talking about an n-tiered architecture. For me the
web client is part of the back end served by the seed...
Jakob Keres
>> Forget "internal" crypto, and just make the server (pod, seed, ...) just
>> work. Make its communication with the rest of the world as secure as
>> possible, using crypto where appropriate and basic access controls (if I
>> don't know/trust you, I won't talk to you) and careful control over
>> information flow to avoid "leaks". Trust the server.
>>
>> Then make the server as easy to install on private computers as that "secure
>> client" you envision. And you're done!
>
> I just wanted to say that this sounds like the most reasonable
> alternative to
> the problems facing Diaspora at the moment.
Yes, but all those people who
* don't have a own computer
* don't have a permanent internet connection
* don't want to/can't use their notebook or computer as sever all the
time
won't use diaspora... I would say 99% of the persons I know - including
me. But may be different in your community.
Michiel de Jong
sorry for not having done this myself to begin with (i was lazy and copy-pasted the existing brainstorm document as-is, which i now realise was not vey constructive of me - apologies!)
EagleG33k
security of e2ee will necessarily be able to host their own server,
even if they would like to. Many, many ISPs have clauses that disallow
residential users (most of us) from running a server from home. Aside
from that, many also prevent it by adding their own hardware in
between the user and the open internet. Diaspora is currently pushing
things to friends servers and this isn't possible if their server
can't accept incoming connections. However, nearly anyone can download
a plugin or even a stand alone application to use. Even on a locked
down work computer you could run it from your flash drive with (for
just one example) portable firefox.
We can't expect users to sign up and pay for hosting somewhere just to
have a server that's accessible, but I think we could expect them to
download an app that would make things just work on the computer they
already have.
Michiel de Jong
Many, many ISPs have clauses that disallow residential users (most of us) from running a server from home
. Aside
from that, many also prevent it by adding their own hardware in
between the user and the open internet.
Diaspora is currently pushing
things to friends servers and this isn't possible if their server
can't accept incoming connections. However, nearly anyone can download
a plugin or even a stand alone application to use. Even on a locked
down work computer you could run it from your flash drive with (for
just one example) portable firefox.
We can't expect users to sign up and pay for hosting somewhere just to
have a server that's accessible, but I think we could expect them to
download an app that would make things just work on the computer they
already have.
Niels Egberts
<dejong....@gmail.com> wrote:
> really? which ISP? which country? that's a problem that needs addressing
> then - not only for diaspora, but also for FreedomBox and many other things
> that we're trying to revolutionize. Can you point me to some reference about
> this? i think in the interest of net neutrality, it should be an internet
> citizen's right to host what he bloody well feels like (obviously, you pay
> for your internet, and get throttled, but that's a different thing than
> downright disallowing).
I have never heard of anyone that the ISP's actually check if you are
running a server or filter data. But in the Netherlands I see it a
lot.
For example here (more :
http://www.internetten.nl/breedband/Ziggo/Internet-Z2/3649/Internet-Z2.htm
Look for:
Eigen server toegestaan: nee (Own server allowed: No).
I have this ISP and I could not find this statement in the contract I
signed, so probably the information is outdated. But I only want to
illustrate that it does happen.
Jakob Keres
>
>
> On Sun, Sep 26, 2010 at 9:07 PM, EagleG33k <eagl...@gmail.com
> <mailto:eagl...@gmail.com>> wrote:
>
> Many, many ISPs have clauses that disallow residential users (most
> of us) from running a server from home
>
>
> really? which ISP? which country? that's a problem that needs addressing
> then - not only for diaspora, but also for FreedomBox and many other
> things that we're trying to revolutionize. Can you point me to some
> reference about this? i think in the interest of net neutrality, it
> should be an internet citizen's right to host what he bloody well feels
> like (obviously, you pay for your internet, and get throttled, but
> that's a different thing than downright disallowing).
In Germany is was very common that the connection was/is interrupted
after 24h and you got a new IP address. I'm not sure if it's still the
same, but it think this happens. Furthermore it happened that the
bandwidth was reduced after you exceeded a certain amount. Also not sure
if this still happens.
But I know this is the case for UMTS connections.
EagleG33k
"use or run dedicated, stand-alone equipment or servers from the
Premises that provide network
content or any other services to anyone outside of your Premises local
area network (“Premises
LAN”), also commonly referred to as public services or servers.
Examples of prohibited
equipment and servers include, but are not limited to, e-mail, Web
hosting, file sharing, and proxy
services and servers;"
https://www.comcast.com/MediaLibrary/1/1/Customers/Customer_Support/Legal/Acceptable_Use_Policy_for_Internet.pdf
And its not just them - another example:
"Customer may not establish a web page using a server located at
Customer’s home. Customer will not use, nor allow others to use,
Customer’s home computer as a web server, FTP server, file server
(this does not apply to file transfers to/from the Customer’s system
for personal use), game server or to run any other server
applications. Customer will not use, nor allow others to use, the
Service to operate any type of business or commercial enterprise.
Customer will not advertise that the Service is available for use by
third parties or unauthorized users."
I agree that its a huge problem, but I don't see it changing any time
soon. My ISP requires I upgrade to their "Small Business" service to
host a server.
Aside from that - I agree there are some ways around this, but its
something we'd probably need to consider. As I understand it (and I
don't understand it very well) this requires some kind of intermediate
server so that the incoming traffic can be disguised as a response to
an outgoing request to the intermediate server. I don't know what the
full implications of doing that would be for security and/or any
protocol we design. Maybe someone here with experience in VOIP or
something similar could enlighten us?
shadowfirebird
(Whether they check is a seperate matter; I've no idea.)
On 26 Sep, 22:13, EagleG33k <eagleg...@gmail.com> wrote:
> It is a violation of the Comcast AUP to:
>
> "use or run dedicated, stand-alone equipment or servers from the
> Premises that provide network
> content or any other services to anyone outside of your Premises local
> area network (“Premises
> LAN”), also commonly referred to as public services or servers.
> Examples of prohibited
> equipment and servers include, but are not limited to, e-mail, Web
> hosting, file sharing, and proxy
andy baxter
>
>
> On Sun, Sep 26, 2010 at 9:07 PM, EagleG33k <eagl...@gmail.com
> <mailto:eagl...@gmail.com>> wrote:
>
> Many, many ISPs have clauses that disallow residential users (most
> of us) from running a server from home
>
>
> really? which ISP? which country? that's a problem that needs
> addressing then - not only for diaspora, but also for FreedomBox and
> many other things that we're trying to revolutionize. Can you point me
> to some reference about this? i think in the interest of net
> neutrality, it should be an internet citizen's right to host what he
> bloody well feels like (obviously, you pay for your internet, and get
> throttled, but that's a different thing than downright disallowing).
>
My last ISP (plus.net in the UK) didn't have an explicit policy on this,
but it did disable incoming traffic to port 80 on my ADSL line, which
took me a while to figure out when I first came against it. (You could
run a webserver on 8080 though).
eveclatrel
clients to be compromised with e2ee if they are on a malicious pod. It
would be a fairly simple man-in-the-middle attack, using a key swap at
the server level. E2ee client creates a private/public keypair, and
you go to add your first friend after connecting to a new pod
(malicious). This pod would capture your public key, and store it in a
"good-key" file, make a *new* public/private keypair and forward that
along to whoever you were trying to contact. That person only knows
you by this bad key, whenever they send messages back the malicious
pod decrypts them, keeps the info or does whatever it's trying to do,
re-encrypts the message with your good key and sends it along to you
for viewing. Neither party is aware of what's going on until it is too
late. I propose a solution however, for key exchange it should be
possible for an e2ee client to contact the friend's server directly to
transmit the public key. It would remove the necessity for
inexperienced users to find a safe way to transmit keys back and
forth, though I will look for a client that lets me define keys
manually as a personal preference.
Braedon Vickers
Braedon
Jakob Keres
> High security public keys really need to be checked in person or signed
> in a web of trust (or by a authority), as being discussed in another
> thread.
Of course, but this would remove one threat, if my pod is malicious but
all my contents is securely stored encrypted on this malicious pod.
Jakob Keres
> I had a thought this morning, it would be possible for high security
> clients to be compromised with e2ee if they are on a malicious pod.
> It would be a fairly simple man-in-the-middle attack, using a key
> swap at the server level. E2ee client creates a private/public
> keypair, and you go to add your first friend after connecting to a
> new pod (malicious). This pod would capture your public key, and
> store it in a "good-key" file, make a *new* public/private keypair
> and forward that along to whoever you were trying to contact. That
> person only knows you by this bad key, whenever they send messages
> back the malicious pod decrypts them, keeps the info or does
> whatever it's trying to do, re-encrypts the message with your good
> key and sends it along to you for viewing. Neither party is aware of
> what's going on until it is too late. I propose a solution however,
> for key exchange it should be possible for an e2ee client to contact
> the friend's server directly to transmit the public key.
Nice idea.
> It would remove the necessity for inexperienced users to find a safe
> way to transmit keys back and forth
it should be sufficient to exchange the fingerprint, which is easier,
although better if it's not necessary.
Also the idea could be that a client has the ability (not to transfer
but) to check if the fingerprints of my public key are right on all my
friends servers.
> though I will look for a client that lets me define keys manually as
> a personal preference.
Your proposal of key exchange could be a requirement that all clients
have to fulfill.
eveclatrel
"secure enough" but still "simple enough" to get uptake. It would be
simple enough for real security minded enthusiasts to manually
transfer and import keys into a local client completely shutting out
any hope that a malicious pod is listening to or transmitting on your
account. Our problem isn't so much that the technology doesn't support
the solution (heck we've known the *real* solution since the
beginning, and it sounds like crypto 101 from what you and shadow.f.b.
have said), it's that the target audience isn't really interested in
the problem. The true battle here is against Joe User's apathy. Right
now it's going to be a balancing act of insecure (or less secure)
methods that the unwashed masses will use and secure options that can
used by those that want them, which I hope will slowly increase as
time goes on. The more popular the Diaspora platform becomes, the more
likely it is to be attacked, and when that happens people will either
take notice of their security or just be plain taken.
On Sep 28, 10:51 am, Braedon Vickers <braedon.vick...@gmail.com>
wrote:
eveclatrel
servers for verification. I was thinking that if it was propagated
throughout the known server list even if the source server was bad you
could still discover the discrepancy and admins would have an easier
time identifying bad pods. That would be true if the client was
expected to upload its fingerprint to its own pod as well as the known
pod list, which could be updated locally if you were worried that all
the "known pods" were malicious too. It would be kind of moot for web
interface clients since they won't have access to fingerprint their
key directly and on a malicious pod you can't expect to get any
accurate data back anyway about other people's key. Those poor folks
are just stuck not knowing if they are talking to Aunt Freda or some
dude who hijacked the server.
This would however generate a bit more traffic if you verified against
multiple servers. I'm not sure how much and if it's negligible, I
would assume that it was, but I'm not up to speed on how hard it is on
the server to request and serve that kind of data. The reason for
propagation is that you might only have 1 friend on this server and
the two pods might not have any known pods in common, but I would
imagine that there will be some commonality within two degrees of
separation. Maybe even put a limiter on it so it only propagates two
or three times to minimize traffic.
davidsv
If we have a voluntary public directory linking people to their public
keys, then most people will choose to be part of it. For those who
don't, they can choose to manually send their public key to friends.
This stops the man in the middle attack, while retaining flexibility
and ease of use.
shadowfirebird
difficult.
Say I want to intercept traffic between you and Alice. Somehow I
need to send Alice my public key and convince her it's yours. If
there is a directory server, then I can put my key there with your
name against it, and wait for her to download it.
The only way to properly guard against MIM is to verify the key using
a completely different channel of commmunication - although not
routing public key discovery through intermediate pods certainly
reduces the risk; I like that.
davidsv
follow-on problems.
ALL aspects of social networking with those who aren't friends must be
conducted independent of the pod. This is because a hostile pod can
mimic any account that you are not friends with. Part of the reason
that Facebook is so successful is the ease of interactions with those
who haven't friended a user's account. If people are unable to trust
directory services to find old friends, for instance, then Diaspora
will not succeed.
I think we need to consider encryption and authentication systems
within this wider context before a decision is made.
Furthermore; this just occurred to me, but it makes encryption sound
like a very bad idea. Say Joe Bloggs User has a computer crash, and
loses his key pair stored on his computer. Most people don't make
backups, and Windows is prevalent enough to make a crash likely for
many people. Unlike with Facebook or any other service, there's no way
of the service provider emailing the key pair to Joe Bloggs. And
furthermore, a 2048 bit key is not something most people will
remember, due to its sheer length. So how does Diaspora ensure that
Joe Bloggs keeps access to his account and doesn't immediately lose
his photos, his status updates and his friend network?
shadowfirebird
> conducted independent of the pod. This is because a hostile pod can
> mimic any account that you are not friends with.
Currently Diaspora doesn't allow it, and I've seen no sign that they
are planning to, not that that means much. Other social networks are
not going to go away; we can always take the view that Diaspora
doesn't need to be able to do that. Personally I'd rather see
Diaspora work to solve the problem of private communication between
friends.
Certainly a hostile pod can mimic any user -- assuming that we store
the keys on the pod, which the team appear to want to do. If we
store the keys ourselves, and check them using a seperate line of
communication, then no-one can impersonate anyone.
> Furthermore; this just occurred to me, but it makes encryption sound
> like a very bad idea. Say Joe Bloggs User has a computer crash, and
> loses his key pair stored on his computer.
price. The guy can always get a new key.
You might equally say: what happens when the pod crashes and loses
everyone's key? Same scenario.
bblfish
On Sep 25, 1:27 am, Bjarni Rúnar Einarsson <b...@beanstalks-
project.net> wrote:
> The only way to do this sort of thing is with a dedicated, custom written
> client
As it happens all browsers implement it. So we're good there.
> It won't run in your web-browser. Your mom won't use it.
Luckily it is in fact really easy to use, contrarty to what the
security
industry will tell you IF you don't use Certificate Authorities.
Here is a video that shows how easy it is do create keys, move
them from one browser to another and use them.
http://www.youtube.com/watch?v=S4dlMTZhUDc
> Your friends won't
> use it. Diaspora's stated goal of providing a privacy friendly alternative
> to Facebook and other centralized social networks won't be met.
>
> You are talking about building something else entirely, which may be
> justified and a worth building, but it's not Diaspora.
I think what he is asking is possible with WebID in fact.
http://esw.w3.org/Foaf%2Bssl
I agree it is very very very odd that nobody has seen that before.
But you know for most of human existance people thought the earth
was flat, and yet it always was round.
>
> On Fri, Sep 24, 2010 at 11:00 PM, Jakob Keres <jakob.ke...@googlemail.com>wrote:
>
>
>
>
>
> > OK, this my plea for end-to-end-encryption (e2ee).
>
> > E2ee is more difficult (or less efficient) to attack than encrypted
> > connections between servers (which I see as alternative). In the latter
> > case a corrupt connection would effect more than one user. Furthermore,
> > even with a working encrypted server-to-server connection but without
> > the usage of signing it would be possible to send spam message to any
> > user. Otherwise the receiver had to check if a message comes from the
> > server the message is supposed to come from. But OTOH a user should be
> > allowed to change the server. This is possible to solve, but everything
> > would become more difficult. Therefore, at least signing is necessary.
>
> > To enable (or at least the possibility for) a client-server model -
> > where the user can have a real secured connection without maintaining a
> > own server on own hardware - e2ee is necessary.
>
> > I don't see any conceptual disadvantages of e2ee even if no
> > client-server model is used. If it turns out that it is too difficult
> > for the client to do the de/encryption, use it as diaspora is doing at
> > the moment.
>
> > Not to use e2ee would mean that the security control is completely given
> > to the server admins. With e2ee and via web of trust, fingerprints etc.
> > the possibility is given to the single user to check the security status.
shadowfirebird
everything you claim it would be practically criminal not to at least
try to use it in Diaspora.
On Sep 29, 11:30 am, bblfish <henry.st...@gmail.com> wrote:
> On Sep 25, 1:27 am, Bjarni Rúnar Einarsson <b...@beanstalks-
>
> project.net> wrote:
> > The only way to do this sort of thing is with a dedicated, custom written
> > client
>
> As it happens all browsers implement it. So we're good there.
>
> > It won't run in your web-browser. Your mom won't use it.
>
> Luckily it is in fact really easy to use, contrarty to what the
> security
> industry will tell you IF you don't use Certificate Authorities.
>
> Here is a video that shows how easy it is do create keys, move
> them from one browser to another and use them.
>
> http://www.youtube.com/watch?v=S4dlMTZhUDc
>
> > Your friends won't
> > use it. Diaspora's stated goal of providing a privacy friendly alternative
> > to Facebook and other centralized social networks won't be met.
>
> > You are talking about building something else entirely, which may be
> > justified and a worth building, but it's not Diaspora.
>
Braedon Vickers
Braedon
Jason Lewis
Jason
Jason Lewis
Jason
Henry Story
On 29 Sep 2010, at 16:20, Braedon Vickers wrote:
> To clarify exactly what it can do, can you give specific examples for how it should be used in Diaspora?
You could use it to login to a diaspora instance of a friend of a friend of yours where you have
never logged in before in one click without using a username or password. Depending on what your
diaspora instance is happy to let him know (as his instance can also use a webid to get access to your profile) he will know as much as you wish him to know about you. Just using REST, TLS and access control patterns.
There is a lot more one can do here.
You need to get this to work:
1. Enable each user profile to create associations from WebIDs to public keys.
publish them, delete them etc... We have code in java to show how to do that so that
it works with all major browsers. The ruby libs pointed to may already provide for that.
2. Enable people to login using WebID to a diaspora instance
either using a simple service such as foafssl.org to get going quickly
or of course better by ssl enabling the server (and adding a hack in the ssl layer -
there are a number for each platform)
http://esw.w3.org/Foaf%2Bssl/HOWTO#HOWTO_foaf.2Bssl_enable_your_Web_2.0_application
Henry
Social Web Architect
http://bblfish.net/
davidsv
> Currently Diaspora doesn't allow it, and I've seen no sign that they
> are planning to, not that that means much. Other social networks are
> not going to go away; we can always take the view that Diaspora
> doesn't need to be able to do that. Personally I'd rather see
> Diaspora work to solve the problem of private communication between
> friends.
user base and be marginalised. Bug number one on the tracker is that
Facebook is the de facto social networking king. If Diaspora doesn't
want to solve this problem, that's fine, just unclear from the aims of
the project. If it does, then it can't leave a killer feature out of
its feature set.
Sorry if that sounds overly harsh, but Diaspora MUST implement all of
Facebook's killer features in order to become successful.
> You might equally say: what happens when the pod crashes and loses
> everyone's key? Same scenario.
to be running in, and that of a client. A pod is probably running on a
dedicated server, and almost certainly on a locked down system (i.e.
BSD or Linux rather than Windows "Insert Current Buggy System Here").
A client is running on someone's day to day OS.
A loss of data on the client is thus far more likely than on the pod.
Jason Lewis
Jason Lewis
Email jasonl...@gmail.com
Mobile 410.428.0253
AIM canweriotnow
Facebook http://www.facebook.com/canweriotnow
michael chrisco
set up subreddits (like the pods), and they sont excatly federate, but
they are close to it between different subreddits. You can definitely
set it up like that. What they have on the diaspora project is a well
created API.
shadowfirebird
> want to solve this problem, that's fine, just unclear from the aims of
> the project. If it does, then it can't leave a killer feature out of
> its feature set.
'privacy-aware' communications working between people who haven't
added each other as friends? What does privacy mean in that context?
> I'd draw a major distinction between the environment a pod is likely
> to be running in, and that of a client. A pod is probably running on a
> dedicated server, and almost certainly on a locked down system (i.e.
> BSD or Linux rather than Windows "Insert Current Buggy System Here").
> A client is running on someone's day to day OS.
patched pod running on Linux is just as dangerous as one running on
Windows; and Linux people are (nearly?) as bad at backing up as
Windows people are.
At the end of the day if you want privacy then some sort of message-
signing and encryption has to take place, and it's a given with that
that losing the key is a Bad Thing. There's nothing we can do to
change that.
Let me give you an analogy: this just occurred to me, but it makes
putting a lock on your front door sound like a very bad idea. Say Joe
Bloggs loses his keys. Most people don't carry spare keys, and there
is no way for most people to pick the lock. So how do we ensure that
Joe Bloggs can still get into his house?
I'm not trying to mock you - I'm just trying to show you the other
side of the argument. We all live with the threat of losing our
keys, and we all lock our doors. The comparison is an apt one.
Jason Lewis
Jason Lewis
Email jasonl...@gmail.com
Mobile 410.428.0253
AIM canweriotnow
Facebook http://www.facebook.com/canweriotnow
Jason Lewis
Dan White
>On Sun, Sep 26, 2010 at 4:52 AM, Dan White <dwh...@olp.net> wrote:
>
>> On 25/09/10 12:40 +0000, Bjarni R�nar Einarsson wrote:
>>
>>> I guess I wasn't clear enough.
>>>
>>> Current browsers cannot encrypt and decrypt message fragments, the only
>>> crypto built into them is at the transport layer, called TLS. This cannot
>>> be changed in a secure way with just a snippet of javascript or a browser
>>> plug-in.
>>>
>>
>> I've found an AES javascript implementation, and an OpenPGP javascript
>> implementation via google searches. Are you sure they cannot be practically
>> used?
>>
>
>Yes. I chose my words carefully when I said "cannot be changed in a secure
>way" - certainly you can do crypto in the browser, using javascript or a
>plugin. But for this to be secure, the entire resulting page must be 100%
>generated by the browser, and the javascript must come from a trusted
>source.
>
>The normal model of "fetch a web-page, fetch some javascript, let the
>browser render it" includes many, many channels whereby the server
>delivering the page (or fragments thereof) can subvert any cryptographic
>actions that take place in the browser. The most obvious is to deliver
>backdoored crypto code, but there are many others.
>
>If any fragment of the displayed page comes from a remote server, then that
>fragment can include code which simply waits for the decryption to finish,
>grabs the decrypted data from the DOM, grabs the *keys as well*, and uploads
>everything back to the malicious server. Silently, without you ever
>noticing. This is NOT a difficult attack.
>
>This is why I say a true end-to-end encrypted system can not realistically
>use a browser as a client. Browsers just aren't designed for this sort of
>thing.
That's a pretty convincing argument. I suppose Java (with signed applets)
would be a better approach to accomplishing e2ee within a client side
browser.
On 26/09/10�22:41�+0200, Michiel de Jong wrote:
>On Sun, Sep 26, 2010 at 9:07 PM, EagleG33k <eagl...@gmail.com> wrote:
>
>> Many, many ISPs have clauses that disallow residential users (most of us)
>> from running a server from home
>
>
>really? which ISP? which country? that's a problem that needs addressing
>then - not only for diaspora, but also for FreedomBox and many other things
>that we're trying to revolutionize. Can you point me to some reference about
>this? i think in the interest of net neutrality, it should be an internet
>citizen's right to host what he bloody well feels like (obviously, you pay
>for your internet, and get throttled, but that's a different thing than
>downright disallowing).
You're preaching to the choir here :) I absolutely agree though, and I'm
proud to say that there are some ISPs (one of which I work for) who get it
and default to not blocking any ports. However, the fact is that many
providers do block incoming port 80 and/or port 25, and require their users
to upgrade to a business class service to 'host' a server.
It's insane, but it's reality, and isn't something that we can depend on
changing anytime soon.
On 26/09/10�14:13�-0700, EagleG33k wrote:
>I agree that its a huge problem, but I don't see it changing any time
>soon. My ISP requires I upgrade to their "Small Business" service to
>host a server.
>
>Aside from that - I agree there are some ways around this, but its
>something we'd probably need to consider. As I understand it (and I
>don't understand it very well) this requires some kind of intermediate
>server so that the incoming traffic can be disguised as a response to
>an outgoing request to the intermediate server. I don't know what the
>full implications of doing that would be for security and/or any
>protocol we design. Maybe someone here with experience in VOIP or
>something similar could enlighten us?
One good way around this problem is to implement Disapora within a generic
protocol, such as with XMPP.
If Diaspora could be implemented on top of XMPP, then 'seeds' could be
implemented as XMPP clients to a public XMPP servers, and interact with
remote seeds via XML messages passed around via 'ignorant of what's inside
the packet' XMPP servers.
In other words, if we could allow participants ways to participate in
Diaspora by running an XMPP Diaspora aware client behind their consumer
oriented DHCP/Address rotating connection, then all we would require is to
have a set of public XMPP servers (which don't even need to be aware of
Diaspora) to provide an onramp for Diaspora participation.
However, there's a problem of how to associate a domain to a particular
XMPP server, and that'd probably require DNS SRV records.
On 28/09/10�07:39�-0700, eveclatrel wrote:
>I had a thought this morning, it would be possible for high security
>clients to be compromised with e2ee if they are on a malicious pod. It
>would be a fairly simple man-in-the-middle attack, using a key swap at
>the server level. E2ee client creates a private/public keypair, and
>you go to add your first friend after connecting to a new pod
>(malicious). This pod would capture your public key, and store it in a
>"good-key" file, make a *new* public/private keypair and forward that
>along to whoever you were trying to contact. That person only knows
>you by this bad key, whenever they send messages back the malicious
>pod decrypts them, keeps the info or does whatever it's trying to do,
>re-encrypts the message with your good key and sends it along to you
>for viewing. Neither party is aware of what's going on until it is too
>late. I propose a solution however, for key exchange it should be
>possible for an e2ee client to contact the friend's server directly to
>transmit the public key. It would remove the necessity for
>inexperienced users to find a safe way to transmit keys back and
>forth, though I will look for a client that lets me define keys
>manually as a personal preference.
There should be a discovery protocol (pull rather than push) for where and
how to find public keys for servers and users. For instance, if a domain
owner points SRV records to a server like:
_diaspora-server._tcp.example.net. IN SRV 5 0 5269 mydiaspora.example.net.
Then the user could delegate any key discoveries to that server, but would
need to trust that server to contain valid keys.
DNSSEC should be used, where available, to validate the accuracy of that
record, to prevent DNS poisoning.
However, as long as the client contains a keyring of end users it wishes to
distribute information to, then a (subsequent) compromise of it's own
domain's Diaspora server, or that end user's sever (assuming e2ee was in
place) would not compromise any messages to or from users that it's already
created a keyring relationship with.
A compromised server could silently become a MITM attacker for any new
relationships though (in the above scenario).
On 29/09/10�03:51�+1300, Braedon Vickers wrote:
>High security public keys really need to be checked in person or signed in a
>web of trust (or by a authority), as being discussed in another thread.
>Another unfortunate reality of 'good' encryption.
That authority could be a server delegated by the owner of a domain.
There'd just have to be DNSSEC in place for that to be secure.
How would a voluntary directory server know that a public key being
submitted is valid?
On 28/09/10�23:15�-0700, shadowfirebird wrote:
>Unfortunately this actually makes MIM attacks easier, not more
>difficult.
>
>Say I want to intercept traffic between you and Alice. Somehow I
>need to send Alice my public key and convince her it's yours. If
>there is a directory server, then I can put my key there with your
>name against it, and wait for her to download it.
>
>The only way to properly guard against MIM is to verify the key using
>a completely different channel of commmunication - although not
>routing public key discovery through intermediate pods certainly
>reduces the risk; I like that.
I agree that there should be an out of band key discovery process, but I
think that should be limited to discovering an authoritative (owning)
server's public key and depend on that server to provide all public keys
for its domain.
On 29/09/10�01:08�-0700, davidsv wrote:
>Those are good points; however, they have some rather disturbing
>follow-on problems.
>
>ALL aspects of social networking with those who aren't friends must be
>conducted independent of the pod. This is because a hostile pod can
>mimic any account that you are not friends with. Part of the reason
>that Facebook is so successful is the ease of interactions with those
>who haven't friended a user's account. If people are unable to trust
>directory services to find old friends, for instance, then Diaspora
>will not succeed.
The reason that Facebook succeeds in this area is that it is the
one authoritative source of information about claimed identities.
That is, if there's a user 'jsm...@example.net' within Facebook, Facebook
can do some validation on that user, such as sending a confirmation email
to that email address, and can then claim uniqueness of that account
throughout the Facebook system. e2ee is not necessary in this environment.
In a distributed network, that can't work (each node just can't send a
validation email in response to each and every friend request).
>I think we need to consider encryption and authentication systems
>within this wider context before a decision is made.
>
>Furthermore; this just occurred to me, but it makes encryption sound
>like a very bad idea. Say Joe Bloggs User has a computer crash, and
>loses his key pair stored on his computer. Most people don't make
>backups, and Windows is prevalent enough to make a crash likely for
>many people. Unlike with Facebook or any other service, there's no way
>of the service provider emailing the key pair to Joe Bloggs. And
>furthermore, a 2048 bit key is not something most people will
>remember, due to its sheer length. So how does Diaspora ensure that
>Joe Bloggs keeps access to his account and doesn't immediately lose
>his photos, his status updates and his friend network?
Why should it? If the key's been lost, it should be treated the same as a
key compromise. Generate a new key and refriend all your contacts. The
private key is king in a distributed network like this.
On 29/09/10�12:23�-0400, Jason Lewis wrote:
>Wow. Just been reading up on WebID, and that's impressive. It seems to
>work similarly to Shibboleth, the open-source standard for federated
>single sign-on. What if joindiaspora.org became a WebID identity provider,
>and then you could use that identity across pods? Trusting
>joindiaspora.org as a WebID provider could be enabled by default, and
>individual pods could trust other providers or not as desired. Then,
>setting up an account would be as easy as going to the provider to
>establish a WebID, and then logging into the pod where your profile will
>reside with those credentials.
>
>We use Shibboleth for SSO at my work, I've done some apache configuration
>for it, and I'm getting ready to add shib authentication to the rails app
>I'm developing there (currently Apache is handling it and passing
>credentials via mod_rails) I should see if there are any FOAF+SSL gems
>already out there.
I've never heard of WebID to be honest. I'll take a look at it.
On 29/09/10�18:28�-0700, davidsv wrote:
>> Not sure what the use case is for communicating with non-friends.
>> Currently Diaspora doesn't allow it, and I've seen no sign that they
>> are planning to, not that that means much. � Other social networks are
>> not going to go away; we can always take the view that Diaspora
>> doesn't need to be able to do that. �Personally I'd rather see
>> Diaspora work to solve the problem of private communication between
>> friends.
>
>Don't expect Diaspora to succeed then. Effectively, it will limit its
>user base and be marginalised. Bug number one on the tracker is that
>Facebook is the de facto social networking king. If Diaspora doesn't
>want to solve this problem, that's fine, just unclear from the aims of
>the project. If it does, then it can't leave a killer feature out of
>its feature set.
You've got to maintain security, or spam creeps into the network for good.
All messages need to be signed at a minimum, and any messages being sent to
non-friends should be limited to friend request, or at least a very small
number of types of messages.
On 30/09/10�11:24�-0400, Jason Lewis wrote:
>Here's some thoughts on the e2ee issue from Michael Chisari, lead developer
>of The Appleseed Project:
>
>Here's the thing about end-to-end encryption, I think people need to take a
>step back and ask what they're trying to solve with it. My understanding is
>that people want to solve the issue of trusting their host. When the plan
>was to make Diaspora P2P (ie, everyone runs a single-user "seed"), then this
>was more doable. The problem is that that's just not practical, and if you
>wanted to do that, you wouldn't write it in rails, you'd write it as a
>system application in ultra-portable C++ or Java, and they realized that
>which is why they moved to a more federated, multi-user approach.
e2ee allows for more control of how a message will be consumed by its
intended users. The issue isn't just trust of the server, but trust of all
servers in the chain of transmission from user to user.
As has been evidenced by SMTP, when relay servers are involved, trust
becomes a huge issue. e2ee security solves many of those trust issues. So,
it is a solution for non-trust for my own 'server', but also all of my
friends servers.
>So if you have a federated structure, what people want is to use encryption
>to make sure that even the host doesn't have access to your data. This
>stems from people's social concerns about data mining and advertising and
>such. But how do you do that, practically, without storing public or
>private keys on the server? That's where the browser has to come in.
You store public keys on the server, and you sign you friend's public keys
with your own private key to establish friendship (these trusts can also be
stored on the server, in keyring form). You store your private key locally
(or on the server depending on implementation).
>I also think this has to do with a tendency to solve social problems in
>social networking with technical solutions, and those rarely work. The best
>solutions to social problems are social solutions (or technical tools to aid
>social solutions). If your host is misbehaving, and selling your data to
>advertisers or spammers or what have you, the low hanging fruit is to allow
>people to move to another host in a federated network. The next step is to
>provide data portability so you can import your data into another host.
> The next step after that is to provide profile forwarding (just like email
>forwarding) so that your contacts can immediately update your identity now
>that you've moved. After that, we can take further steps, but those three
>things will go a long way to making hosts honest.
Good technical solutions become good social solutions through great design.
They should not be separate concepts, at least not within a successful
distributed project.
Data export should be a function that all Diaspora servers (and/or end-user
client software) support.
>And then some people want to take it a step further, and use it to solve the
>issue of whether you can trust your friends with your data. Sort of like a
>DRM for social data. And that's just completely impractical, and I haven't
>seen any theoretical user flow that would be in the least bit practical, let
>alone a working prototype.
And that's what we're missing at the moment (although I'm a few days behind
in catching up on this list).
>I'm not against encryption, but I just think it's basically a waste of time
>until a good UI/UX can be devised that makes it so bloody easy that everyone
>uses it without knowing. Until then, Appleseed has been going the granular
>access control route, and putting all data behind a guard that checks a
>user's privacy controls before serving it up. It doesn't protect against
>your host doing ugly thing with direct database access, and it doesn't
>protect against your friends saving your photos to their hard drive and
>forwarding them, but that's stuff that can be layered on once more practical
>concerns are handled.
--
Dan White