Discussion:
unknown
1970-01-01 00:00:00 UTC
Permalink
We have crypto currencies now and off block IOUs. You just need a web of
trust. I'm going to try and demo completely decentrlaized ads in the next
year, it's a pity
"ad bard" is no longer going or I could have promoted lots of FLOSS
software too...
I agree although Linus was also an exceptional mind, coder and
community leader. He had a pure focus, ie to port the UNIX kernel
to GNU as free software.
In the social web we cant assume that we'll be blessed with someone
as brilliant as Linus, and there is mixed focus, so working
together becomes important, which is one area where standards can
maybe help. I say *maybe* because a standard that is restrictive
may sometimes be counter productive.
*** Yes! We don't need a leader, we need leadership. And consensual
leadership. Based on ethical values, and clearly defined objectives.
The more I look at it, the more I think we should go for the simplest
possible thing, and leave convenience out of it, because convenience
is a vector for surveillance and control.
Ironically, Mozilla made a "Prism" project some time ago that would
allow to run a feature-stripped firefox to reduce risks, and make the
web app look more like a native OS app. A concept that Ubuntu recycled
pretty well, so much that it became itself a vector for
commodification of the user into a consumer.
I love most of what comes out of Mozilla, but underwhelmed with Persona,
which is the identity solution that sits in the middle of most things.
They are in the church of "your email is your identity" -- let's be clear
this is an unnecessary restriction with will not scale. Other projects
(not mentioning any names) *cough cough* are also in this religious sect.
Before we can start to speak about standards, we need to have a
consensus of those interested in a post-faceboogle social web
about its structure and capabilities. You may call this worthy of
a standard in itself, but very basic properties have to be agreed
upon before serious efforts
should be
invested into realizing it.
*** Oh, I think we're on the path to reaching a GNU consensus on free
social software :)
Together with Elijah of the LEAP project we came up with this list
1) Client side encryption
*** +1, but only if it's end-to-end, otherwise, see (8).
+1 Certainly should be an option, or a default, but key management
is hard and a topic in itself, it takes time. I would say a goal
to build towards.
*** We tend to always repeat the same: public communication does not
need to be encrypted, so it's a use case that should easily be agreed
upon. Yet, everything that is not explicitly public is, in my opinion,
to be private: that means, in the current context, strongly encrypted.
Great point. We've not even solved the public version yet. When we do I
suspect the encrypted version will be easy, just some shared keys and AES
or another symmetric cypher, asymmetric PKI, or hybrid, or security by
obscurity. I'm not a huge believe in advertising which crypto algorithms
are being used to the whole world, that all the relevant parties know
should be enough.
2) Social graph obfuscation
*** +1
3) Self determined data storage
*** +1. I've been looking into OwnCloud 5 and Git-Annex lately.
4) Scalability
*** +1
5) Integration of old friends on legacy networks (which would
compromise 1 and 2 for those, of course).
+1 Some projects are underway to build this kind of 'driver'
*** Are you talking about Friendica (probably the largest surface of
contact with legacy networks), GNU Social (AKA StatusNet+Free Social),
others?
Freindica is one sure.
6) High availability - you should be able to access your data when
you want it.
*** Including OFFLINE! I'm not sure whether that is covered by the
more server-sideish "HA".
7) Device portability - you should be able to access your data
from multiple devices at the same time
*** +1, and with various ACLs: I can't trust my phone as much as my
laptop for example. And certainly not a random computer in a random
cybercafe. [1]
8) Client choice - you should be able to use a mobile, desktop, or
html5 app client (once webcrypto is deployed in browsers).
*** Honestly, I'm not sure that is a sane decision. Not until there
- 1 TLS certification authorities (utterly broken and mostly
untrustable)
- 2 TLS perfect forward secrecy implementation everywhere (servers,
browsers) including protection against TLS-downgrade attacks. That's
mostly a matter of proper configuration though.
- 3 Javascript protection: Libre JS to ensure the code run on the
page is genuine and not malicious
- 4 proper protection against XSS, CSRF, and other MITM
3 and 4 are way out of reach at the moment. HTML5 is bringing new
attack vectors, and the development of the Web is going towards more
usage of centralized resources (+1, Like, Login with X, analytics,
etc.) without mentioning javascript-less CSS-based or DOM-based XSS,
plugin-based infection, and mobile phone network insecurity as a whole.
I dont believe in trying to create perfect security, security should be
"good enough" then you start the arms race between attackers and
defenders. Facebook didnt even start with https remember and go to 100
million users. In any other project I'd be a security fundamentalist, but
for a social project, users count, this often seems to be underestimated...
To me (8) is the convenience door open to keeping the spyware operate
as is. We should aim instead for much more ambitious things: secure
hardware, end-to-end encrypted connections (see (1)).
9) Multiple identity - you should be able to maintain multiple
identities, and choose to link them or not.
*** +0 Again I see that as a convenience door open to spooks. True
unlinked identities are to remain... unlinked. Maintaining multiple
identities on a single device for example, is hard to protect in case
it is compromised...
The user should be in control of their identity. They should be allowed to
have their identity the way they want it, so long as it doesnt impinge on
any other user.
These are sometimes called 'nyms' (short for pseudonyms) ... yes
it's important to think in terms of multiple identities, most
systems restrict you to one, and even worse, one that is a subset
of their particular world view.
*** +1. Identities are made to recognize people.
It is in the interest of bureaucracies and surveillance systems to
recognize people globally. That's why they want you to bear a "family
name" and well as a "given name", to get a passport and an identity
card (a recent invention that's supposed to prevent crime, but
everybody knows that criminals can forge identities), or in a too soon
future an implanted chip (now sold as "cool" for VIPs in hype clubs,
"life saving" for people with medical conditions or soldiers,
"protective" for inmates, or "efficient" for cattle).
But in social networks, people are used to share identity with their
own circles, and independently of their "Real Name (TM)". If you're
"Mister Smith" to your employee, you're "John" for your neighbor,
"daddy" for your children, "honey" for your wife, "spud" for your
former classmates, etc. Your identity only means that the people
susceptible to interact with you know who they are addressing
consistently, and you do as well know who is talking to you.
Identity is not about 1 person, but about a bi-directional
relationship. I have nothing to do with the NSA, nor any suspicious
government, nor any marketing entity that want to commodify me. So to
them my identity must be ephemeral.
10) Protocol agnostic - you should be able to cross-communicate
with different protocols, be they XMPP, HTTP, or p2p based.
*** It depends. If I'm willing to use the Briar Transport Protocol,
obviously I don't want nor need that it interoperates with anything
else. Again, spooks might want that, but not me.
If I want to communicate using a protocol, with someone who is using
another, there should be a possibility for me to bridge that
communication to that protocol, but I would not put that as a requirement.
Although I would love to see this happen, it's perhaps taking on
too much for the first phase.
*** Yes.
11) Secure groups - groups with membership determined
cryptographically. Groups function as a virtual user, with all
users in the group able to receive and send as the group, because
they share a private group-key.
*** +1. Private group communication is fundamental.
It's also a hard problem: sharing a private group key was discussed at
length last year during the hackathon in Berlin. Two main issues were
raised: 1) how do you bootstrap the key? 2) what to do when people
join or leave a group?
So maybe the notion of group must be revised as well to match
volatility of the concept. Transient groups might form and want
ephemeral communication; more stable groups will arise and want
perennial archives. Etc.
*
For me, most of the points you propose are conveyed by the
GNUnet/Secushare project, which you mention in your presentation, and
that is the explicit goal of the GNU/consensus project. For which I'm
being an opportunistic Bolchevik and wish for a (somehow short)
dictatorship of the Web people until we are ready to move to a true
p2p architecture. :)
=> hk
[0] The GNU/consensus Whistle is an upcoming monthly newsletter that
should start its life soon. A draft is available on the GNU/consensus
wiki at http://libreplanet.org/wiki/GNU/consensus/whistle/002013-07
and you're welcome to edit it.
http://libreplanet.org/wiki/User:Hellekin/A_User_Perspective_Of_GNU_Social
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCgAGBQJR7YfuAAoJEEgGw2P8GJg9wBEP/Rdc/Akdiei2xEJ6t2aT6Qvn
WHbD72x9TdmP2Q5jj5iHJPnZO3xFCeRx73ZXeXbZKjVTOkP2pG+d5KXCVq7/wUwk
joy0hptBJVW6LSdv1hggf9s4emwfT0K8SyNxl2t5l1KC5EPVLcflZYWsQ2lmw61C
8JJPM2QtPVJbAQ+FiNZnK4DJebzfUPVvkQ19ImANrm/SPAtO0LqnO3UUXWbtRmLf
IXS43+PQn+Yq8Gm/hLVZxaZDR4RVF86eER2fV/993+DUZJczMogNapslQ19Z8VRo
mXXFhg2T9zP1A8w4ZGJJPB6ar5havCBlaS7xWp+zwTDuuwy3pt4VkLpGGG/oNRM5
NGDEed3pGJXloyZ2kapk8vowcVhT8ano/f+uJCbMavhU6f407CjpDAEo+Y1wWhbl
whWOI+oOOkitQfSbSwPP1I2x/JSCJMhI2lSzhC8o1/cMofbmZV8z3tEFAeizFtBa
1VHXYbVzNxhzgDVQqSe8ioj7Q2bd55hvPHaTHdxwTibENjyErij/M6bZJ1wIEYEi
WT+dlePfhfa2/LdVsi5i5BJ4/u+GWLhFKFE9lQevdECJkdS3wzuCBd6SRK3poPee
I5TmAiJZT3XfGZaAXKPjaP/zEK0JoXtiDnI5oki1t5B6BJERT9hSIPxxc4/G1rUZ
xH960Bxxi8w8gYe/KgJi
=LPX5
-----END PGP SIGNATURE-----
--001a11c3504cd7061604e21f4d6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 July 2013 21:28, hellekin <span dir="ltr">&lt;<a href="mailto:***@gnu.org" target="_blank">***@gnu.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
On 07/22/2013 06:01 AM, Melvin Carvalho wrote:<br>
&gt;<br>
&gt;&gt; Klaus Schlesiek wrote: In essence, Edward Snowden has raised the<br>
&gt;&gt; question of &quot;trust&quot;.<br>
&gt;<br>
*** Yes Klaus, you&#39;re right. I share most of your analysis. I posted<br>
some of it yesterday and will correct the draft of the GNU/consensus<br>
Whistle [0] to mention trust as well as privacy.<br>
<br>
At least there&#39;s a shared agreement that we&#39;re living a momentum for<br>
radical change.<br>
<div class="im"><br>
&gt;<br>
&gt; Crowd funding is a good idea.  Although it tends to be non<br>
&gt; optimally allocated.<br>
&gt;<br>
</div>*** That is the challenge we need to overcome! Two days ago I was<br>
sitting in a library with a friend and I was proposing that we could<br>
bring 10 developers from various projects and sequestrate them in a<br>
cheap country to fix the inter-project communication for good. That<br>
would not take a lot of investment to do it under nice weather<br>
conditions, for 6 months to a year, and it certainly wouldn&#39;t take<br>
that long to move from the actual mess to properly functioning<br>
grassroots federation. We could do that with the Mocambos network in<br>
Brazil (Vince?).<br>
<br>
-

Loading...