Nezhynska led a tour of the new website and the thinking behind its design, including its accessibility features. It looks very polished; how well it functions as a hub for the DWeb community only time will tell.
Brewster Kahle introduced the meeting by stressing that, as I have written many times, if the DWeb is successful it will be attacked by those who have profited massively from the centralized Web. The community needs to prepare for technical, financial and PR attacks.
Below the fold I look at how the principles might defend against some of these attacks.
The fundamental goal of the DWeb is to reduce the dominance of the giant centralized platforms, replacing it with large numbers of interoperable smaller services each implementing its own community's policies. Inevitably, as with cryptocurrencies and social networks such as Parler, Gab, 4chan and 8chan, some of the services will be used for activities generally regarded as malign. These will present an irresistible target for PR attacks intended to destroy the DWeb brand.
The principles are a start on building a defense for the DWeb brand against the attacks. The idea is to deflect the criticism that the DWeb technologies inevitably lead to bad outcomes by allowing the community to point to statements disclaiming them. How effective this will be is open to doubt, but it may well be the best available defense. The principles fall into five groups:
- Technology for Human Agency
- Distributed Benefits
- Mutual Respect
- Ecological Awareness
Technology for Human Agency
- We urge coexistence and interoperability, and discourage walled gardens. Interoperability based on standard protocols is an essential pre-condition for decentralized networks with diverse implementations.
The canonical response of dominant players to standards-based interoperability strategies is Microsoft's embrace, extend and extinguish. While it is true that Microsoft gradually evolved to a more cooperative approach, their example stands ready to inspire others. The community could learn from the "connectathons" that Sun Microsystems sponsored to ensure interoperability between disparate implementations of NFS. Thinking about structures that encourage "embrace" but discourage "extend" by supporting broad participation in protocol development would be useful.
- We value open source code as a fundamental building block of an open and inclusive Web. Well, yes, ideally this would be the case.
Once dominant content owners forced Encrypted Media Extensions on the Web, Google prevented users from disabling the closed-source plugin that implements them. There was a small outcry, but the vast majority of users couldn't care less; "I want my MTV". So, in practice, if you want to reach a wide audience, you can't be religious about open source (see Linux vs. OpenBSD).
- We aim for peer-to-peer relationships, rather than hierarchical control and power imbalance. Peer-to-peer system architecture can provide resilience and stability that centralized systems, which necessarily have single points of failure cannot. This is the reason the LOCKSS digital preservation system has a peer-to-peer architecture.
However, W. Brian Arthur's 1994 Increasing Returns and Path Dependence in the Economy and the subsequent histories of the Web and social media, not to mention peer-to-peer systems, show how difficult it is to push back against the winner-take-all economics of technology. Systems with increasing returns to scale, such as the Web, amplify small "power imbalances" rapidly. Pushing back is particularly difficult in the case of peer-to-peer systems which, despite their many advantages, are inherently slower and less efficient, and thus more expensive, than equivalent centralized systems. Thus even initially small amounts of centralization in the system tend to grow into major "power imbalances".
- Our technologies must minimize surveillance and manipulation of people’s behavior, and optimize for social benefits and empower individuals to determine how and why their data is used. Three points to support this:
- DuckDuckGo has shown that a profitable business model doesn't depend on surveillance.
- Much research has shown that targeting advertisements is not effective.
- The metrics that Facebook uses to price ads are wildly inflated, part of Facebook's long history of lying to advertisers, politicians and the public.
But as I wrote in The Data Isn't Yours:
Most discussions of Internet privacy, for example Jaron Lanier Fixes the Internet, systematically elide the distinction between "my data" and "data about me". In doing so they systematically exaggerate the value of "my data".Thus the goal must not be to prevent collection of "data about me", which isn't possible, but to prevent aggregation of "data about me", which is a difficult but perhaps soluble problem.
The typical interaction that generates data about an Internet user involves two parties, a client and a server. Both parties know what happened (a link was clicked, a purchase was made, ...). This isn't "my data", it is data shared between the client ("me") and the server. The difference is that the server can aggregate the data from many interactions and, by doing so, create something sufficiently valuable that others will pay for it. The client ("my data") cannot.
- We believe that multiple technical means will be more effective than a single technical solution to achieve ethical and people-centric outcomes. This is an important principle for two reasons. First, a single technical solution, even if it is open source, centralizes control in the implementors of the technology (as we see with Bitcoin), and effectively decreases users' choices (as we increasingly see in browsers). Second, diversity in technology is essential to resisting the likely technical attacks. A technology monoculture will fail abruptly and completely. Avoiding a monoculture has significant costs, which must somehow be paid.
- We believe that decentralized technologies will be most beneficial to society when the rewards and recognition of their success, monetary or otherwise, are distributed among those who contributed to that success. Ensuring that the benefits of technology development flow to the people actually doing the development is an issue for both closed- and open-source software:
- In the closed-source world, two developments over the past decades have greatly reduced to proportion of the added-value of technology developments flowing to the technologists. First, the VCs funding startups have become much better at transferring risk to the entrepreneurs and employees, and rewards to themselves. Second, the lack of anti-trust enforcement has meant that many fewer startups become large, profitable companies providing many employees with rich rewards. Promising startups are purchased by the big companies before they have many employees to reward. Employees of large companies may be comfortable but few are richly rewarded.
- How the volunteer contributors to open source projects can be rewarded and motivated has been the topic of a couple of recent posts, Supporting Open Source Software and Open Source Saturation. It is an increasingly difficult and urgent issue.
- If that is infeasible, proportionate benefit should flow to the community at large. One approach to a compromise between the need for a corporate structure to support significant open source technology with the volunteer ethos is the idea of a Benefit Corporation:
A benefit corporation's directors and officers operate the business with the same authority and behavior as in a traditional corporation, but are required to consider the impact of their decisions not only on shareholders but also on employees, customers, the community, and local and global environment.Although there is no legal requirement for a Benefit Corporation to donate a proportion of its profits to the public good, this requirement can be written into the corporate charter.
- High concentration of organizational control is antithetical to the decentralized web. A successful peer-to-peer system requires some form of "organizational control" over the development of the protocol and encouragement of interoperability. An example is the way the success of Bram Cohen's 2001 BitTorrent protocol in 2004 spawned BitTorrent Inc., and the company's acquisition in 2018 by TRON.
- We believe projects should aim to minimize ecological harm and avoid technologies that worsen environmental health. And:
- We value systems that work towards reducing energy consumption and device resource requirements, while increasing device lifespan by allowing repair, recycling, and recovery. The point about "device resource requirements" is important. I stood out among my engineering colleagues in Sun Microsystems' operating system group because, while most of them had the biggest, fastest machine they could lay their hands on, I always had the oldest, slowest machine the company still supported. Someone had to experience what the least of our customers did. I'm still travelling with old Chromebooks running Linux. Developers rarely live on minimal hardware, a fact that helps them get their jobs done but contributes to rapid hardware obsolescence.
The cost of coordination in decentralized systems means that they are inherently less efficient than equivalent centralized systems. Their benfits in terms of resilience, personal autonomy, etc. are not free. They don't need to, and should not, be as catastrophically inefficient as proof-of-work cryptocurrencies (Bitcoin alone consumes 124TWh/yr, or 0.5% of the world's electricity). But critics will easily find examples of relative inefficiency.