Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Tent - the decentralized social web

tent.io

Post reply on HN
Print view View original

221–229 of 229 posts

Re: Introducing Tent - the decentralized social web

#221

Post by gizmo686 »

graue wrote: post #219
gizmo686 wrote: post #148

Earlier quoted context omitted.

Just because you cannot prevent all threat models, does not mean you through privacy out the window. For example, if Alice wants to send Bob a message, in the current system: 1) Alice tells Facebook she wants to friend Bob 2) Facebook tells Bob, who accepts 3) Alice sends Facebook the message addressed to Bob (I think in plaintext) 4) Facebook sends the message to Bob. 5) The message is still unencrypted on Facebook…

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still…

> In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does.

Actually, facebook does, and that information is (potentially) available to third parties. The intent of my system is that in order for information to leek, you would need to have one of your trusted recipients be compromised.

Re: Introducing Tent - the decentralized social web

#222

Post by graue »

gizmo686 wrote: post #221
graue wrote: post #219

Earlier quoted context omitted.

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still…

> In contrast, although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does. Actually, facebook does, and that information is (potentially) available to third parties. The intent of my system is that in order for information to leek, you would need to have one of your trusted recipients be compromised.

If you're thinking in terms of Facebook showing deleted updates to law enforcement to track down activists — or some rogue employee at Facebook HQ taking a peek — then we're talking about totally different levels of paranoia. Sure, that is a legitimate concern for the relative few who have something to fear from powerful governments.

For the rest of us, though, someone we unfriend (an ex-partner, for example) being able to archive and still access all of our old photos/updates is a much bigger concern. I argue that distributed social software should follow Facebook's lead and offer a sane default of not having such an archiving feature, and not going out of its way to make it particularly easy to add one, either. Otherwise the "creepy" aspect of not being able to rescind access to your photos/updates is going to be a serious downside to this new network, and could keep people from using it.

Edited to add:

Also, what's more secure in theory isn't always more secure in practice. Moxie Marlinspike observed that the original version of Cryptocat (which did end-to-end encryption in JS) was potentially less safe than Gchat. Why? Because if you compromised Cryptocat's server, you could make it serve JS with a hidden backdoor. And Cryptocat, being a one-man shop, would likely be a softer target than a company like Google, which has had plenty of time and expertise hardening their systems. How much do you trust the guy behind Cryptocat, versus Google with their reputation to protect?

Along the same lines, imagine you use a hosted Tent server for social networking — you don't have time to bother running your own server, but you've heard Tent keeps your data safe from Facebook, so it'll protect your privacy better, right? But then the random guy hosting your Tent account turns around and leaks your info. Or he's running old software with a vulnerability in it, and gets pwned. Suddenly hackers have all your data. Would that have happened on Facebook?

When I was curious about signing up with Diaspora, one of the open community pods had a cheeky note from the server admin saying basically that he would peek in and read your stuff if he felt like it. So this is not entirely hypothetical. I'm a huge fan of efforts like Tent, but let's not forget there are upsides to Facebook and Google's stewardship, and an alternative system can easily have as many privacy/security cons as it does pros. Tread carefully.

Re: Introducing Tent - the decentralized social web

#224

Post by icebraining »

lmm wrote: post #203
icebraining wrote: post #86

Earlier quoted context omitted.

HTTP implements an architectural style which ensures reliability, scalability, decoupling of systems and support for hypermedia for a complex network of disparate, unreliable systems and networks. Do you have any suggestion that provides the same features, or should we forgo them because HTTP is "hefty"?

If you really want a particular concrete protocol to compare to, how about AMQP?

While iMatix was the original designer of AMQP and has invested hugely in that protocol, we believe it is fundamentally flawed, and unfixable. It is too complex and the barriers to participation are massive. We do not believe that it's in the best interest of our customers and users to invest further in AMQP. Specifically, iMatix will be stepping out of the AMQP workgroup and will not be supporting AMQP/1.0 when that emerges, if it ever emerges.

By the way, the AMQP spec is roughly the same size as the HTTP spec, and the latter spends a lot of pages listing just status codes.

And of course, AMQP uses a model based on Sessions, which is great if the components of the system are static, but not that great if you're talking to a lot of nodes who come and go, since you'll end up with uneven load distribution on your servers. Regardless of HTTP as a particular implementation, I think statelessness makes perfect sense in a unreliable network of nodes.

Re: Introducing Tent - the decentralized social web

#225

Post by rhinosix »

lukifer wrote: post #132
enobrev wrote: post #97

A few years back, I started getting interested in a similar idea. I'm definitely intrigued in seeing how well it goes. Good luck to you. Of course, as ideas go, I allowed myself to think further into the possibilities, and found some interesting avenues. For instance, why allow the facebooks, twitters, etc to own domain over our content? Let people store their own data, and offer API endpoints giving facebook, twitte…

It's a great concept, but here's where it breaks down: once data is given out, it can never be retracted. Whether it's an author's novel or a shopper's purchase history, once the data is released to someone in a readable format, they are unable to stop the recipient from doing something they don't like with that data. Granted, the issue can be mitigated with trust networks, social conventions, or laws, but it comes d…

