Social Protocols: Enabling Sophisticated Commerce on the Web. Technical and Legal
Audience: Students of HLS and MIT 6.805: Ethics and Law on the Electronic Frontier
Goal: With social protocols introduced, go into technical and legal
design principles and rules of thumb. I have not yet enunciated enough principles, but I
outline some of the issues.
5 Key Points
Engineering under Policy Constraints
Good engineering requires flexibility, layering and modularity
- Requirements may differ across technical constituencies and time.
- When engineering becomes closely coupled to a specific policy, the technology is seen as
- When contentious policy issues are embedded in the engineering process, there is more
policy debate than engineering.
- By supporting a range of policy options one decouples policy debates from engineering.
Web Technology and Policy
Developing web technology in the policy domain is hard
Relationship between Technology and Policy (1/2)
Some technologies are intrinsically limited to serving certain policies effectively.
- Nuclear bombs are poor at improving air quality.
Other technologies can effectively serve multiple policies.
- Guns can be used to effectively "hunt" or "shoot the enemy."
Relationship between Technology and Policy (2/2)
A useful pair of strategies for technologists is to
- find the right "layer" for addressing policy issues and
- delimit the range of options which they will support.
- TCP/IP is merely a communications protocol that cares nothing for what is said or who
said it. (L18)
- PICS allows anyone to comment on a Web resource.
Enabling Multiple Policies (1/2)
In social protocol design one needs to understand the greater context:
- The critical issues.
- The range of policies.
- The stakeholders and their views.
Note, the examination itself may be questioned since it make shed light on power
previously exercised privately. (Much of Internet policy has been set this way -- to good
effect -- by an Internet old boy network.)
Enabling Multiple Policy (2/2)
Supporting multiple policies can be contentious:
- Some policies may not be supported.
- Some supported policies may be subject to criticism.
- Some people may not wish to permit a range of policy options.
The arguments of "where to draw line" and "if to draw line" are
Cases in point: PICS, JEPI, IPR
Common Regulatory Strategies
These strategies are not exclusive, rather they are often used in conjunction:
- link: couple a related issue to a contentious issue. (Clipper 3 coupled digital
signatures (and their legitimiticy) to key escrow policies; strong confidentiality to
- choke: regulate those that are easy to go after. (CDA focussed on large ISPs,
and telco common carriers, rather than those creating the content.)
- gouge: regulate those that have deep pockets, often used with choke.
(Some have pushed to criminalize the contributory infringement of copyright.)
- browbeat: use the bully pulpit to abash, or threaten further regulatory
"industry" doesn't self regulate, the government will get involved.)
- herd: selectively place and remove liability to channel policy towards a goal
without overtly setting the direction. ("Mandatory self regulation" and safe
harbor provisions are frequently proposed solutions to Internet content issues.)
How do the regulators propose to address the Technical Constraints of Regulation
- Location - where are the parties?
- Identity - who are the parties?
- Transactions - how to track? (size, number)
- Relationships - who to trust?
- Time - how to regulate in this rapidly changing domain?
- (an approach common to all of the following slides is to defer, study, or take a
Technical Regulatory Strategies.
- social protocols should enable end-user configuration and preference expression
- enable the emergence of self forming content, trust, and economic communities
- government may wish to extend their own concepts of community on to the Net
- design - two models of technology policy
- specifying an instance - everyone fights over what X is.
- configuring an option - the platform supports W, X, Y, and Z.
- W3C chose strategy #2 and also promoted "good" engineering design principles
to the user interface level: abstraction, modularity, and extensibility.
Technical Regulation by Specifying an Instance
Engineering principles which served the Internet well (such as decentralization) also
made it difficult for governments to regulate.
In the CDA hearings, the DoJ certainly tried strategy #1 with the argument (based on
Dr. Olsen of BYU) that IPV6 would support an adult/minor tag in each datagram, but failed.
PICS, based on principles of decentralization and user control, was seen as a better
However, now there is fear that PICS builds censorship into the Net.
Technical Regulation by Configuring an Option
I talked about social protocols over a year ago on "Internet Control" and
"A social protocol is not so much an 'Internet Control,' but a way of using
meta-data and negotiation to control the interactions one has with others on the
In the PICSRules debate, critics missed the true danger: regulations on the UI. As
you promote configuration and preference expression to the UI (good things), governments
may shift their strategy from infrastructure to UI.
- servers will not use PICSRules, but clients will -- that was the point
- easy to require a content or privacy configuration be available or activated in an
extensible configuration architecture.
Social Protocol Regulation Dilemma
Is there a way to limit protocols intended for self-emergent communities from being
co-opted by external communities?
- value exchange mechanisms: include VATs and taxes in the transaction
- trust mechanisms: require algorithms and escrow into the DSig/trust relationship
- privacy mechanisms: require EU specific configuration files
- easier when there is no relation to the external community, harder when there are
Observations on Constraints (over-generalized but useful)
- the Internet is global
- governments are realizing a significant portion of their constituents and market are
moving to cyberspace
- commerce motivates convergence; culture motivates divergence
- technologists - mechanism not policy regulators - policy not mechanism
- regulators often focus on fixed targets and choke points (ISPs and telcos)
- relying upon previous regulatory models can be misleading (print, speech, broadcast)
- often policies can motivate unintended consequences, or lead to regulatory arbitrage