Re: [Add] Trust and control on the Internet (was Re: fixing coffee shop brokenness with DoH)

[Andrew Campling <[e-mail]>]

On Jul 24, 2019, at 4:05 PM, Ted Mellon <[e-mail]<mailto:[e-mail]> > wrote:

>  Vittorio, I think it’s important to make a distinction between “who you might choose to trust” and “who you are forced to trust.”

>  In order to run an app, if the app is able to make https connections, you are forced to trust the app.   This is true whether you are aware that you are trusting it or not, and regardless of your attitude toward your service provider.

Whilst not disputing the logic of being forced to trust the app, experience tells us that we are unwise to do so as there are sadly numerous instances where that trust is betrayed; I note for example the settlement today of the most recent Facebook privacy case in the US.  In a number (most?) cases where trust is betrayed, data monetisation appears to be a motivating factor and we should note that centralisation has the potential to magnify the data monetisation opportunity.

>  This is what I am getting at.   This is completely orthogonal to the question of “whose resolver would I choose to trust?”

>  What DoH does, but what any app can do whether DoH is present or not, is to make it possible to trust someone other than your service provider.  Without some covert channel that the service provider can’t block, the user does not have this choice.

The second sentence in this paragraph is incorrect – there are mechanisms that can provide the user with choice of DNS resolution without being covert, albeit also allowing the service provider to block the mechanism should it choose to do so.

>  But really, the user doesn’t have this choice anyway.   It’s the app that has this choice.   The user may hope that the app does what the user wants, but the user probably can’t validate that leap of faith.

>  We in the IETF do not have the ability to prevent the app from bypassing the ISP’s resolver.   It’s totally pointless to talk about whether or not we should do this.

Whilst the IETF might not have the ability to prevent abuses, I believe that it ought to avoid providing a standardised way of enabling these abuses if at all possible and, as a minimum, should ensure that it also provides mechanisms to allow the user (specifically the device administrator) to express their preferences and communicate those preferences to apps.  Published best practice should be that those preferences are respected by apps in all circumstances except where relevant regulations/legislation makes this impossible to do so legally.


Andrew