A few months ago, Klaus Kursawe and Christian Stüble have published a paper that includes several proposals to improve the TCG specification. One of their proposal is to include an owner override into TCG. Compared to EFF's proposal, the proposal of Klaus and Christian includes a slight, but important variation. Under their proposal, the platform user would be allowed to send "false" integrity metrics to the remote application, service or content provider. However, at the same time, the user would always send the true integrity metrics to the provider as well, although in an encrypted form. The true integrity metrics would be encrypted with the public key of the TPM vendor.
Thereby, e.g., a bank could not control whether the user is accessing its online banking service with the bank's own client application or with the application of a competitor. However, if the user would take the bank to court afterwards due to some problems with its online banking service, the bank respectively the court could, with the assistance of the TPM vendor, force the decryption of the true integrity metrics. The bank could now prove in court whether the user accessed the online banking service with its own client application or with a third-party client that is not officially supported by the online banking service. If the user used a third-party client, any damages that have occured on the user's side would rest with the user. This modified owner override would enable users to access services with the client applications of their choice, but allocate the risk of using unsupported client applications to the users. It would disable "just-in-time remote attestation", while enabling ex post attestation.
While I find this an interesting variation of an owner override, I still have a problem with it: I doubt whether an ex post attestation will be enough in all cases. There are instances where the application, service or content provider is only willing to offer his service to users if he knows their attestation values before he starts offering his service to them. This is not only true for DRM, but may also be true for other applications where the threat model includes a malicious user.
What this proposal ultimately does is that it moves disputes about integrity metrics from the point in time when the service is offered to a later point in time when the service provider and the user meet again either in court or in out-of-court settlement talks. In law-and-economic terms, this resembles the turning of a property into a liability rule. The application, service or content provider cannot deny a user access to his service due to particular integrity metrics of a user. Rather, disputes about the integrity metrics are resolved in subsequent legal dispute settlement procedures. As a large body of economic literature has demonstrated, under certain circumstances, there are good reasons to move from a property to a liability rule. But I am not sure right now whether those circumstances are met in this case. (Also, other factors might have to be considered which are not part of the standard property/liability rule analysis).