Today, EFF published "Privacy Without Monopoly: Data Protection and Interoperability," a major new paper by Bennett Cyphers and me.
It's a paper that tries to resolve the tension between demanding that tech platforms gather, retain and mine less of our data, and the demand that platforms allow alternatives (nonprofits, co-ops, tinkerers, startups) to connect with their services.
It starts from the premise that tech companies abuse our data because they *can*: because they know we're locked into their silos, because they know we have few alternatives even if we decide to abandon our social ties and move elsewhere.
Demanding better data protection from tech companies works well, but fails badly. It's great when companies respond to public pressure or legal changes by protecting our data, but if they don't, and there isn't any alternative, well...
The upshot is that alternatives represent an important piece of the privacy puzzle: both as a force to discipline big companies tempted to abuse our data, and as an escape valve when they yield to temptation.
Interoperability is complicated. There's some legislative energy for mandating interop - last year's US ACCESS Act, the pending EU Digital Services and Markets Acts.
There's also a lot of antitrust suits around the US and the world, and companies might settle these with a requirement to open APIs. And there are other levers: government procurement rules, or requirements for participation in standards bodies.
Mandatory interoperability represents a good floor, but it's a lousy ceiling. Monopolists who are required to allow interoperability to allow alternatives might sabotage the mandate by shifting around their operations so the interop doesn't do much.
The ceiling on interop needs to be competitive compatibility (comcom, AKA "adversarial interoperability"), when a new service plugs into an existing one against its wishes, say, by scraping data on behalf of a user.
Comcom was once the norm in tech, but the same companies that owe their existence to comcom used their monopoly rents to obliterate the legal framework that permitted comcom, ensuring no one does unto them as they did unto the companies they disrupted.
Restoring comcom can come through a mix of new laws, better interpretations of existing laws, and through the same levers we might use for mandates: antitrust settlements, procurement rules, conditions of participation in standards-setting.
III. Delegatability (AKA front-end interoperability): allowing a third party to automate clicks and mouse movements to connect to your account on a service on your behalf.
Both mandates and comcom expose users to privacy risks - as does business-as-usual. If we take away companies' legal weapons so they can't use the law to block interoperators, they will lose a tool they use to protect users' privacy.
But users will gain ways to interact with social media that are more privacy-preserving than the big companies are willing to stretch to.
The answer to this isn't to count on big companies to have our best interests in heart - and to defend those interests by abusing copyright and cybersecurity law. We need a federal privacy law - one that binds both Big Tech and new rivals.
A federal privacy law would also safeguard users' privacy where there's an interop mandate in play, and because a mandate is managed and orderly, big companies can shut down APIs or limit access when someone breaks the rules.
Big Tech doesn't have a monopoly on good ideas or the ability to provide a platform for discussion, socializing, and political and civil engagement - but they *do* have a monopoly on platforms where these things take place.
One of the biggest things making Federation work right now is block lists. Yes, it can balkanize nodes into echo chambers – but it would become intolerable without the ability to block entire nodes.
The thing is, there's really no way to force the big players to not block other nodes. Nor, I think, should you. But, this does mean there will be a loophole in interoperability we can't close.
No easy fix here. Imagine the bezzles if block lists have to be 'approved' by someone…
The single biggest reason is abuse by badly behaved nodes – which can include abusing the APIs, but is obviously not limited to that and will certainly include new ways to abuse privileges not yet invented.
It's true being able to personally block a node is a pretty nice feature of Mastodon. I don't know if other Fediverse software includes that capability or if they only block individual users.
Mamot.fr est une serveur Mastodon francophone, géré par La Quadrature du Net.