Re: [GNU/consensus] [SocialSwarm-D] Map of Projects / Sessions at 30C3

[carlo von lynX]

On Fri, Nov 15, 2013 at 12:40:02PM -0300, hellekin wrote:
> *** Until I can run GNUnet and share conversation with people from my
> Emacs, I don't see that happening.  The majority of relevant
> discussion I'm having are happening via Tor+PSYC, Tor+IRC, and
> GPG+Email.  RetroShare still is marginal, as is I2P.

Well, you mentioned Tor twice - and Tor is a cryptographically
routed system, not a federated one. All you need to do is move
on from GPG over mail to GPG over Pond.

> I wish email--that is, the system of: SMTP+POP3/IMAP--would be amended
> or disappear, but first we need the GNS, and proper UIs that mimic
> plain conversation, because that is what people know and like.  When
> talking about email, we should be careful distinguishing the
> underlying protocols, from the general usage habits.

Yes, it could be enough to make newer better UIs since that has
worked impressively well for Facebook, and later consider offering
IMAP gatewaying for legacy-affectionate users.

> In the end, for the user, there's no difference between Email,
> Facebook, or What's App: it's all about conversations, and they will
> use 1) the system that brings them most closely to most of their
> contacts, 2) the system that offers the most straightforward
> interface, 3) eventually, the system that protect their privacy better.
> Obviously, that is a power law, and 3) is already in the long tail.

Point (3) unfortunately still isn't very important to them, so we
really need to do some magic in the field of (1) and (2)

> Your mission, if you're willing to accept it, is to ramp it up to
> provide safety to users who only care about efficient, and maybe
> effective, if they have a personal reason to doubt they're a fish
> inside a net.

Hm. I would simply do something new which is so amazing that everyone
loves to use it. I won't go into details as enemies are reading in.  ;)

> I'd rather keep the discussions about the Pirate Party to the Pirate
> Party.

I removed that line from the website.

> Pursuing "the right design" does not disqualify trying to fix a
> sinking boat, for while the lifeboat is not ready, nobody leaves the
> shipwreck.

But that's not the job of this working group. If you want to fix
up a sinking boat join LEAP. I prefer to simply refrain from having
private conversations over the current Internet. I started meeting
people in person again.. if I can't get them into a secure comm tool.

> > Privacy is about AT LEAST having end to end encryption, which
> > doesn't work if the UI is coming from the server.
> > 
> *** Actually the expected design for Lorea 2.0, that Sembrestels is
> now exploring, consists in moving all the engine to the client side,
> and use the server as a store-and-forward agent.  I believe that
> approach is gaining ground over a pure end-to-end approach that
> requires both ends being online at the same time.  Some use a DHT,
> others dumb-servers.  "Always on" is itself a problematic concept,
> both technically and privacy-wise.

Dumb servers with custom smart software or with a client-side website
that you have to "install" on your computer? In any case you have an
installation procedure, so you could aswell bring something like
Tor or GNUnet along which also protects transaction data.

> > to disable http and other surveillance technologies.
> > 
> *** I fail to see how HTTP qualifies as a surveillance technology.
> HTTP is designed to make information sharing easier.  I doubt sharing
> information can be considered a monopoly of surveillance freaks.

Cookies, E-Tags, Cache bits, counter GIFs, URI session IDs,
SSL session IDs, Javascript session IDs etc etc etc.
All because the browser trusts the server and the web is
so superprogrammable. HTTP is the technology for web sites to
phone home, but you are right.. it's not only HTTP. We also
have web sockets and WebRTC and other bad stuff coming our way
to introduce more surveillance in the web.

> The complexity of protecting the user from that surveillance is nicely
> illustrated by the Content-Security Policy: just try implementing it
> on your website, and see all your Web 2.0 applications break. You
> cannot use Google* or Amazon* or whatever third-party process without
> granting them access to a lot more than you actually intend to
> use--thus, you trust them.  Then, if you're able to stick to the
> minimum, you can still work around CSP by choosing to proxy
> third-party contents "transparently" to your user, without their
> knowledge--thus, they trust you, the website operator, who is only an
> intermediate in the social interaction.

+1