Get the latest tech news
Google says "not a security vulnerability", quickly fixes without attribution
Following up with concrete operational cost data you suggested was important. I ran both implementations ingesting 1M certificates and performing monitor-style read operations: Write Costs (1M certificates): CompactLog: 12,847 storage PUTs Sunlight: 287,364 storage PUTs 22.4x more expensive writes Read Costs (Full tree sync, 1000 iterations): CompactLog: 82,025 GETs total (mostly cache hits after first sync) Sunlight: 41,030,000 GETs (41,030 per sync × 1000) 500x more expensive reads This exposes fundamental architectural issues with "independent read/write paths." The system lacks application-level caching, meaning every monitor request hits storage directly.
But this creates a distorted view of architectural viability - what works with sponsored infrastructure doesn't translate to sustainable operations for the broader ecosystem. The static CT API is objectively more complex than RFC 6962, its "pure" deployment model is economically unviable without sponsorship, and it weakens security guarantees (MMD > 0). What's particularly troubling is that the "direct storage serving" approach is essentially brute force engineering - throwing unlimited infrastructure at a problem instead of solving it properly.
Or read this on Hacker News
