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

I think it could say, "Standardization is a trade-off - you get the reliability of a predictable way to interop is a benefit, but it comes at the cost of the ability to just make stuff up that suits your idiosyncratic needs or fast-changing real-world circumstances. An API is a promise, and that promise binds you, for good and for ill. Here is a way to secure the benefits of standardization while minimizing the risks."

On 2/9/22 09:28, Lukasz Olejnik (W3C) wrote:
> 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 <mailto: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/> <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> <mailto: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
>      >
>

Received on Wednesday, 9 February 2022 17:35:42 UTC