Re: Welcome / introductions

Thanks, Mark!

I'm Cory Doctorow, a special advisor to the Electronic Frontier Foundation (I was formerly its EU Director), and I hold an honourary doctorate in CS at the Open University, where I'm also a visiting professor of CS.

I've been doing various kinds of standardization work - mostly in very adversarial modes, where standards bodies were pursuing DRM standards - for 20 years, at the MPAA's Copy Protection Technical Working Group, the Broadcast Protection Discussion Group, OASIS, the W3C and the Digital Video Broadcasters group.

Decades of fighting against DRM have gradually given way to a half-decade of fighting *for* interop, both formal, standards-defined interop, whether or not it is mandated, as well as reverse-engineering driven "adversarial interoperability" (which we at EFF call "competitive compatibility" or comcom):

https://www.eff.org/deeplinks/2019/10/adversarial-interoperability

I'm very interested in the relationship between comcom and mandates, which I see as complimentary from a security/design perspective. Mandates can be subverted by firms that perceive a benefit to doing so, and enforcement action can be slow and indecisive. Comcom acts as a kind of automatic stabilizer, by changing the risk calculus of dominant firms that act in bad faith - they don't just risk an eventual fine from a regulator, but rather, an immediate outbreak of technological guerrilla warfare where they operate at a disadvantage, because aggressive acts undertaken to block comcom will also implicate their own users, causing loss of revenue and reputational harms.

In the best of all worlds, this would stay the hands of decision-makers who would otherwise defect from mandate-compliance. But even if it doesn't, comcom offers a short-term remedy to firms that are harmed by bad-faith technical changes that break compatibility.

A good example: in 2012, a Massachusetts ballot initiative requires auto-makers to supply the information needed for independent mechanics to interpret the diagnostic messages on cars' wired CAN buses. The auto-makers responded by retooling, so that the majority of diagnostic messages traveled on the cars' wireless networks, which are excluded from the 2012 rule.

In 2020, Mass voters returned to the poll and passed a new ballot initiative that amended the 2012 rule to include wireless networks.

But in the intervening eight years, independent mechanics were increasingly sidelined because the pool of cars they couldn't service expanded with each passing year. Many exited the field or went to work for the big automakers' service divisions. The corrective - eight years in coming - does not remediate the damage done by malicious noncompliance, because you can't get your car fixed at an independent mechanic if the independent mechanic has gone out of business.

A dominant firm could amass a pool of malicious noncompliance measures - comparable to hoarding 0-days, but for regulation - and deploy them in series, so that independent mechanics are starved of market oxygen and demoralized, and investors are spooked, making interoperability mandates irrelevant because there will eventually be no one to interoperate with.

But when comcom is added to the mix, the game-theoretical equilibrium shifts in favor of competition and the public's right to choice and self-determination. If Massachusetts technologists could produce their own, unofficial, reverse-engineering-based diagnostic tools without fear of liability under patent, anti-circumvention/copyright, cybersecurity, and tortious interference theories, then they could offer a corrective straightaway (reverse-engineering the wireless diagnostic messages is a solved problem in the wild, but no one starts a business supplying tools to do this because of this liability).

So if a couple of smart MIT kids were able to market a $50, comcom-based diagnostic tool with a bill of materials that comes in at $3, they could keep the independent mechanics in business and even build out ancillary services that pose a large, unquantifiable, chaotic risk to the big automakers' business plans, such as providing a conduit for third-party spares, third-party warranties, etc.

The threat of this alone might be sufficient to stay the hands of decision-makers at the big auto companies, but if not, then mechanics would not have to exit the field while they waited for regulatory relief. Meanwhile, the big auto companies' technical countermeasures are limited by their size - if they change their tooling to block comcom-based diagnostics, they also have to retool a much larger pool of official service depots and licensed mechanics, who will (rightly) blame management for introducing technological chaos into their operational planning.

I think this story - and its hypothetical contrafactual - is a really neat encapsulation of the way that we need to think about interop in the context of producing competition in concentrated markets, encapsulating commercial considerations, coordinated technical work, administratibility in light of policy makers' capabilities and constraints, and peripheral, uncoordinated technical work by reverse-engineers.

It's similar to how security engineers need to think about security economics, human psychology, legal regimes, audits, and so on, as well as the mathematics of cryptography, if they are to produce a secure system.

Let's see, what else?

I'm based in Los Angeles, though I'm a Canadian-British citizen. I write science fiction novels and stories - more than 20 books, including several NYT and international bestsellers - and sometimes, these overlap with my work on DRM and interop:

https://arstechnica.com/gaming/2020/01/unauthorized-bread-a-near-future-tale-of-refugees-and-sinister-iot-appliances/

I also wrote a short book in 2020 about competition, interop, and the rise of conspiratorial thinking:

https://onezero.medium.com/how-to-destroy-surveillance-capitalism-8135e6744d59

I'm really looking forward to this group's discussions!

Cory

On 11/23/21 21:49, Mark Nottingham wrote:
> Hello everyone. Welcome to the Community Group!
> 
> We're just getting started, so please excuse the quiet while we wait for people to join and allow the Americans their holiday. I'm aiming to hold an online meeting before the end of the year, so that we can start discussing how the group will function and what we want to focus on first.
> 
> However, it'd first be good to get to know each other.  Please send an e-mail introducing yourself, including:
> 
> * A brief summary of your background
> * Why you're participating in this group
> * Where you call home (so we can try to schedule meetings when it's not *too* painful for anyone)
> 
> I'll start below.
> 
> ---
> 
> My name is Mark Nottingham, and I'm one of the folks who supported formation of this Community Group and coordinated drafting of the charter.
> 
> I've worked in Internet and Web standards for more than 20 years, having chaired a few different groups (including HTTP and QUIC), authoring many RFCs (including the most recent revision of HTTP), and also being a member of the W3C Technical Architecture Group and Internet Architecture Board.  I currently work for Fastly, a US-based Content Delivery Network, and I'm also working on a Graduate Diploma in Communications Law at Melbourne Law School.
> 
> I'm excited about combining architecturally sound, open specifications with the potential for a legal mandate from regulators -- while there are many risks, there are also opportunities to improve the Internet in ways that haven't been possible to date.
> 
> I'm located in Melbourne, Australia.
> 
> Cheers,
> 
> 
> P.S. If you haven't seen the group home page, please take a look at: https://interop-remedies-cg.github.io
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> .
>

Received on Wednesday, 24 November 2021 22:25:27 UTC