The net.html is an experimental web app that inverts regular web architecture:
Client programs that use the websites of other users as an API to build HTML networks.
It might at first sound like a mashup, or a webring, but it's not any of those things.
What is the app and network?
One goal of this experiment is to see how many of the
network access provider roles
can be taken over by the clients themselves, if they cooperate
to overcome the same-origin policy.
Another goal is to develop a way to easily create
social computer networks
with an expressive medium.
A third goal of the app is to create social networks that are private
and where the "algorithm"
can be explained to and understood by non-technical people.
The app runs in the browser and crawls HTML link networks and stores
snapshots in IndexedDB.
Nodes in an HTML network are simple HTML pages with rel=friend links.
Updates to the network nodes (that are generally static webpage URLs) are
presented as a stream in the app.
In this network you are always in public. Your webpage publishes your
outgoing rel=friend network links to the whole world
(basic HTTP authentication is an option but in the simple case a
static HTML page is publicly accessible).
Those outgoing links are like your personal declarations of trust in
someone else.
Anyone with knowledge of the URL to any node (webpage) in the network
can see all nodes and all connections.
An obvious question is if privacy is possible in a network like this?
Is it private?
The answer is that HTML networks can operationalize contextual integrity in several ways.
As Nissenbaum explains1,
the limits of privacy can be difficult to define except in relation to
contextual norms of information flow and appropriateness.
A network that can encode those norms of flow and appropriateness should
therefore be able to respect the privacy of its users.
First, it is important to note that discovery in the HTML network happens
through the trust graph. It is therefore not required to make your
webpage discoverable through a search engine. And it doesn't need DNS.
When discovery relies on the trust graph of your and your friend's webpages,
it removes dependence on a custodial platform to provide the network
connections which reduces the ability to do mass surveillance.
In the HTML network a "contextual boundary" or "context" in Nissenbaum's sense
is encoded as a webpage URL and the outgoing rel=friend links on that webpage.
A context exists as a perspective of an individual user.
Users can have different sets of outgoing links on their respective network
nodes and the full network is the union of the individual contexts.
The data that is put online on a HTML network webpage is, except metadata like
outgoing rel=friend links or public keys, ambient.
The webpage node expresses the user's personal state at some point in time,
visually and structurally.
Contextual norms of appropriateness and flow are expressed by linking
to other users' webpages using rel=friend links or blocking the app from
crawling particular webpage URLs that are part of the network,
but further away than one hop in the trust graph.
Linking and blocking in the network make the network itself a convergent
encoding of contextual norms.
The user can create many webpages that each contain their own set of outgoing
links. Each webpage represents a separate, potentially isolated context.
For example
https://user.com/school.html,
https://user.com/work.html,
https://user.com/family.html,
https://user.com/friends.html,
https://user.com/sport.html
could be different social contexts for the same user.
Maintaining the secrecy of those contexts is entirely dependent on
the network peers.
While there are no hidden operators in the network that receive implicit trust,
there could be lurkers who know the URL of a network node that you are trying to
keep secret.
Lurkers are hard to detect and can keep lurking for a long time.
Another important difference between the HTML network and the custodial platforms
is the trust that users would conventionally put in the platform
is transferred to the network peers, which is in most cases is a worse solution.
In the HTML network, if just one network node is leaked then the entire network is leaked.
Any end-point compromise would be the equivalent of platform compromise, although contained to that one network.
Is it public?
Being in public is first of all necessary in the HTML network to allow new people
into your network.
And many social contexts do not require secrecy.
Also a precondition for participating in the HTML network is that you have identified
yourself to your web hosting provider and paid them with a credit card.
And while publishing your network connections instead of guarding them with a password
on a platform could be perceived as insecure, when discovery is based on trust,
it ultimately comes down to a question of how to handle end-point compromise.
I believe that HTML networks can be private even when they are public.
You can have approximately the same expectation of freedom from observation in offline public
spaces as you can online behind a hard-to-guess URL.
There are some tradeoffs to building social networks like this:
Message delivery is not guaranteed and restoring lost secrecy can be a lot of work.
On the other hand is that risk manageable and only puts constraints on what
kind of information should be shared.
Besides, the slow HTML network and its
trust graph
can be used as
signaling channel
for a WebRTC messaging overlay for more real real-time peer-to-peer communication.
Direct messaging and presence is the next step.
You can follow the progress by visiting the demo app.
This article is published as part of the HTML link network experiment.
-
Privacy as Contextual Integrity
↩