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

Makes sense!

But then, we sign this as who?

 +Justify that omitting the standardisation part may result in fragmented
chunks of technologies, which is not a good idea (suboptimal for sure, and
not good for security/privacy). Actually at least in Europe, standardising
first" was a big part of 2G's success.

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

> 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
> >      >
> >
>