You can see the CT peoples' comparison of CT to other technologies here: http://www.certificate-transparency.org/comparison http://www.certificate-transparency.

You can see the CT peoples' comparison of CT to other technologies here: http://www.certificate-transparency.org/comparison http://www.certificate-transparency.org/comparison One serious concern I see about TACK from the browser's perspective is the support burden of dealing with server admins' lost TACK keys. HPKP has similar risks, but it seems to manage this risk in a way that is more comfortable for browsers to deal with. However, I also think that at least at Mozilla we've become more worried about the risks of HPKP than we were originally, and so there are plans to build the same kind of mechanism for dealing with DoS due to HPKP that a browser would need to build for TACK. It may be too late to get browsers to do TACK because they seem pretty committed to HPKP already and it is harder to convince them to do both. However, if you still want to try then I'd suggest presenting more clearly how browsers could deal with the "I lost my TACK key" scenerio. The other major negative thing about TACK is that it requires the server admin to do work that can't be automated in a way that is reasonable (because the TACK key should not live on the web server). HPKP leaves more of an open door for future web servers to automatically apply it automatically (e.g. by generating pins for the end-entity, intermediates, and root keys in the chain, on the assumption that the server admin will never lose control of the private key of the end-entity at the same time he/she needs to switch CAs) or with very simplified UI.