Re: [Add] [EXTERNAL] Re: Browser Administrative Authority

["Deen, Glenn (NBCUniversal)" <[e-mail]>]

Hi Stephen,

> On May 25, 2019, at 4:42 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Some) VPNs don't match that history. There are probably other
> examples but those never caused such debate

I think one important difference with VPNs is that the device admin likely chose to install them since many of them require admin authority to install.  In most cases, the user or admin also had to choose to configure and turn them on.  So it would be working within the classic administrative hierarchy.

I suspect, that many would be very upset, If there was a situation where an application developer decided on their own to quietly install a user space VPN and then route all the app’s traffic through VPN endpoints also chosen by developer without first getting the users or administrators agreement and full awareness.   

Further, if the app and it’s VPN resulted in a variety of other things breaking that were important to the user, such as security and machine configuration, I suspect the application would soon be the subject of massive debate. 

Hence the debate this is causing.

To be clear, my analysis was not in any way expressing a concern for the DoH protocol.  It was to highlight that the proposed application level changes were violating a well established security and device management architecture and with that choice comes unintended side effects.   

We have examples of such conscious choices to bypass established hierarchies in other contexts - If a network protocol did something similar, we’d call it a layer violation.  Programmers have encapsulation violation.  

With each choice to violate architectural hierarchies, there is often a driving motivation to get something done; For those of us who have crossed the line and done such things, the lesson of needing to properly and fully deal with unintended side effects is something I for one have come to learn and respect.

I am also worried about the notion that we need just push it through, or that we can’t wait to do it right, because there is a urgent need to deploy this particular application level change in choice of DNS resolvers and protocol selection.    It worries me a for a couple reasons, not the least of which is it means that time won’t be taken for studying the possible side effects and dealing with them properly.

We’ve already identified the unintended side effect of breaking filters for child protection and things like malware sites.  

There are and will be others.

Going back to VPN example at the start of this note. There is likely unintended side effects with VPNs as they often depend on DNS configurations and resolver choices in order to work seamlessly.  Certainly secure corporate environments often rely of split DNS for their VPNs.  Having a browser level DNS that resolves address differently than the VPN expects may cause a lot of unexpected and hard to diagnose behavior for the users.

Identifying, understanding, and dealing with unintended side effects seems like an important consideration for something this impactful.

This is not simply a case of let’s be perfect before doing anything.  It is very much a case of wanting to avoid major disruption for users that we should have seen coming if we took the time needed. 



FWIW - My suggestion of an OS or device level means for managing and respecting the administrators choice to follow doesn’t necessarily depend on the OS manufacturer to accept changes.  Most OSs have the means to have application level settings that require device administrator privilege to be set and managed.  

Regards,
Glenn