Remote attestations and dangerous protocols
Concerns around remote attestations vs. the protocols that use them with Web Environment Integrity as a case study
In their vision for the web, Mozilla highlights openness as one of their key values for the web and describes the properties that enable it.
One key property that enables this is interoperability based on common standards; any endpoint which conforms to these standards is automatically part of the Web, and the standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web.
In theory, the web, as an open network, should be agnostic to how any individual endpoint is implemented. As long as an endpoint (the user or in most cases a browser serving as a user agent) in the network follows the rules outlined in Internet standards like HTTP, it is supposed to be a part of the network with the same access rights as any other endpoint regardless of where the endpoint is and the hardware and/or software used to run the endpoint. A major benefit of endpoint implementation agnosticism within a network is that endpoints can be upgraded or modified to enhance user experience independent of the rest of the network. For the web, examples of enhancements include localization, ad blocking and flexibility in choice of device to access the web.
In practice though, the web, has long since veered away from this pure form of openness. The description of openness in Mozilla's vision is best thought of as a platonic ideal - when considering openness as a property, it is less useful to ask whether a system is open or closed and more useful to ask where a system falls on a continuous spectrum between open and closed. In the case of the web, many aspects of the network are still open (anyone can spin up their own server and communicate with many other servers), but as a whole the network has also been nudged in the closed direction with cross-jurisdictional differences in Internet service regulation in areas like data localization and content licensing (i.e. major streaming platforms adjusting content catalogue based on viewer location) forcing endpoint implementation details to come under greater scrutiny and restrictions.
The ideal of openness and where the web actually sits on the open vs. closed spectrum when confronted with a reality of incentives and tradeoffs will be useful to keep in mind when considering another technology with growing adoption and that also poses questions for the openness of the web: remote attestations.
What are remote attestations?
A remote attestation is a digital assertion about the hardware and/or software used to handle data that can be cryptographically verified to originate from a trusted, physically isolated area of a device. These types of attestations are a core part of confidential computing, a set of techniques for protecting "data in use" meaning that data can remain private and protected from tampering even while it is being used in computation. These properties are enabled by a "trusted execution environment" (TEE), a physically isolated area of a device that handles protected code and data - theoretically not even a device owner should be able to access or modify data in this area. The details about the hardware and software running on a device can be collected by the TEE and served in a remote attestation as supporting evidence for a verifying third party that only specific computation was run on specific data without unauthorized access or modifications.
Examples of systems with remote attestation capabilities actively being developed today include:
Trusted Platform Module (TPM) enabled devices
Intel SGX enabled devices
Nvidia Confidential Computing on H100 GPUs
The web also supports the use of remote attestation via the integration of Webauthn APIs for attestation in major browsers that expose a set of supported attestation formats (each device has its own attestation format) to developers generating on-device keys for their users.
The use cases for remote attestation typically revolve around building trust whether that be in the computing environments used for shared confidential data (i.e. health, financial, etc.), in the security of AI model weights and sensitive inference input data, in the privacy guarantees of contact discovery in a messaging app or in the hardware/software provenance of content. In all use cases, there is some party (the "relying party" in technical terms) that will only trust the system if there is evidence via a remote attestation that specific computation was run on specific data without unauthorized access or modifications.
In isolation, remote attestation appears to just be a useful feature for security assurance that code and data is being used as expected without tampering by a bad actor. However, in the context of a network, remote attestations can also be used as verifiable proofs of network endpoint implementation details - a verifying third party can then use these proofs to adjust their own behavior in the network according to the hardware and/or software powering an endpoint. As we'll see in the next section, a network where the default behavior is for endpoints to expose this information stands in stark juxtaposition to Mozilla's vision for an open web that is agnostic to how endpoints are implemented.
Web Environment Integrity
Web Environment Integrity (WEI) was a proposal put forward by Google last year for a browser API that would allow developers to automatically request remote attestations (technically the design allowed for a variety of different attestation policies, but for this post we'll focus on remote attestations) from a browser. The proposal has since been abandoned after receiving a significant amount of criticism from other browsers, organizations and communities.
The bulk of the criticism centered around how the proposal, if implemented, would shift power away from users and to websites that could discriminate against users based on the hardware and/or software they use to access the web - a notable example that many feared was ad powered websites blocking browsers using ad blockers. While the proposal highlighted valid reasons for surfacing details about the browser and the device it is running on to websites (i.e. defenses for ad fraud, game cheating, bots), the proposed solution, if deployed in Chrome which has > 50% of browser market share, was likely to not just nudge, but propel the web in the closed direction given how much power the browser API would give website developers to acquire endpoint implementation details.
At the same time, despite remote attestation playing a key role in the design of WEI, it is not clear that remote attestation itself should be to blame as the root of WEI's problems. The problems with WEI seem to have stemmed not from the mere fact that it used remote attestations, but from the dangerous protocol that would have emerged from how it used remote attestations.
Dangerous protocols
Nadia Asparouhova describes protocols as procedural systems of social control that simplify communication between actors and how they can be "dangerous" because participants are tempted to implicitly trade their own agency for the simplification in communication that the protocols enable. Initially, individuals opt-in to participation and the rules are enforced by a combination of infrastructure, authorities and social norms. The individuals benefit from participation because they don't have to worry about how to communicate with others and have less decisions to make - they can just automatically follow the protocol. But, if they continuously trade their own autonomy for simplification of communication, the eventual end state is that participants are not even aware of their participation in a protocol - while they might view their behavior as driven by personal choice, in reality their behavior is controlled by an implicit protocol that guides their actions with an invisible hand. And this equilibrium of behavior may or may not be in the best interest of the individual.
With this in mind, we can consider WEI as a protocol for simplifying the communication between a user and websites for requesting remote attestations about the user's hardware/software environment used to access the web. The rules of the protocol would have been enforced by the browser API that allows developers to easily request and receive responses for attestations. Without the protocol, websites in theory could still ask users for remote attestations (a strawman approach: run a separate tool to generate a remote attestation on your device and paste a bunch of data into a text box), but this would likely to be a very manual and clunky process that would be bad for both users and websites.
By using a browser that follows the protocol, the user would not need to worry about how attestations are generated and provided to a website because the browser API streamlines the process with code. By following the protocol, the website can avoid exposing users to separate workflows when asking for attestations and instead fetch an attestation with a single API call. From a communication overhead point of view, the simplification here can be very attractive for both participants!
However, the simplicity comes at a cost - by reducing the cost of communicating remote attestations between users and websites, the protocol also increases the overall volume of remote attestations transmitted to websites and thereby increases the allure of requiring that information on a go forward basis as pointed out by Eric Rescorla (in the context of Apple's Private Access Tokens which has similarities to WEI).
The reason to think about WEI and systems like it in the context of the dangerous protocols they can enable in an open network is that once a network reaches a certain equilibrium of behavior it can be difficult to break out of that equilibrium even if participants can technically choose to behave differently (i.e. a user choosing to use a different browser). In a world where it is burdensome to exchange remote attestations between a user and a website, there will be too few instances where that information is accessible for a website to require it. In a world where accessing remote attestations is as simple as an API call for a website, the instances where the information is available can be so numerous that websites face less risk for requiring it even if a subset of users opt-out.
The most useful takeaway from the failure of WEI is not that remote attestations should be treated as radioactive, but that it is important to consider the cost of communicating remote attestations, and whether it should be higher or lower depending on the context you are operating in, as inputs into whether or not to design a protocol around remote attestations for any network.