Many observers have pointed out that TC architectures might be used by application, service and content providers to define which client applications to interoperate with. This feature could be used to create lock-ins and hinder competition in the client application markets. Recently, EFF has proposed to enable TC platform owners to send false integrity metrics to the remote application, service or content provider ("owner override"). Thereby, the remote provider could no longer base its decision whether to interoperate or not on the particular client application that is running on the local TC platform. Owner Override could prevent lock-ins and preserve competition in the software client markets. While such a proposal has interesting features, it deserves further discussion before it could be adopted:
- An owner override solution could be "under-inclusive". There might be other ways in TC architectures to create similar lock-ins. Application, service and content providers could, e.g., only interoperate with client applications that know a certain shared secret. This shared secret could be bound to a particular client application by sealed storage. There might be ways to get around this sealing, but it may be hard for the average TC user.
- An owner override solution is "over-inclusive". It limits the functionality of TC. Because remote challengers can no longer be sure whether the transmitted integrity metrics are true, TC becomes useless for DRM applications. While the EFF likes this result, I am not so sure whether that's a good thing. I am relatively critical of DRM myself, but my criticism does not go so far to ban DRM in TC altogether. In addition, this limitation of functionality does not only affect DRM, but all services that depend on a secure authentication of client applications and include malicious users in their threat model.
- I am not sure whether, in all cases, an owner override would be allowed as a matter of law. Anti-circumvention regulations such as the U.S. DMCA and the European Copyright Directive as well as criminal law statutes might outlaw an override under certain circumstances.
- There are other solutions to prevent lock-ins and market failures in TC infrastructures. In TC architectures, the potential for misuse results from the fact that service, application and content providers can base their decision whether to communicate with a particular TC platform or not on the integrity metrics which this TC platform transmits to them. To prevent misuse, owner override allows the platform owner to lie to the application, service and content providers without their knowledge. Another approach to prevent misuse would be to say that application, service and content providers may always receive true integrity metrics from TC platforms and can base their decisions on those metrics as long as their decision is based on security considerations ("integrity metrics misuse regulation"). They would not be allowed, e.g., to dismiss other software environments that have comparable, fully acceptable security properties. Under such a regime, AOL could not prevent Yahoo's client to interoperate with AOL IM. I have written about this a little bit in a paper a few months ago (see pages 641-642). In fact, such an approach is not something totally novel. In the consent decrees which brought the U.S. antitrust proceedings against Microsoft to an end last year, there are several "security carve-out" provisions according to which Microsoft is not required to disclose/license APIs etc. of its DRM and security technologies to third parties (see my paper on pages 627-628 and 642 footnote 2018). However, Microsoft is not allowed to deny the disclosure/licensing just to prevent competition to occur. This is a similar approach to an "integrity metrics misuse" regulation because it allows the use of true integrity metrics by the service/content provider for security-related reasons, but not for other unrelated, in particular anti-competitive, reasons.
I am not saying that the integrity metrics misuse approach is necessarily better than the owner override approach. The integrity metrics misuse approach has its own drawbacks:
- It may be unrealistic to expect that such an approach would be implemented in the near future in some countries, in particular the U.S.
- There is a danger that application, service and content providers will cite security reasons for the refusal to interoperate with a particular client application where, in fact, they do this just for anti-competitive reasons. It may be easy to "hide" anti-competitive reasons in a security justification. In fact, this issue was also noted by the court which approved the consent decrees in the Microsoft case (see my
paper on pages 627-628).
Ultimately, it's not a question whether an owner override or an integrity metrics misuse regulation is the perfect solution to prevent anti-competitive behavior in TC platforms. Rather, it's a matter of comparing the pros and cons of both (and perhaps other) approaches. Currently, I am not sure which is the better way to go. In the end, it may be that lawyers tend to prefer an integrity metrics misuse regulation, while technologists prefer an owner override solution.
Thanks a lot to Seth Schoen and Dave Safford for helping me clarify my position on this issue.