prolurker

Tables layout is generally complex and slow, only hiding the text with CSS feels very fast.

Once layout is involved even without looping to set innerHTML it becomes a lot slower.

With control over the mirror list you can prevent certain users from getting updates which is a security problem but without being able to sign packages the danger is limited.

I would argue this particular example has more to do with the radix parameter of parseInt being optional and having a complex behavior.

More generally, javascript functions accepting any number of parameters, regardless of those specified in the function declaration, is quite error prone when passing functions around.

I always use anonymous functions or 'bind' to explicitly match the parameters unless all functions involved are curried.

The other reason to avoid passing 'naked' functions around too happily is the behavior of this.

I also find most optimizations to focus on simple, explicit code. Nothing like using the less common, more dynamic features of the language to hit deoptimizations.

Correct, but, even if not explicitly said, the cached entries should be associated to the certificate's fingerprint and immediately discarded once the certificate expires or is changed.

The problem is that servers are allowed to update their resources at any time without waiting for any specific expiration time. So when a user instructs it's browser to refresh the page, usually expecting to get the most up to date version, the browser has to choose between giving the still valid, but maybe not completely updated, cached version or actually checking if the resource has been updated.

Immutable makes it clear that the server won't update the resource in place and will handle updates by generating a new one so the browser can happily avoid checking those resources on page refresh.

That's an interesting attack vector, in the section 3 of the RFC they recommend to ignore the directive unless it's a secure connection which would mitigate that kind of problems.

Another solution would be to use an unpredictable versioning scheme so the attacker can't anticipate the name of the resources.

cache-control: private doesn't seem to imply that a resource won't ever change and on page refresh the browsers have to check if the resource has been updated, immutable would avoid the 304's responses cascade.