In this scenario instead of releasing a novel, it would be more like allowing a manuscript to be read with an attached NDA.

If an individual owns their own data, they can make a service click the 'I agree' button, and set their own standards on security, data handling, sharing with third parties, and so on.

Yes, they may be able to copy parts of your data and share it with third parties, but you would have grounds to hold them accountable.

Re: Introducing Tent - the decentralized social web

#226

Post by tripzilch »

jancborchardt wrote: post #217
jsilence wrote: post #187

Earlier quoted context omitted.

" Let people store their own data, and offer API endpoints giving facebook, twitter, etc access." That is the goal of unhosted. http://unhosted.org/ I really whish their RemoteStorage protocol would gain traction. The locker project is heading into the same direction, although with a different approach. Posting content to Facebook et al and then recollecting it into your locker. http://www.lockerproject.org/

Thank you for the shout-out! :) There also is an unhosted social network now, check it out at http://friendsunhosted.com (my username is jan@5apps.com, feel free to add me)

I'd be all over this if you'd support the Opera browser :)

Re: Introducing Tent - the decentralized social web

#227

Post by tripzilch »

graue wrote: post #219
gizmo686 wrote: post #148

Earlier quoted context omitted.

Just because you cannot prevent all threat models, does not mean you through privacy out the window. For example, if Alice wants to send Bob a message, in the current system: 1) Alice tells Facebook she wants to friend Bob 2) Facebook tells Bob, who accepts 3) Alice sends Facebook the message addressed to Bob (I think in plaintext) 4) Facebook sends the message to Bob. 5) The message is still unencrypted on Facebook…

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still…

> "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo.

That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help with that anymore.

However, any new photos shared through the same channel can't be seen by Bob anymore because I assume the key changes as the members of the access group change.

Still, while you can't solve the original problem (Bob can leak everything), you can still do slightly better than that by properly implementing Off-The-Record messaging[1]. This adds perfect forward secrecy, as well as deniability: The latter is very interesting because in OTR it means that both parties can authenticate received messages to be certain of the sender's identity, but they can also FORGE any message to look like it's been signed by the other. This means that even if Bob decides to publish your private messages to him, he can never prove you were the one that wrote and signed them, because he could have forged them himself.

Two problems with that: I'm not sure how the OTR protocol extends to multiple recipients (but I bet there's some research on it), and while this "deniability" might be enough for private (text) messages, it's not much use for photographs in many cases: If Bob decides to publish an embarassing photo of you that he had once access to, it's not going to be much use that you can argue "ha, but you can't prove I sent you that photo!".

Still, for textual communication, it adds a (thin) layer of extra security even though you can never beat Eidetic Bob.

[1] http://www.cypherpunks.ca/otr/index.php#docs and in particular http://www.cypherpunks.ca/otr/otr-codecon.pdf

Re: Introducing Tent - the decentralized social web

#228

Post by graue »

tripzilch wrote: post #227
graue wrote: post #219

Earlier quoted context omitted.

> we do have crystallographic methods to encrypt a message such that an arbitrary group of people can decrypt it. This doesn't solve the problem you're responding to: "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still…

> "once data is given out, it can never be retracted". That remains the case. If you encrypt your photo so that each of your 770 friends can decrypt it, but then you unfriend Bob for being a jerk, he's still got the key and the encrypted data. So he still sees that photo. That particular photo, yes. But Bob could also have saved that photo as soon as he saw it or maybe he's got eidetic memory, so crypto can't help wi…

I addressed the "Bob could have saved that photo" point: "although you could theoretically save every photo and update anyone ever lets you see on Facebook, it would be difficult enough that in practice no one does." Facebook has a sane default of not saving everything that you view on your computer. Yes, maybe someone saved one or two photos, but they probably don't have them all.

OTR is pointless for a medium that's mostly about photo sharing. For the Facebook use case, what's far more important than crypto is the set of social norms the site establishes via what's easy to do (share) and what's hard, e.g., archiving everything your friends share as it comes in. Not only would that be tricky to do without getting detected as a bot, but 99.9% of users would never think to try it. This problem is inherently more tractable with a distributed system, and that could be bad.

Re: Introducing Tent - the decentralized social web

#229

Post by maximveksler »

cyarvin wrote: post #202
ninetax wrote: post #176

Earlier quoted context omitted.

And even if it is just as easy, or easier, to set up as facebook or twitter, it still might fail because of the user and the egg problem. As much as I would love to use and have a network like this, until all the people I keep in touch with through facebook use it, I'll still have a facebook. I wonder if it's plausible, even possible, to have all those p2p benefits (encryption, authentication, privacy) and some how a…

Can you make a Tent (or more ambitious social p2p) client which is also an FB client? Of course. FB and Twitter have APIs. Of course, they can revoke your key. But they have web clients, so they can be scraped. Faced with a genuinely distributed opponent, there's no way the existing behemoths can keep your data in their silos. For instance, FB can block tent.is at the API level or even at the IP level. But if Tent ho…

I've been thinking about this idea a lot recently. I'm wondering if you would like to have a discussion? If so, please email me at maxim.hn.4418904@vekslers.org

Maxim.

Post reply on HN