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

What should such a one-pager consist of? I'm not sure we should support the
view of "standardization can slow down innovation"

śr., 9 lut 2022 o 18:09 Cory Doctorow <cory@eff.org> napisał(a):

> Thanks, Chris!
>
> In terms of output, I think we could write a short public position
> advocating that interop mandates be structured as safe harbors on the lines
> I lay out, possibly with some brief argument. A one-pager like that could
> be easily referenced in policy debates, both to influence the actual
> contours of any mandate, and to address both good-faith and bad-faith
> concerns about the impact of mandates on flexibility and innovation.
>
> Cory
>
> On 2/9/22 08:59, Chris Riley wrote:
> > 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/ <
> 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 <mailto:
> 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
> >
>
>