[einhverfr]

If Amazon, Yahoo, and the small SaaS provider are in the same boat security-wise, then you have the incentive to get the root problems fixed. Google's approach takes away that incentive from the large providers.

I don't think it is just a question of pretending. It is a question of making sure that everyone is in the same boat security-wise so that the root problems in fact get addressed.

What Google does is make Amazon more secure and the small SaaS provider less so. And it makes sure that the big providers have less incentive to fix the underlying concerns.

[tptacek]

The Chromium team didn't choose how big to make the lifeboat. They have the one they have. If they've got to choose between putting Amazon in it or you, then, as a user, I'm glad they chose rationally.

[gojomo]

It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).

[tptacek]

Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.

[gojomo]

Then correct me, don't insult me.

Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates?

All I know about it, I read from Langley's writings. Is there a better reference?

Who set the implemntation limits, if not Google?

Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.

[tptacek]

Your feelings aren't material to the issue at hand. You're not supposed to feel good about CRLsets.

Google didn't invent this idea. It was suggested by the CABForum.

CRLsets are static, practically hardcoded revocations that every installation of Chrome receives. The idea that https://yourblog.com should expect specific consideration in Chrome updates is about as reasonable as suggesting that we revert back from the DNS to host files.

[gojomo]

Yes, feelings are immaterial, but you shouldn't be trying to convince with bluster when you've erred on the facts.

The more I read, the more it seems CRLSet implementation choices were entirely Google's. For example, when CABForum members want information about how CRLSets work, Langley suggests the best (and only!) reference is the Chrome source code:

https://cabforum.org/pipermail/public/2013-August/002149.htm...

I am of course open to better information. But for now it still looks like Google did indeed "choose how big to make the lifeboat", unlike your assertion to the contrary.

Also, it looks like the 250KB cap is in Google's unpublished server-side source that constructs the CRLSets. So Google could conceivably "expand the lifeboat" unilaterally with a tiny edit!

For reference, it appears the current 'Safe Browsing' blacklists, never more stale than 45 minutes, are about 2.3MB in size. So the CRLSet cap (250KB) and freshness (1 day) aren't very generous to users.