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

[Stephen Farrell <[e-mail]>]

Hiya,

Coupla comments and a question at the end...

On 25/05/2019 15:08, Deen, Glenn (NBCUniversal) wrote:
> 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.. 

Browser installs also do; or if shipped with the device then
the device vendor made that choice so I see zero difference
there.

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

Gotta say I don't agree that the above's that valid. Minor
VPN products misbehave all the time in way worse ways and
don't cause this level of debate. I think we ought be clear
that the volume or traffic and number of users involved is
why we're getting this level of debate, not architectural
(im)purity.

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

Sure.

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

Using terms like "violate" is likely to irritate those in
favour of applications making these choices, just like
network operators get irritated when folks describe the
network as being hostile. Neither term is wrong but it's
not particularly useful for us to irritate one another
either;-)

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

Push what through? DoH is done as an RFC. What other "it" do think
is needed? (That might result from this debate.)

Cheers,
S.

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