Re: [Add] Browser Administrative Authority

[Tommy Jensen <[e-mail]>]

Good point. I made a leap by connecting network admin with device admin for a simple reason: today, most platforms do trust their network via their default setting of using the DNS servers recommended by the network. Whether that's ideal is another topic.

To eliminate network trust as a variable in this discussion, let's have the story be the use of a DNS provider, say CleanBrowsing for example. In this scenario, the parent as the device admin has manually changed the device's DNS server settings to point to CleanBrowsing. However, the use of an app which rolls its own DNS stack by default will bypass this configuration. Device authority has been sidestepped in a way the user is not likely to understand.

I agree with your point that device administration is the appropriate answer. Apps should defer to (or proactively refer to if they want to suggest changes) device configuration rather than the device needing to be aware of the nuances of each app it could be running.

Thanks,
Tommy
________________________________
From: Tom Ritter <[e-mail]>
Sent: Friday, May 24, 2019 12:23 PM
To: Tommy Jensen
Cc: Cook, Neil; Adam Roach; [e-mail]; Deen, Glenn (NBCUniversal)
Subject: Re: [Add] Browser Administrative Authority

"imagine a parent who configures content controls through their ISP"

Okay; but then this isn't a device administrator. This is a network
administrator. (And whether it's enterprise or not isn't really
relevant, no feature is restricted to enterprise use.)

The network should be considered hostile until configured otherwise
because... the network usually is hostile. Or at least it's untrusted.
Every cellular connection; every coffee shop, every store's free wifi,
every friend's network you connect to, every AirBnB wireless, every
hotel... Percentage-wise, the number of untrusted networks the average
user connects to dwarfs the number of trusted networks (even if the
percentage of time spent on untrusted networks is dwarfed by the
percentage spent on trusted networks.)

Device administration is the appropriate answer here - it's the
appropriate trust boundary for users. An administrator of a device is
a person or organization the user of that device knows and understands
controls it. For the network to be able to override and disable users'
security and privacy controls is inappropriate - for example we don't
allow networks to strip TLS. UNLESS, of course, the device is
configured to allow such activity.

-tom

On Fri, 24 May 2019 at 17:53, Tommy Jensen
<Jensen.Thomas=[e-mail]> wrote:
>
> Glenn, that was a great write-up. Thanks for sharing.
>
> To highlight Neil's point about this not being enterprise only: imagine a parent who configures content controls through their ISP. In a world where the browser defaults the user into using the browser's own DNS (DoH or otherwise) while bypassing system policies, children have a no effort needed sidestep to parental controls and it won't be immediately obvious to the parent why their controls don't work.
>
> I don't think asking the platform and other apps on the platform to all be aware of one another's policies is scalable. For the same reasons Glenn gave, I think apps should defer to the platform, redirecting users to make changes there rather than making changes within their own space.
>
> Thanks,
> Tommy
>
> ________________________________
> From: Add <[e-mail]> on behalf of Cook, Neil <neil.cook=[e-mail]>
> Sent: Friday, May 24, 2019 9:56 AM
> To: Adam Roach
> Cc: [e-mail]; Deen, Glenn (NBCUniversal)
> Subject: Re: [Add] Browser Administrative Authority
>
> Glenn’s point is not just about enterprises. It applies to consumer use cases as well.
>
> Neil
>
> Sent from my iPhone
>
> On 24 May 2019, at 16:58, Adam Roach <[e-mail]> wrote:
>
> This is called “enterprise policy”, and — as far as I know — all major browsers honor it.
>
> See, e.g., https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fproducts%2Ffirefox-enterprise%2Fpolicies-customization-enterprise%2Fpolicies-overview-enterprise&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=Qx5XXn2n77kMw9TscJ5Fxexlnju92%2BQtUad%2FqEXU500%3D&amp;reserved=0
>
> /a
>
> On May 24, 2019, at 09:48, Deen, Glenn (NBCUniversal) <[e-mail]> wrote:
>
> HI everyone,
>
>
>
> I’ve been thinking though some of the issues with the proposal DoH deployment in browsers.
>
>
>
> A big part of the tug of war here is  the authority precedence for advanced security and network settings that should be followed.
>
>
>
> Historically, it’s been at the device level – which meant the device administrator, which could choose delegate choices to a specific DNS resolver operator, or to the Network DHCP provided settings.
>
>
>
> Now the browser is seeking to adding itself into the authority chain for those settings. The trouble being that this is a major change to the administrative trust model.
>
>
>
> To date, browser settings have been limited to rendering options, some basic certificate options, addons, and scripting language choices.    Advance security and trust has remained with the device administrator.     Adding the browser to the administrative chain so that it can control advanced security and network settings introduces a problem because the browser does not have an administrative level authority that is as high as the device administrator.
>
>
>
> Current hierarchy (top has more authority)
>
>
>
>               Device Administrator       -- device authority for security, network, trust settings
>
>               Network Administrator     -- provides recommend network settings to devices
>
>               Resolver Administrator    -- can provide filtering
>
>               Browser  Maker               -- provides core trusted certificate list
>
>               Browser User                  -- can set rendering options, can make limited certificate choices, plugins.  – Impact is limited to the browser sandbox
>
>
>
>
>
> The problem is that some of the browser makers proposals are now changing this administrative authority hierarchy, but they haven’t done the extra work of establishing administrative trust and working through the consequences of that such as a child being able to change the browser DNS settings and bypass both resolver, Network, and even OS based restrictions.
>
>
>
> So they are changing it to:
>
>
>
>               Browser Maker                -- provides default DNS resolver and DNS Protocol choices.
>
>               Browser User                  -- can set DNS resolver and DNS protocol
>
>               Device Administrator       -- device authority for security, network, trust settings
>
>               Network Administrator     -- provides recommend network settings to devices
>
>               Resolver Administrator    -- can provide filtering
>
>
>
>
>
>
>
> The path to fixing this maybe to see if there is a way to express the administrative hierarchy that respects the intentions of the device administrator on what hierarchy they want to accept/delegate decisions to.
>
>
>
> It maybe that what’s needed is a means to communicate to the browser what authority the device administrator wants it to follow, since in the end the device owner should be in charge.
>
>
>
>
>
> -glenn
>
>
>
> --
> Add mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0
>
> --
> Add mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0
>
> --
> Add mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cac269940328c4cf2713708d6e07d59f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636943226330979994&amp;sdata=wbq0RiqgNQODZ%2FY%2BCX6Ie1iYjbG4uw5iRHQ7glreOIk%3D&amp;reserved=0