Re: Safe harbo(u)rs: A structural proposal for interop

Hi Cory,

In principle I like this idea - thank you for raising it. Something broadly
similar occurred to me in reading the DMA, because it provides a mechanism
(which at the moment is, in my understanding, entirely ad hoc) for
demonstrating that a company is not a gatekeeper in practice and thus
should not be subject to the law's behavioral obligations. It feels ideal
to construct a scenario where the incentives set up a company working to
build and demonstrate sufficiently open gates.

In practice, though, I do worry about the technical counterarguments you
note, that it's easy to stonewall the implementation (I'm thinking of
Mozilla's struggles at using the Facebook ads library set up in Europe:
https://adtransparency.mozilla.org/eu/log/). But a FLOSS reference
implementation could maybe be sufficient to address that? Curious what
others think.

Because of the variability in what would need to be included in such
standards depending on the service, I'm also wondering what the most
effective output would be from us. It's a bit abstract and political rather
than technical, no? Or we could pick a specific service/technical context
and articulate more detail, and use that as an illustration for the broader
principle/policy approach. That might be best...

C

On Wed, Feb 9, 2022 at 6:14 AM Cory Doctorow <cory@eff.org> wrote:

>
> Hey folks; here's something I want to bounce off of you.
>
> Critics of the ACCESS Act and the DMA raise the legitimate issue that
> standardization can slow down innovation, and might lead to stagnation in
> service development.
>
> Both of these proposals involve something that is analogous to a formal
> standards-setting process, which means that both will have a
> requirements-setting phase, resulting in a requirements document.
>
> I think we could use these requirements to preserve the
> pro-competitive/pro-user elements of these acts by modifying the acts
> slightly.
>
> Rather than mandating that companies must adopt the standard, the acts
> could specify that dominant companies must offer an interface that
> *satisfies the requirements*.
>
> An interface that doesn't satisfy the requirements would be an offense
> under the act, and competitors and regulators would have the right to sue
> for compliance and damages.
>
> The standard that the technical committee develops would be a "safe
> harbor" - any firm that adopts it would be presumptively safe from any
> enforcement action.
>
> But when firms wanted to accomplish goals that were compatible with the
> requirements, but not the standard itself, they would be able to develop
> their own, independent APIs and use the requirements as an objective metric
> to assure themselves that they are not violating the law.
>
> As part of this obligation, any firm that offered its own API could be
> mandated to offer a FLOSS reference implementation of a library for
> interacting with it.
>
> I think that this group of technical experts could be well suited to
> advance this proposal. I think a lot of the "standardization is bad for
> innovation" critique is in bad faith and basically advances a nihilistic,
> "Nothing can be done, this is as good as it gets" position meant to create
> paralysis.
>
> But a safe harbor proposal preserves the best of all worlds -
> democratically accountable (small-S) standards for interop, a (capital-S)
> technical standard, and the flexibility to ignore the latter provided you
> don't interfere with the former.
>
> It's one of those ideas that straddles the line between tech and policy,
> in a good way, but might encounter headwinds because (e.g.) policymakers
> might not understand the distinction between requirements and standards nor
> its significance; and tech people might argue that an interoperator
> confronted with an inadequate roll-your-own standard from the likes of
> Facebook would face an insurmountable hurdle because going to court is
> impossibly hard. But orgs like EFF and FSF can and do sue over this kind of
> thing all the time, and the right penalties for noncompliance often mean
> that we don't have to.
>
> What do you all think?
>
> Cory
>
> Cory
>
>