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

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

Howdy,  inline..

> On May 25, 2019, at 7:40 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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.

The difference is in the administrative level needed to make changes, and how that fits with the administrators and user’s expectations, as well as expectations of working with the understood administrative model of authority.

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

Certainly, the scale of users affected here is raising the level of attention and impact. 

Some minor VPN not working isn’t really going to affect many users or cause much disruption.  But at scale it makes a lot of users unhappy, and can also cost organizations a lot of money due to support calls and problems.
> 
>> 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;-)

Sorry, my use of the word “violate” was chosen because it’s the term of art for when  protocol layers and data encapsulation in objects is bypassed or not observed.     It was not in anyway meant to irritate.

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

I was responding to your original notes assertions that I read to be about not getting stuck in a perpetual debate in search of perfection.  (Because the ietf never does that!) 

My understanding was that this list was being used to additionally discuss and explore the impacts and consequences of proposed DoH architectural deployment choices.  

So what I was saying is that I hope the community of internet and web architects and those who build the applications and systems take the time to get the proposed deployments right because the scale of the impact of the choice of deployment approach is very very large here and it will amplify any unintended side effects.

-Glenn