Re: [arch-d] <draft-lazanski-consolidation-00>

[Vittorio Bertola <[e-mail]>]

> Il 10/11/2020 02:43 Martin Thomson <[e-mail]> ha scritto:
> 
> The draft doesn't suggest any particular course of action in response for these protocols (QUIC, TLS, DoH) in response to the implication that they drive consolidation.  If I were to infer that refusal to standardize is an option, I posit that that would have a severe deleterious effect on the playing field.  It wouldn't remove the desire to deploy such mechanisms, but it would affect the availability of technology to smaller players.

+1 to this. In fact, the (non-technical) problems do not come from having standardized a protocol, but from having failed to gather and address the non-technical requirements of all stakeholders before finalizing and deploying the standard.
 
> The document claims that DoH deployment was forced.  The claim is that this was not market forces at work.  I have to reject that thesis entirely.  While I agree with the author of RFC 8890 that the development of RFC 8484 had some issues (some of which were novel, all of which are worth learning from), the progress toward deployment seems to me to be unremarkable.  It's a deployment with a disruptive technical innovation that has a displacement effect on some incumbents, for sure, which are never painless, but it's not like Microsoft or Apple or Google or Comcast or any of the other actors who have responded are responding to force.  They are responding to market pressures.

The problem, however, is that consolidation *is* the effect of market pressures.  The global regulatory discussion around Internet platforms is indeed a discussion about rules that could prevent these market pressures from reaching a short-term optimal point which is damaging to the market itself in the long term, and that endangers fundamental rights and public policy needs.

> This is FUD, and I'm disappointed to see it repeated here:
> 
> >   By routing the DNS over HTTPS, it becomes much easier to track user
> >   activity through the use of cookies.  Therefore a protocol that was
> >   developed to enhance user privacy and security could actually
> >   undermine both: privacy through the use of cookies and security by
> >   consolidating DNS traffic onto far fewer resolver operators that are
> >   far more attractive targets for malicious actors of various types.
> 
> Yes, cookies are terrible.  Which is why no DoH implementation I'm aware of pays any attention to them.  That's a simplification, but the suggestion that client implementations don't take all reasonable steps to manage privacy risks and the trade-offs involved demonstrates a lack of understanding.

However, when you design a protocol, you should also take into consideration how it could be misused.  If you design a protocol that gives an additional possibility for user tracking to a sector of the Internet industry that in many cases has user tracking and profiling as its main source of revenues, then there will be a natural business incentive for these companies to activate the tracking sooner or later.  Of course you can rely on a pledge that they will never do so, but still, you created a new risk by design.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy