Canary domain

[dmarti]

user story: As the administrator of a sensitive network on which attribution reporting is blocked by policy, I want to minimize administrative complexity and the need to update browser configurations and enterprise policies.

user story: As a system administrator deploying a workaround for a future possible security issue involving attribution reporting, I want to be able to temporarily disable this system with a straightforward amount of effort.

Add a "canary domain" that works similarly to use-application-dns.net to manage attribution reporting. This canary domain should be checked using the system DNS, so that the decisions for DoH and attribution tracking on a network can be made separately.

[martinthomson]

Yes, administrators will want to set these sorts of policies. Though I don't think your reasons make a lot of sense, that's probably not worth debating as long as we agree that administrators will want that. After all, browsers try not to annoy the people who operate networks (not always successfully).

A canary domain is completely the wrong tool to use.

We have experience with the concept of canary domains at Mozilla, as you note. This is appropriate in that case, because the control point is at that layer of the network already. Introducing DoH is an intervention on the endpoint, such that giving network administrators that capability was considered necessary. A canary domain acts at the right control point, so it is appropriate to consider. We've seen some amount of opting out as a result of that, though the concrete rate is a lot lower than you might expect (even accounting for enterprise deployments that disable our telemetry, the rate isn't that high; sadly, that telemetry expired, so I can't give you exact numbers).

However, tinkering with DNS is not the same as a new Web API. The DNS change is something of an exceptional circumstance here. The Dolev-Yao threat model under which a lot of the network security we develop operates under says that the network resolver that might override the DNS RRs for use-application-dns.net is a network attacker (even if we might not consider them a bad actor). As such, we would ordinarily not pay any attention to that sort of signal. For name resolution using DNS though, where we are already exposed to that specific attacker to some degree, this was considered an acceptable concession.

Attribution doesn't operate at that layer and so we would not respect a request from what could be a network-based attacker under any circumstances.

The administrative tools that browsers provide (Firefox, Chrome) can be used to disable the feature, which is a more appropriate mechanism. Those depend on exercising some amount of control over endpoints, which also depend on having controls over software installation. My understanding is that networks that are considered "sensitive" critically depend on access control that is minimally conditional on some sort of endpoint control.

I will also acknowledge that some network administrators insist on snooping on the contents of all communications, using a combination of forced installation of trust anchors in end systems and TLS interception devices. This is far more invasive -- unnecessarily so -- but that could also be used to effect the same outcome.

(Edit to add:) How browsers choose to present options to device administrators is not within the domain of web standards. If a browser chooses to provide these administrative controls, that would be very sensible. We don't need to document those options, though we should discuss whether it makes sense to add some non-normative discussion of these sorts of control.

[dmarti]

I agree that TLS interception is unnecessarily intrusive, and adds attack surfaces in such a way that it puts the users of that network at much greater risk than they would have been at without it.

The person who a canary domain would help is the network administrator who wants to make the case for not buying the TLS interception solution and deploying a simpler and safer alternative.

[martinthomson]

I propose that we close this issue without action. Availability of web browser features is not something that we should hand control of to network administrators. If there is interest in pursuing discussion about device administrator control over those features -- though I still maintain that this is not something for standards -- please open a separate issue.

[dmarti]

This is not just a web browser feature, though. It's a marketing data collection system, and every network administrator with a Pi-Hole is used to being able to manage those.

The administrator expectation and responsibility is still there, even if the architecture changes. (If a browser started sending email spam by pasting into a webmail client, the email administrator would expect to be able to block it even if the browser didn't touch any of the administrator's traditional server-side email stack.)

[AramZS]

Individual browser vendors make a number of configuration features available to corporate IT administrators. Those administrators than can choose to configure these features accordingly. This can include wide varieties of features, including one like those you refer to here. This includes everything from length of use to browser-level log-in/log-out rules. Providing these controls to system administrators is at the discretion of the browser vendor. We do not, at the level, discuss that type of process in this type of group. As such, this is an off-topic thread. As Martin notes, the correct place for this would be in a support area for the browser vendors you are concerned with. I am closing it now.