unknown
1970-01-01 00:00:00 UTC
Decentralized payments could change things.
*** Yes! But we're facing huge inertia: of nation states, ofcapitalist banks. Can we get cooperative banks on our side? Can we
convince people that in order to escape from Prism, they need to
invest in their^Hpublic communications infrastructure, and in
their^Hcooperative financial infrastructure; and that this is not out
of reach!
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 consensualcommunity 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.
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.
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
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
invested into realizing it.
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) Client side encryption
+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 notis hard and a topic in itself, it takes time. I would say a goal
to build towards.
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.
2) Social graph obfuscation
*** +13) Self determined data storage
*** +1. I've been looking into OwnCloud 5 and Git-Annex lately.4) Scalability
*** +15) 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 ofcompromise 1 and 2 for those, of course).
+1 Some projects are underway to build this kind of 'driver'
contact with legacy networks), GNU Social (AKA StatusNet+Free Social),
others?
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 theyou want it.
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 myfrom multiple devices at the same time
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 therehtml5 app client (once webcrypto is deployed in browsers).
are some things fixed:
- 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.
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. Trueidentities, and choose to link them or not.
unlinked identities are to remain... unlinked. Maintaining multiple
identities on a single device for example, is hard to protect in case
it is compromised...
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'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.
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,with different protocols, be they XMPP, HTTP, or p2p based.
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.too much for the first phase.
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.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.
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.
[1] 3 years ago:
http://libreplanet.org/wiki/User:Hellekin/A_User_Perspective_Of_GNU_Social