My kids are 7 and almost-9, and they’ve started wanting to talk to their school friends over the
phone. Giving out my cell phone number works when I’m home, but it also leads to calls when I’m out,
and it means the kids can’t just call at any time.
So I set up VoIP
service and got an IP cordless phone, and now the kids can call their friends. I picked a VoIP
provider that’s cheap and very configurable, but also complicated to set up. If you want something
simpler, there are lots of VoIP providers that bundle their service with a particular device. If
you’re willing to handle some complexity, though, this post tries to walk you through the setup.
Chris Hardie also wrote an article on
this, which I used heavily in figuring out how to do it.
For VoIP, you need a device that can translate between the internet and a normal phone. Dedicated
devices for this are called
ATAs,
and you can plug a normal corded phone into these. All of the ATAs I found have to use an ethernet
cable to connect to your router: they can’t connect to Wifi. If you want to use a phone you already
have, and your router is in a convenient place, follow Chris Hardie’s
article for help setting this up.
It’s also possible to get a router that includes VoIP and a phone port. I already had a router, so I
didn’t investigate this.
Finally, there are “IP Phones” that connect to Wifi directly from a handset that otherwise looks
like a cordless phone. Because my house doesn’t have a convenient wired connection between the
router and a place the kids could talk on the phone, and we only need one phone, this is the route I
picked. In particular, I bought a Grandstream
WP816 for $70
on Amazon, and the
rest of this post explains how to set it up.
The initial admin password is on a sticker under where the battery will go, so copy that before
you put the battery in. If you miss this, like I did, then when you get to the Web
GUI,
you can type admin into the user name field, and it’ll give you a ** code
to type into the phone to approve the initial login.
When you first boot it, it might give 2 options for connecting to Wifi. I think they were “Mobile
setup” and “Local device”, but I’d need to factory reset the phone to double-check.
“Mobile setup” will present a QR code that you can scan with a cell phone to connect to a
WP816-provided Wifi network. The “login” page for that network lets you type in your home Wifi
network’s SSID and password.
“Local device” has the WP816 scan for Wifi networks, and then you can type in the password by
nostalgically pressing numbers repeatedly until you get to the letter you want. Get capitals
and symbols using the “Input method switching
key”.
Once you’ve logged in, it’s a good idea to set up automatic firmware updates. Go to
Maintenance | Upgrade and Provisioning, and set:
“Firmware Upgrade via” to HTTPS
“Firmware Server Path” to firmware.grandstream.com
Press , and then press .
While the phone is downloading the update, go to the Provision tab, and turn on
Automatic Upgrade. I picked a weekly schedule. This ensures that any security
vulnerabilities get patched promptly.
The phone will eventually prompt you to reboot to apply the firmware update. While it’s downloading,
you can sign up for and configure VoIP service.
Get VoIP service
VoIP.ms, based in Canada, offers a flat rate of $4.25/month
for 3500 minutes, or $0.85 + $0.009/minute. There are other VoIP providers that cost more in
exchange for simpler setup, but this is the one I picked and that I’ll explain how to set up here.
Visit their page, click
, and use the resulting form to create an account. (Using this link should get both of us $10
off.)
You can do the following in any order, but I’ve put buying a phone number (a
“DID” number) last so that you’ll have the other bits
available to attach to it right away.
Voicemail
Create a voicemail
mailbox, following the instructions in the first part of this YouTube video.
We’ll connect it to things as we create them.
Sub Account
Add a Sub-Account so that the password you enter on the phone isn’t your main
account password. Most fields can stay at their defaults, but
Pick a username and password. Your main account was assigned a number
as its SIP username, and the subaccount’s username (which you’ll enter on your phone below) will be
that number, an underscore (“_”), and the text you type here.
Turn Encrypted SIP Traffic to yes.
Set Internal Extension VoiceMail to the voicemail mailbox you created above.
Time Condition
If you want to restrict when your phone can receive calls, for example so that your kids’ friends
don’t wake you up in the middle of the night, create a Time Condition. I set
mine to only ring from 8am to 7pm Pacific time (note that times have to be set in US Eastern time),
and to go directly to voicemail otherwise:
Phone Number
Now you should add
funds and order
a phone number. Where the video says not to change the routing settings, you’ll want to set it
to either the Time Condition you configured earlier, or the Sub Account under SIP. Once you’ve
ordered the phone number, go to the Manage DID(s) page (under the DID
Numbers menu), and press the icon next to the phone number you just bought. Set the Voicemail associated
with DID to the voicemail mailbox you set up above, and define a Port Out PIN
protection PIN.
Emergency Services (Optional)
The ability to call 911 costs
$1.50/month, and since we don’t
yet leave our kids home alone, we didn’t turn it on for our landline. When we do start leaving our
kids by themselves, we’ll turn it on using the page at https://voip.ms/m/me911.php.
With that, your VoIP account is set up, and you can proceed to connecting your phone to it.
I was annoyed that the phone made noise every time I put it on the charging cradle. If you also want
to turn that off, it’s in System Settings | Preferences |
Enable Charging Tone.
I also got a warning that the User login had the default password. I got rid of that by unchecking
System Settings | Security Settings | Enable User Web
Access.
And you’re done. Let me know if something didn’t work.
Governing Knowledge Commons
by Frischmann, Madison & Strandburg is next in my attempt to figure out if the
idea of a commons can help us keep the Web going. Many of the chapters are
available online, so I’ll try to link to them as I start reading them. I may
skip around to the chapters that look most relevant to the Web, and I’ll
probably skip the paywalled chapters.
I’m a little skeptical of the editors here, since they’re law professors and
might be overly focused on how commons theory affects just intellectual property
law. Chapter 1
section II A does focus on IP law, and while IP law is the way the largest
sanctions are applied on the Web, much more of our regulation uses sub-legal
methods like robots.txt and Javascript paywalls.
[Original]
“Legal limitations on intellectual property rights support the possibility of
constructing commons governance arrangements that allow resources to be used in
ways that generate spillovers”, in section II B, is an interesting statement.
Legal limitations allow more free-riding, or, equivalently, inflexibly require
certain kinds of spillovers. They limit the variety of institutions that it’s
possible to create, but perhaps ensure that the institutions are good?
[Original]
Section IV A: “Unlike commons in the natural resource environment, knowledge
commons arrangements usually must create a governance structure within which
participants not only share existing resources but also engage in producing
those resources and, indeed, in determining their character.”
I’d been thinking that the Web, at least, might have a 2-sided commons shape,
where authors rely on users as a resource system, and users rely on authors as a
resource system. We’ll see if I’m close.
[Original]
“Inevitably, the intellectual products of past and contemporary “producers”
(creators, inventors, innovators, thinkers, and the like) serve as inputs into
later productive activities.”
This reminds me of how the fish in a fishery have children that are the fish in
the future of that fishery. The analogy won’t be exact, but that kinda implies
that the people claiming IP rights over their own ideas are the appropriators
who can overexploit the commons.
[Original]
“the nonrivalrous and nonexcludable knowledge resources that make up the
cultural environment …”
Ideas themselves are non-rivalrous, but as
@luis_in_brief pointed out in
https://blog.tidelift.com/resilient-open-commons,
other parts of a knowledge commons can be, like the maintainers’ time. Other
rivalrous parts might be potential readers’ time/attention and download and
other hosting costs.
[Original]
Oops, 2 paragraphs later: “the nonrivalry of knowledge and information resources
often rides on top of various rivalrous inputs (such as time or money) and may
provide a foundation for various rivalrous outputs (such as money or fame)”
[Original]
“The property scholar Carol Rose emphasizes the role of narratives, especially
of origin stories, in explaining features of property regimes that are not
determinable strictly on theoretical or functional grounds, particularly if one
assumes that everyone begins from a position of rational self-interest.”
This is interesting and, I think, good: Governing the Commons, from 1990, never
let itself model incompletely-rational actors, but humans are never completely
rational.
[Original]
The next section, IV B, goes through a list of questions to answer when doing a
case study of a knowledge commons. I see at
https://knowledge-commons.net/research-framework/ that they’ve added some
questions, so I’ll try to answer those too. Note that these are one person’s
sense with limited thought. It’d be nice to get someone to write an actual paper
about this based on real research (or to read one that’s already been written,
but I don’t see one linked from the knowledge commons site).
[Original]
Background Environment: “What is the background context (legal, cultural, etc.)
of this particular commons?”
The Web comes out of the Internet and a particular research group at CERN
(https://en.m.wikipedia.org/wiki/World_Wide_Web). Its architects inherited and
still have a deep sense that it should first and foremost be good for the world
(https://www.w3.org/TR/ethical-web-principles/). However, as it’s grown to
billions of users, its users have become as diverse in their motivations as the
world.
[Original]
“What normative values are relevant for this community?”
“What is the “default” status of the resources involved in the commons
(patented, copyrighted, open, or other)?”
Copyright covers basically everything on the Web, but there’s a strong emphasis
on fair use, letting search engines build indices, browsers transform content in
lots of ways, and the Internet Archive archives everything. robots.txt and
paywalls are interesting exceptions to the tradition of openness.
[Original]
“How does this community fit into a larger context? What relevant domains
overlap in this context?”
Well! The Web is part of the Internet, which has its own traditions. It’s highly
influential on global politics and the economy, leading to lots of (recent?)
interest from traditional power structures.
I’m not sure what this research tradition means by “domains”: we’ve got
entertainment, news, socializing, commerce, propaganda, and probably a bunch
more.
[Original]
I’m going to take the questions under “Attributes [of the commons]” out of
order, and start with the ones about the Community Members. So, “Who are the
community members and what are their roles?”
We can start with the Priority of
Constituencies:
“users over authors over implementors over specifiers over theoretical purity”.
That gives us 4 kinds of community members, translating “implementors” into
“browsers” and ignoring “theoretical purity” as not a kind of person.
[Original]
I’ll drop “specifiers” as a kind of community member too: we (I’m a specifier)
design the rules for how the browsers and authors interact, but we’re generally
representatives of one of those groups. That is, I think we’re a governing body,
and our place in the Priority reflects an ideal of servant leadership.
[Original]
In principle, the browsers are “user agents”. That is, they’re supposed to be
strictly servants of the users, and so maybe we could ignore them as members of
the community too. In practice, while I think they’ve done a pretty good job of
being faithful agents, they need a lot of funding (~$500M/year if Mozilla is
representative) and could make a lot of money by exploiting users’ reliance on
them. So I think we have to model them and whatever forces are policing their
behavior.
[Original]
What other kinds of community members do we have? Search Engines deserve a
place, with their role of helping users find authors.
Advertising Networks, with their role of getting users to fund everyone else
without noticing it.
What about Social Networks or Framework Authors? Should we distinguish Content
Authors (the humans) from the Publishers/Distributors/Aggregators who connect
them to users?
And do we need to account at this level for Google playing significantly in 3 of
the roles?
[Original]
Leaving those questions unanswered, I’ll focus on Users, Authors, Browsers,
Search, and AdTech as the community members for now.
“What are the degree and nature of openness with respect to each type of
community member and the general public?”
Users: Are the general public.
Authors: Incredibly varied.
Browsers: Open Source; generally make decisions in public standards bodies,
but motivations can be private.
Probably everyone is affected, either by critical services being more easily
available over the Web, or by neighbors’ beliefs coming from websites.
[Original]
Now back to exploring the Resources in the Web Commons, from the perspective of
each kind of community member:
“What resources are pooled and how are they created or obtained?” …
[Original]
Resources for Users: “Accessible” websites are the most obvious. “Accessible” in
both the WCAG sense and in the sense that if you can’t find a site or can’t
afford to pay to find out if it’s worth accessing, it’s not accessible.
Deeper resources might be: true information, entertainment, and “third places”.
In the dawn of the Web, users would write their own pages curating these
resources and share them with each other. Since the advent of good Search, most
users have stopped doing that.
[Original]
Resources for Authors: I think “User Attention” works as a general description.
Some authors want to turn that attention into money, either by selling it to
advertisers, or selling access to their own website, but other authors want to
convince people of things or change behavior or just feel a connection.
Attention is “created” by attracting users to spend more time on the Web, by
showing that the Web is a productive “hunting ground”. It’s rivalrous and
non-excludable.
[Original]
Resources for Search Engines: Search Engines link Users and Authors, and so
their resources are the union of the two? What else might be specific to search
engines?
https://commoncrawl.org/ comes to mind: Engines with fewer resources than Google
can share the work of crawling the web.
Bing has mentioned that it needs click data to improve its ranking to Google’s
level. I don’t know of a commons emerging around that data, but I could imagine
it happening.
Browsers need revenue to fund their development, and so far that all comes from
deals to send searches to Google. (Except Edge which sends them to another
Search Engine.) I’m not sure this is exactly a shared resource, but it’s a
shared problem.
Browsers (and Authors) also share the standards bodies (like the W3C, WHATWG,
Khronos, etc.) that they use to agree on new features.
[Original]
Resources for Advertising: This sub-community needs user attention, specifically
from users who aren’t fed up enough with ads to block them, and (for some ads)
who they know enough about to target. This commons is being overexploited, as
advertisers haven’t found a way to coordinate enough to avoid annoying users
into installing ad blockers.
AdTech also needs a community of entities who want to advertise, but I’m having
trouble seeing that as a commons…
[Original]
“What are the characteristics of the resources? Are they rival or nonrival,
tangible or intangible? Is there shared infrastructure?”
Users: Accessible websites are non-excludable and barely rival, in that
hosting isn’t free, but it is cheap. “Third places” are anti-rival (have
network effects). Do browsers count as shared infrastructure for users?
Authors: Attention is rival. CDNs and server software are shared
infrastructure.
Search: The Search-specific resources seem like public goods. Not very shared,
given the very small number of engines.
Browsers: Revenue is a private good (rival and excludable). Standards bodies
are public goods.
Advertising: Lots of shared infrastructure, both standards bodies and for
exchanging targeting data. Targeting data seems like a club good (non-rival
and excludable).
“What is personal information relative to resources in this action arena?”
(This question might not be a general part of the framework and just an artifact
of the fact that Privacy As
Commons was the last to update
it.)
Generally information about Users counts as personal information, unless it’s
sufficiently aggregated, and information about the other actors isn’t personal
information. Cross-author (site) personal information is newly considered
sketchy.
[Original]
“What are considered to be appropriate resource flows? How is appropriateness of
resource use structured or protected?”
Copying sites to index them is considered appropriate as long as robots.txt is
followed and as long as the resulting search results send “enough” traffic to
the source site.
Bypassing paywalls and blocking ads are contentious.
Sharing user data among authors and advertising networks is also contentious.
There are probably other interesting details here.
[Original]
“What technologies and skills are needed to create, obtain, maintain, and use
the resources?”
The masses of Users and Authors don’t need many skills; their shared
infrastructure (browsers, hosting providers, and adtech) provide access, and, to
the extent anyone does it, handle the work of maintaining the resource pools.
The infrastructure is made of software and consensus-building.
[Original]
Digression: the book says “Some knowledge commons deploy IP rights to solve
collective action, coordination, or transactions cost problems that exist apart
from IP rights and perhaps would not be solvable without these rights (e.g., IP
might be essential to facilitating collective action).” and lists open source
and standards as examples of this. I strongly disagree: the IP rights get in the
way, if anything, especially for standards.
[Original]
@jyasskin For standards, yes, but IMO because they take the fundamentally
wrong approach to IP rights.
Standards (IME, and it’s narrow so maybe there are standards bodies that are
diff / better) typically try to take a weirdly “neutral” stance on IP rights
— requiring that they aren’t “used” or “held” or some such.
IMO, open source is much better at this — actively forcing a legal agreement
to claim and then reciprocally share IP rights to create commons IP
rights.
I’m bogging down a bit, so I’m going to start skipping through the questions as
I see ones with interesting answers.
The “Goals and Objectives” questions seem to mostly have obvious answers, so I’m
probably missing something. People want to be able to keep getting the Resources
mentioned above, but taking too much can threaten the viability of whoever’s
providing the resource. New technology (LLMs) and changes in the balance of
power can threaten the system’s sustainability.
[Original]
I’m reading Elinor Ostrom’s Governing the
Commons to see if I can learn
anything about how to ensure that the Web stays a viable public resource. The
book says its focus is limited to “common-pool resources” in nature that affect
less than 15,000 people, so I’m on shaky ground extrapolating to the Web, but I
will remain optimistic!
One amusing passage: ”… a common set of problems … coping with free riding,
solving commitment problems, arranging for the supply of new institutions (!),
and monitoring individual compliance” (pg 27)
One of these things is not like the others … Or more probably indicates that
we don’t share an understanding of “institutions”.
[Original]
Chapter 2, pg 35–39, talks about how shared cooperative norms can help
individuals achieve better results, and how watching others cooperate can help
individuals cooperate. Unfortunately, a lot of the actors on the Web are
corporations that have been taken over by business school graduates who were
taught to ignore norms in favor of a quick buck.
[Original]
Pg 42 appears to endorse another theorist’s observation that “supplying a new
set of rules is the equivalent of providing another public good … a
second-order collective dilemma.”
But participating in defining rules isn’t a simple public good: the more you
participate in defining rules, the more your interests are reflected in the
content of those rules. I hope she’ll clarify the dilemma she sees.
[Original]
This body of research should be read like all other bodies of research. First,
it should be read cover-to-cover, multiple times. Then, it should be read
backwards at least once. Then it should be read by picking random research
papers and following all the cross-references.
Chapter 3 starts to show a tension between commons management and modern ideals
of free immigration, although it also says that high emigration was important to
maintaining this commons. I wonder if that’ll turn out to be a theme, or if some
commons also work with more open immigration.
[Original]
“The Tribunal de las Aguas is a water court that has for centuries met on
Thursday mornings outside the Apostles’ Door of the Cathedral of Valencia.” pg
71
[Original]
Design Principles
Pg 90 presents 8 design principles drawn from long-enduring (think 500 years)
institutions that manage common-pool resources (CPRs).
[Original]
Clearly defined boundaries: Individuals or households who have rights to
withdraw resource units from the CPR must be clearly defined, as must the
boundaries of the CPR itself.
This is clearly a problem for the public Web, since we want the Web to be for
everyone. Maybe we shouldn’t think of the public as the ones withdrawing
“resource units” from the Web, but rather aggregation tools, or a similar idea?
That’s also a problem as long as the tools are owned by corporations instead of
people.
[Original]
Congruence between appropriation and provision rules and local conditions
This basically says that we should expect to figure out our own rules for the
Web and not be able to just copy them from elsewhere.
[Original]
Collective-choice arrangements: Most individuals affected by the operational
rules can participate in modifying the operational rules.
This is again a problem if we expect 3–7 billion people to participate, but
maybe less so if there’s a way to only constrain the people who risk damaging
our commons.
[Original]
Monitors, who actively audit CPR conditions and appropriator behavior, are
accountable to the appropriators or are the appropriators.
Graduated sanctions: Appropriators who violate operational rules are likely
to be assessed graduated sanctions (depending on the seriousness and context
of the offense) by other appropriators, by officials accountable to these
appropriators, or both.
These principles are followed by a long section with several insights…
[Original]
One bit reminds me of an institution adjacent to the Web: “graduated punishments
ranging from insignificant fines all the way to banishment” sounds like the
system by which browser root programs regulate Certificate Authorities.
[Original]
Back to the Web, this section discusses how monitoring for rule violations has
to be built into the way people follow the rules themselves, or has to be
directly funded by the rules. We’re starting to think about this in principles
like https://www.w3.org/TR/privacy-principles/#transparency, but we have a long
way to go in incorporating monitoring into the ecosystem itself instead of
external researchers.
[Original]
Conflict-resolution mechanisms: Appropriators and their officials have rapid
access to low-cost local arenas to resolve conflicts among appropriators or
between appropriators and officials.
This feels straightforward to do well once some rules are in place and not worth
worrying about before some progress has been made on other parts of the puzzle.
[Original]
The rights of appropriators to devise their own institutions are not
challenged by external governmental authorities.
This will be a problem. We’ve already seen this to some extent in the CA Root
Program space with CAs appealing to European regulators when they didn’t want to
follow the CAB Forum rules. With the Web mattering so much to so many
governments, it’ll be easy for defectors to ask a government to intervene even
if we get the commons management right quickly.
[Original]
Nested enterprises: Appropriation, provision, monitoring, enforcement,
conflict resolution, and governance activities are organized in multiple
layers of nested enterprises.
It’s not clear to me how this will apply to the Web. This might be another
principle like (6) where it’s just a reminder to get it right once we’ve found
some overall rules.
[Original]
@jyasskin this describes how the web works doesnt it? IETF, W3C, DNS, national
policies, eurozone, etc. another way to understand this is polycentricity—
overlapping domains of decisionmaking at various scales with various
subdomains within them. Which is also to say, these principles arent
applicable to one thing, because resources arent usually discrete things. It’s
fractal.
It’s been pointed out (see the edited OP for credits) that researchers continued
to study this aspect of the commons problem at https://knowledge-commons.net/.
I’m going to keep live-blogging this book, but my readers should keep in mind
that I’m just a programmer who’s new to the space, so many of my observations
and guesses are likely to turn out to be naïve compared to the discoveries from
34 more years of research.
[Original]
Case Studies
Chapter 4 is about how Southern California water basins created systems to
manage their commons. This is the setting in which Ostrom developed her theories
in the first place.
These stories strike me as the most like privatization I’ve seen so far in the
book. They’re different from the traditional interpretation of the Tragedy Of
The Commons in that the distribution of the new private property was negotiated
among most of the appropriators, but they still came out with tradeable
property.
[Original]
Pg 129 discusses how the water basin associations organized a state law to let
each water commons create an institution to manage itself. That worked because
the state had many distinct water commons with local features.
The Web, on the other hand, spans many legal jurisdictions and only exists once
in each, so it doesn’t make as much sense to create a legal framework for, say,
the W3C to instantiate.
[Original]
Ah, on pg 136 she distinguishes between the privatized rights to the resource
units made available by the water basins (acre-feet of water/year) and the
communal management of the basins themselves. If they were actually just
privatized, the basins themselves would also be tradeable.
[Original]
Pg 140: “The origins of institutions and changes in institutions frequently are
[incorrectly] considered to be fundamentally different. Endnote: This
distinction characterizes my previous work.”
I like that she was willing to point out her previous mistake.
This is also a really key point: unless you have overwhelming power, as do some
governments, monopolists, and monopsonists, you can’t invent a new complete set
of rules from while cloth. You can only incrementally evolve what you have.
[Original]
Overall, chapter 4 was too narrowly focused on one kind of commons in one US
state to feel like its examples are going to be very useful in designing a
future for the Web.
It’s good that it indicates that subsequent researchers probably focus on how to
evolve institutions (which we already have some of for the Web) instead of
staying stuck on creating them from scratch, so there’s probably good research
around for me to keep reading.
[Original]
Skipping a couple stories from chapter 5, pg 149-157 discusses a fishery where
national officials kept overriding the participants’ collective wishes, like
eIDAS threatened to do to the certificate authority system in Europe. In
fisheries where this didn’t lead to overfishing, it instead led to private
ownership of the whole fishery with “undesirable … distributional
consequences” due to their monopsony position driving down wages.
[Original]
“Irrigation engineers [in Sri Lanka] strongly identify with the
civil-engineering profession, in which esteem derives largely from designing and
construction public works, rather than operating and maintaining them.”, pg 164.
Software engineering has the same problem, as does the promotion system at
Google, at least.
[Original]
The last story in chapter 5 has an endnote discussing how technological
advancements can destabilize the agreements governing a commons. The commons in
that section convinced the early adopters to discard the new equipment they’d
bought.
We’re definitely seeing this in the Web as LLMs overturn lots of existing
conventions and shift the balance between (what this book calls) appropriation
and provision.
[Original]
Chapter 6, pg 190: “Success in starting small-scale initial institutions enables
a group of individuals to build on the social capital thus created to solve
larger programs with larger and more complex institutional arrangements.”
This will be a good reminder for W3C leadership like me, who will be tempted to
try to organize the whole Web at once.
[Original]
This was implied by some of the water basin stories in Chapter 4, but Chapter 6
pg 196 emphasizes that institutional change is helped if data about the state of
the commons is collected and distributed to all participants.
The difficulty of this is illustrated by the development of the Privacy Sandbox
over the last several years: despite lots of research, there’s still no
consensus around how much online advertising revenue depends on cross-site data,
or how that revenue is distributed.
[Original]
Enablers for Institutional Change
The book ends with a list of characteristics that Ostrom expects to predict
institutional change to protect common-pool resources. Starting with the
“internal” characteristics, and adding my comments about the Web:
Most appropriators share a common judgement that they will be harmed if they
do not adopt an alternative rule.
This probably depends on the part of the Web and may be changing quickly when it
comes to LLMs.
[Original]
Most appropriators will be affected in similar ways by the proposed rule
changes.
We don’t yet have any proposed rule changes, but this seems very unlikely given
the variety of entities using things published on the Web.
[Original]
Most appropriators highly value the continuation activities from this CPR; in
other words, they have low discount rates.
I’m worried about both the startups and large companies here: VC-backed startups
get high discount rates from their VCs and short runways, and several of the
long-standing companies in this space seem to have recently acquired high
discount rates and demonstrated them in laying off employees. The experienced
individuals do value the continuation of the Web.
[Original]
Appropriators face relatively low information, transformation, and
enforcement costs.
I think we have high information costs: it’s hard to get trustworthy information
about the viability of production for the Web or the effects of various rule
changes.
We have good venues in which to discuss and agree on rule changes, and lots of
experience finding consensus in those venues.
Enforcement costs are high, requiring use of multiple national legal systems.
[Original]
Most appropriators share generalized norms of reciprocity and trust that can
be used as initial social capital.
This is hard to evaluate when the actors here are companies, often huge ones,
who send different kinds of individuals to negotiate for them. The technical
representatives to standards bodies have these norms and social capital. I
suspect the legal and business representatives don’t, but I don’t have the
experience to be sure of that.
[Original]
The group appropriating from the CPR is relatively small and stable.
Ostrom doesn’t present a numbered list of external characteristics, so I’ll try
to paraphrase here.
A political regime that allows substantial local autonomy.
We have a long history of this on the Web, and of fighting off attempts to
centrally regulate the Internet and Web. However, recent history might be
showing a reversal of that trend.
[Original]
A political regime that invests in enforcement agencies.
This one’s mixed: there’s generally good enforcement for legal decisions within
the countries that large multinational companies care about, some recent
enforcement of privacy and competition regulation, and very little effective
enforcement of anti-fraud norms.
[Original]
A political regime that provides generalized institutional-choice and
conflict-resolution arenas.
I might be missing an aspect of this, but I suspect this one’s a “no”, given how
many countries need to be involved in any legally-enforceable agreements that
would cover the Web. That said, we have lots of standards venues that can serve
as conflict-resolution arenas.
[Original]
And that’s the book! It’s definitely been helpful in starting to think about how
to manage the commons involved in the Web, but I’m also looking forward to
learning what the next 30 years of research discovered at
https://knowledge-commons.net/.
[Original]
The kyriarchy (racism, sexism, ableism,
homophobia, transphobia, etc) is the default. In Twitter, in Mastodon, in the U.S., in Europe, in
Asia, in me, and in you. It’s what we do effortlessly because we’ve been raised to do it. But with
effort, we can reduce the harm we cause and protect the people who would otherwise be oppressed.
So we have to make an effort. Raise up oppressed voices. Don’t
*splain to them.
#TipYourServer and help moderate it. (And more generally,
pay for community-run and small services instead of relying on “gifts” from dominant corporations.)
Learn to do better.
I’m running for the W3C TAG this year. I was thrilled to see that we got 9 candidates with a wide set of complementary skills and focuses. Tess and Sangwhan have done a great job on the TAG and provide unique perspectives, so it would be a shame if they weren’t re-elected. Lea will provide an important connection to web developers, so it would also be a shame if she weren’t elected. That leaves one more seat for which the right choice is less clear. More than one of the remaining candidates would do a great job in that seat, and I wish there were more seats to put us in, but there aren’t, so you should vote for me.
You should vote for me because I care about many of the same things you care about, and I have deep experience making them compatible with the Web’s strengths and other people’s constraints, and then negotiating them into browsers.
I designed the Web Bluetooth API and the security UI that gave Chrome, Edge, Samsung Internet, and Opera the confidence to ship it. That security UI enabled a series of follow-on device APIs like WebUSB, Web Serial, WebHID, and Web NFC. These and many of the other Fugu APIs demonstrate how we sometimes have to trade off between capability, safety, and other concerns, but other times we can design features that do better on several axes than what was previously possible.
Taking Bluetooth as an example, it’s clearly less safe to give someone else’s code access to any of your Bluetooth devices, than to turn off that radio. We have a capability-vs-safety tradeoff here, and we can pick various points along that tradeoff:
Disallow all Bluetooth access.
Allow you to give a device’s manufacturer permission to access their devices, but nobody else.
Allow you to give anyone permission to access devices.
But we could also have picked a design that isn’t at the Pareto frontier of the tradeoff: if you want to grant a program access to one device, you’d have to grant access to all of your devices at once. This is what all operating systems except the Web do for Bluetooth. So when designing the Web Bluetooth UI, I had an opportunity to move closer to the Pareto frontier when looking at the computer as a whole, even though we also had to shift along that frontier—trade off capability against safety—when looking at the Web by itself.
If you think we need to look for creative ways to add capabilities, security, and privacy when we can do it without sacrificing the others, while also deliberately choosing the tradeoffs when we do need to sacrifice something, vote for me.
An even playing field
We all benefit when people and businesses with innovative ideas get a chance to show that those ideas are better than the status quo, and we lose those ideas when the systemic effects of the existing architecture give large players an advantage. As Mark Nottingham recently pointed out, the Web’s architecture is “extremely well-adapted to enabling creation of platforms (on top of it) that accrue network effects, where decentralised solutions could have emerged.” The TAG is the right group within the W3C to make recommendations about long-term architectural changes that could resist this pressure.
The TAG is going to need help to make the right tradeoffs here, and to find the right points of leverage to get our changes adopted widely. The tradeoffs can be tricky: sometimes centralization in one area is helping to offset the power of centralized actors in another area. If we introduce a Web feature that decentralizes that first area without also decentralizing the second area, we could cause even more-concentrated power over the whole system. We need to come up with guidelines for making that tradeoff.
The W3C also can’t just adopt a Recommendation for a decentralizing API and expect that developers and users will automatically adopt it. We need to design incentives and evolutionary pressures that are strong enough to overcome the network effects and status quo bias that led to the current centralization. Browsers are one of the strongest levers the W3C has to get its standards adopted, and as a voice within Chrome, I can help figure out how to get access to and use that power.
Productive discussions
My style is to try to find a way to make everyone in a discussion happy. Often that means noticing where participants are talking past each other or using the same words for different concepts. This was one of my primary contributions as chair of the C++ Library Evolution Working Group. Other times, I’ve had to invent or help the participants invent a way for everyone to get most of what they want, like in the case of the Web Bluetooth chooser UI. In the worst case, I try to find a shared understanding of a small set of core disagreements, which we can continue to discuss even after we’ve picked one or the other side for the immediate decision.
In the W3C, I started the Target Privacy Threat Model to document the places we both agree and disagree about what privacy guarantees the web platform should provide. In addition to focusing privacy discussions on areas we disagree, this model helps feature teams design their features under the right set of constraints. Previously, feature teams would design a feature without knowing what privacy advocates would say about it, and then get into a fight at the end of their development about what parts of the feature they needed to cut. Like the TAG’s Design Principles, the Privacy Threat Model avoids surprises and lets the experts focus on difficult or truly-controversial cases.
Privacy and other human rights
The W3C has long had a focus on making sure the Web protects certain human rights. The Accessibility, Internationalization, and Privacy horizontal reviews have made sure our Recommendations consider those needs. Both the Accessibility and Privacy groups have recently been doing a good job of considering the end-to-end implications of technical decisions. Accessibility folks have been finding designs such that web developers who are targeting and testing for non-disabled users will accidentally serve users with disabilities as well, and Privacy folks have been defining a threat model to set limits on what a privacy-hostile developer could do with the complete web platform. On the TAG, I will insist that we keep that wide focus over our systems’ higher-order effects, even when the developers between us and our users have different priorities.
More recently, the IETF has created a Human Rights Protocol Considerations research group, and the TAG has started writing a set of Ethical Web Principles. These extend the set of rights that we consider fundamental for users on the Web, and for people affected by the Web. We have much less experience turning these principles into concrete API designs. I’d like to work with the IETF group and draw on the breadth and depth of experience represented by people working in the W3C to turn our principles into tangible change.
What about Google?
Several groups are concerned about the amount of power Google has in the web ecosystem, and likely worry that electing me will just increase that power. While I do have some biases from working in Google’s environment and having more access to pro-Google arguments, I’m also happy to publicly disagree with Google policy when it’s wrong. Being on the TAG will help me route critical opinions to the right people within Google and will help convince those decision-makers that their preferences have been given a fair hearing if the TAG decides against them.
Vote for me! And the other great candidates!
Again, the voting deadline is January 5, and every AC member’s vote will be important. If I’m elected, I’m really excited to work with the amazing people running here or already on the TAG. If not, I’m still confident that we’ll have an excellent TAG to shepherd the Web’s architecture for the next year. Happy holidays!
Now, obviously, if a page loads an ad from a URL, then blocking that URL will
block the ad. But the web is an evolving system, and ad blockers are in an
adversarial relationship with publishers, advertisers, and ad-tech companies who
all want to make sure users see their ads. Those ad folks are smart and capable
of finding ways around naïve attempts to block their ads. So what prevents them
from avoiding that list of URLs? Why do URL-based ad blockers keep working?
This post primarily tries to answer that question, not to answer Pete’s concern,
but it does eventually come back to web bundles’ effect on ad
blocking: they don’t really affect any of the
reasons sites haven’t pursued an arms race with ad blockers.
A user who has installed an ad blocker has sent a pretty clear signal that they
don’t want to see ads. Advertisers and publishers may not want to risk angering
such users by showing them ads anyway.
And even though around a quarter of all web users use ad blockers, that may
still not be enough to pay a publisher to engage in an arms race with ad
blockers.
Functionality that needs an online endpoint
The far bigger reason that ad blockers keep working is that advertisements are
usually fetched based on the results of an auction that runs as the surrounding
page is downloaded. Whoever runs that auction accepts requests at some URL and
responds with ads. That URL is a nice stable target for ad blockers. The
auctioneer could dodge the blocker by changing the URL whenever it gets blocked,
but then they have to find a way to update all of the publishers’ pages that
were written to call that URL. That’s a big logistical problem.
The first thing the auctioneer might try is to have
the publishers load a <script src="https://auctioneer.example/auctioneer.js">
that includes the dynamically updating auction endpoint. This is often known as
an “ad tag” and is usually the way ads are served even when they’re not trying
to avoid ad blockers. But, oops, now the ad blockers are blocking
auctioneer.js, and the auctioneer is back to the original problem.
Obfuscate the URL
It’s straightforward to obfuscate the URL for the auction endpoint, for example
by encrypting it with the current date and even a key provided to the particular
publisher. The auctioneer can decrypt the request on their server, and run the
resulting auction. If the auctioneer isn’t careful, this will lead to their
entire domain being blocked, but they might be lucky enough to run a popular
website on the same domain, which ad-blocker users would be sad to lose access
to. They’ll need to encrypt every resource on the server in the same way to
avoid letting the URL-based blockers distinguish.
The bigger problem is that now they have some complicated code copied to every
publisher’s page. If that code ever needs to be updated, it’s going to be a
problem. And they can’t abstract it into an auctioneer.js for the same reason
as before.
Proxy via the first-party server
The auctioneer could also ask the host of each page to act as a proxy for either
the auction request URL or the auctioneer.js posited above. The page would
request /any_url_the_publisher_wants.js, and the server would forward that
request to the auctioneer and reply with their response. Because of the number
of different publishers, it would be difficult for an ad blocker to block all of
the script names they picked, and a publisher that wanted to avoid ad blockers
could be as creative as they like in rotating those names.
However, this is still more difficult for publishers to adopt than pasting an ad
tag on their site, and that difficulty seems to have been enough to stop this
technique from being widely adopted. Proxying too much would also make it hard
for the auctioneer or advertiser to detect ad fraud, since ad fraud detection
currently depends on inspecting connections directly to end-users.
Run a CDN
The auctioneer could also offer to act as a
CDN for publishers
that want to avoid ad blockers. By proxying all of the publisher’s content, they
can automatically rewrite the ad tags into randomized local references that an
ad blocker can’t distinguish from the page’s actual subresources. However, the
publisher can only do this with one auctioneer, and they need to trust that
auctioneer to do a good job serving all the rest of their content.
What about first-party ads?
A publisher that sells their own ads might not need to make a separate request
for ad blockers to target. Instead, they have a choice between an easy-to-manage
URL space with all the ad-related resources in a separate path that ad blockers
can target, vs ads mixed indistinguishably among the site’s other resources. The
second costs enough development and maintenance time that sites tend not to do
it. However, some large sites have chosen to frequently rotate the paths of
their ads resources to make it hard for URL-based blockers to keep up.
A first party could also inline ad-related resources into
the page itself. Any necessary scripts and styles can be placed at the bottom of
the page, and images can either be compiled into the scripts or included with
data: URLs. This requires every page of the site to be served dynamically and
loses any possible caching benefits from sharing ad resources between pages.
What about non-ad uses of ad blockers?
It turns out that ad blockers are also used to block other intrusive things,
like trackers (including social widgets), big downloads like fonts,
fingerprinting scripts, and cryptocurrency miners. Trackers and cryptocurrency
miners have to make a network request off the first-party origin in order to
send their results, and the URL of that request has to be similarly stable to an
ad auction, so ad blockers can block it.
Fingerprinting scripts, on the other hand, only need to report their result to
the surrounding page, and some of them provide npm
packages for trivial use in
website bundlers (like webpack,
Rollup, or Parcel).
The fingerprinting script can even be bundled with some of the site’s shared
code to ensure that it can be cached within the site while ensuring that
blocking it will break the site. Ad blockers will only manage to block a
fingerprinting script whose host isn’t trying to avoid the
blocker.
Issue #551 claims that Web
Bundles make it easier to avoid ad blockers, so how might they do that?
Uses that need an online
endpoint will still need one
whether or not they’re bundling their code. Ad blockers should continue to
target that endpoint. The considerations that make it difficult to move that
endpoint around outside a bundle also make it difficult to move it around using
bundles.
Uses that only need to get a script to run are already defended by existing
Javascript compilers: if a publisher doesn’t care
enough about defeating ad blockers to run a
compiler, there’s no reason to think they’ll care enough to build a web bundle
either.
Bundles provide another way to inline first-party ads, with the
improvement of not needing to use data: URLs for images. They come with the
same downsides around needing to serve every page dynamically and losing the
caching benefits of sharing ad-related resources between pages.
Web
Bluetooth is a developing JavaScript API to allow websites to
communicate with Bluetooth
devices. Sites ask the browser to show a list of nearby Bluetooth devices matching certain
criteria, and the user either picks
which to grant access to
or cancels the dialog.
The user can choose which heart rate monitor
to grant access to, if any.
As you might expect, there are security risks here. When deciding whether to
ship the new API, we should look at several kinds of attackers and defenders:
An abusive software developer, trying to do embarrassing or
privacy-insensitive things that don’t go outside devices’ security models.
A malicious software developer, trying to exploit users using nearby Bluetooth
devices.
A malicious hardware manufacturer, trying to exploit users or websites who
connect to their devices.
A malicious manufacturer/developer, who can push cooperating hardware and
software.
Weakly-written device firmware, which doesn’t intend to hurt its users, but
might be vulnerable to malicious connections.
Weakly-written kernels, which might be vulnerable to either malicious userland
software or malicious connections.
The ultimate decision about whether to ship Web Bluetooth should also take the
competitiveness of the web into account, but this article only analyzes the
security tradeoffs.
Abusive websites might try to do embarrassing things like configure a Bluetooth
speaker to play porn sounds. Web Bluetooth defends against this in several ways:
The chooser grants a website access to only the specific devices a user
selects, which helps the user associate misbehavior with specific sites and
prevents those sites from messing with extra devices.
On desktop platforms we show a tab indicator while a site is connected to a
device, which also helps associate the site with the misbehaving device. This
isn’t perfect, since the site might configure a device to only misbehave
later, long after the site has disconnected to stop showing the tab indicator.
If users notice misbehavior and revoke a site’s access to a device, we’re
looking into ways to aggregate that in a privacy-preserving way and use it to
protect other users from that site, either by automatically denying the
chooser or by adding an extra warning that the site might be abusive.
Malicious software developers
In a world with Web Bluetooth, malicious developers will be able to choose
between attacking users via native or web apps. We want shipping Web Bluetooth
to make their job harder across the combination of both targets.
Getting permission
Assume the user visits the malicious developer’s website. To grant it permission
to attack Bluetooth devices, the user must:
Click the vulnerable device inside a dialog that mentions pairing.
Click ‘Pair’.
Web Bluetooth provides more warning to users than Android or iOS before giving
access to the first device. Web Bluetooth also requires the same permission
sequence for each additional device, so the malicious developer can’t attack
devices the user wasn’t aware of.
Getting permission illicitly
A developer can also hijack a trusted site’s permission to use Bluetooth
devices.
Native: XcodeGhost demonstrates
that it’s possible to compromise native apps at scale, but to do it you need
to compromise development machines.
Web: Web sites are
often compromised
to host malware. Even without being compromised, web sites embed ads that
shouldn’t be able to access Bluetooth devices. To make sure ads only get
access to expected capabilities, Chris
Palmer is proposing a
permission delegation API,
which Web Bluetooth will use.
Web Bluetooth is probably more vulnerable to this type of attack.
Attacking the kernel through Bluetooth APIs
The kernel or Bluetooth drivers may be vulnerable to attack from the local
machine, or from a remote radio as discussed below. The main defense we have
here is to keep the API surface small and to run fuzz tests over that API. Web
Bluetooth is helped by the GATT API being relatively small.
Attacking through non-Bluetooth channels
A user who wants to access a Bluetooth device will follow instructions for how
to do so. This may allow other attacks:
Native apps find it easier to escape the system sandbox than web apps, at
least because web apps have to escape a browser sandbox before even attempting
to attack the system.
Native apps have more abilities by default than web apps. For example, native
apps have raw network access, can execute in the background, and can track
users through a persistent advertising ID.
Android M+ requires the user grant access to their location in order for an
app to communicate over Bluetooth.
If we ship Web Bluetooth, users can get used to simple uses working on the web,
which will help restrict the more dangerous native apps to the cases they’re
actually needed.
Avoiding blockage
Before a site or app is discovered to be malicious:
Native: App stores have full access to an app’s code and can test it for malicious behavior on
hardware they pick. However, because each kind of remote Bluetooth device may speak a different
protocol and have different vulnerabilities, the stores basically can’t test for malice and have
to allow any messages they don’t know to be harmful.
Web: We can’t do an offline scan of a website, but app stores aren’t benefitting from offline
scans in this case anyway. We can block the known-harmful messages using an updatable registry of blacklisted
services.
After a
site or app is discovered to be malicious:
Native: Stores can take down all apps uploaded under a single credit card.
Web: Safe
Browsing can block access to the single malicious
website.
Web
Bluetooth should be just as good at preventing attacks ahead of time, but doesn’t have as strong a
response after we discover an attack.
Attacking the device
Native: The app has access to both GATT and Bluetooth Classic profiles. Classic profiles are
byte-stream-based, which makes them harder to parse and more likely to be exploitable. As
mentioned above, native apps can also attack all devices in radio range, the entire time they’re
installed, without going back through a user prompt.
Web: Sites can only communicate over the relatively simple GATT protocol, which maps keys to
bounded-length values. Sites can also only attack devices the user explicitly granted access to.
Web
Bluetooth does not take the extra CORS-like step of asking devices to opt into the origins that are
allowed to communicate with them, but is still less likely to give access to exploitable device
code.
Some
Bluetooth devices intentionally allow firmware updates over a GATT channel. For example, Nordic
Semiconductor has defined a Device Firmware Update
service
with a default
implementation in their SDK. Unfortunately this implementation doesn’t check the update’s signature,
which could enable an attack along the lines of the
iSeeYou attack on USB.
As a result, Web Bluetooth will
probably add this service to the
blacklist, and restrict unsigned
updates to native apps. Firmware update services that do check signatures would not need to be
blacklisted.
Malicious hardware manufacturers
Websites
that don’t know about Web Bluetooth aren’t affected by its existence, because they have to make an
explicit function call to opt into
it.
Because
users get to choose the device they connect to a website, websites have to design around being given
an incorrect device. They may still make incorrect and exploitable assumptions about how the device
will respond to their messages. That said, this only affects the single exploited website: browser
sandboxing prevents the damage from leaking to other sites.
Malicious
hardware may also be able to work alone to attack a user’s computer, as described in the next
section.
Malicious hardware manufacturers who also write websites
Remote
devices can also attempt to exploit a user’s computer. The most well-known example of this is
innocent-looking USB devices that behave as keyboards or mice when plugged in. I’m told that neither
apps nor browsers can pair with Bluetooth devices in a way that makes the devices into trusted
keyboards, but I haven’t seen a reliable published source saying this.
Devices
may also be able to attack a user’s kernel, possibly through their Bluetooth drivers. We haven’t yet
fuzz-tested this attack surface, but we plan to before shipping the API.
The Physical Web makes it easier for malicious hardware to get
users onto their website, than it would be
to get them to install a native app. Web Bluetooth needs to validate that remote hardware can’t
attack users’ systems through this route.
Conclusion
Web Bluetooth’s ability to pair an application with a single remote device is
a big advance toward the principle of least privilege.
Reducing the number of native apps users need to install is another big advance given the general
power of native apps.
Some users’ devices probably will be exploited by malicious websites using Web Bluetooth. We
believe the other security benefits will outweigh this.
We need to run several more security tests before shipping the API, including fuzzing several
operating systems and testing that they don’t automatically grant access for devices to act as
keyboards.
Add a Sub-Account so that the password you enter on the phone isn’t your main
account password. Most fields can stay at their defaults, but
icon next to the phone number you just bought. Set the Voicemail associated
with DID to the voicemail mailbox you set up above, and define a Port Out PIN
protection PIN.