tunetheweb

We've investigated and found the bug: https://crbug.com/559302209

It's not just Google.com but any site using Compression Dictionary Transport (which google.com was an early adopter of - https://developer.chrome.com/blog/search-compression-diction...). The shared dictionaries are an additional storage added with this feature but are not getting correctly cleared on close.

A fix is being worked on to resolve that. Follow above bug if interested when that lands...

Site owner here! Even if it did take that long, browsers are clever enough not to wait until all the HTML is fetched as HTML can be processed in a streaming fashion. You can see here that stylesheets https://www.webpagetest.org/customWaterfall.php?test=240913_... are requested from the first bunch of HTML.

A second is little disappointing, but in fairness my lowly, single CPU, single core server with only 1 GB of RAM (a t2.micro server on AWS) was struggling a little with the load that Hacker News sent to it yesterday (16,000 page views in a day compared to about a third of that number for the whole month before that!). Plus the images on this page are a particularly big (because they are quite detailed so can't compress them more without losing that detail). So it was probably a bit slower than usual. At the minute everything is served from that one server (no CDN either at the mo - I really should stick it behind Cloudflare). It was a little play thing for me to test stuff out with, that became an occasional blog too on the side.

2022 edition of the Web Almanac (HTTP Archive’s annual state of the web report) has just been released.

Seems like a good thing to check for! So we added a rule for this: https://github.com/sqlfluff/sqlfluff/pull/1527

Including autofixing if wanted.

Will be in the next release.

There already is a VS Code extension for this: https://marketplace.visualstudio.com/items?itemName=dorzey.v...

https://github.com/sqlfluff/vscode-sqlfluff

Looks like we didn't support SETOF.

Added this here: https://github.com/sqlfluff/sqlfluff/pull/1522

Demonstrating how easy it is to add this sort of thing to the project thanks to how the code is structured! :-)

They’ve been proposed!: https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-dat...

You can already do this with JavaScript now: https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo... though as you can see from the bottom of that link, Browser support is limited at the moment (and experimental so may even be removed/changed!).

From the post: “That leads nicely into the privacy implications of using third-party CDNs. You have no idea what sort of tracking they are doing to your users by using them, rather than self-hosting. And recent legislation means a lot of sites have to explicitly list all the cookies used on the site, which gets more complicated when using a third-party.“

Is any site using this? It requires a special certificate and signing your content (which admittedly Cloudflare will take care of for you) but even then it’s only for Chrome and Firefox and Apple have said they won’t support it. Over a year after announcing it I’ve yet to find a single site that does this.

> But why is CSP harder to test than any other client-side change, like rewriting your login page/component?

Maybe not so much now. But when I wrote that post there were lots of bugs and missing features across the various browsers (examples in the post). It was early days for CSP and it’s got better since (hence why I now do recommend CSP), but regardless CSP is a complex technology and tough to get right. Each page and each browser might have its own CSP requirements (e.g. when polyfills are included on a bad for example).

> I meant to say that you can add it as a XSS prevention to example.com/app/ and not worry about example.com/static/ or example.com/blog/

Then your cookies are at risk. Yes cookies can be scoped to a path, but few do that. And they can be made HttpOnly which is more common, but still not used anywhere near enough (8.31% of cookies - https://github.com/mikewest/http-state-tokens/blob/master/RE...). Additionally if you have a vulnerability on /static/ then you can hijack the app link or login link to send users to badexample.com or similar when they want to login to the app.

It will still offer some protection if only on /app/ and is better than nothing, but still preferable to have it on the whole domain. It’s like HTTPS - having it on just one page is an anti-pattern that shouldn’t be used anymore.

Yeah I was trying to figure out what to do with that one. In the end I “corrected” it as suggested but could have gone either way depending whether Manning is a singular company or a plural collection of people.

OP here and I disagree. Implementing a CSP for a page is hard (given the many different browsers), implementing it for a site is really hard! And yes it does pretty much need to be "domain level" to be effective.

It's easy to test if a password algorithm change fails, not so much for CSP. And the reporting options are next to useless because they are so noisy.

That's not to say people shouldn't implement CSP - it's a great option (now - less so in 2015 when this post was written). But they shouldn't just copy and paste a CSP policy from a random blog post they found, get an A+ on a security scanning tool and feel proud, without realising that they may have broken part of their website or implemented a pointless CSP. That was intention of this post and apologies if it read as "don't use then cause they are hard".

As others have pointed out, this post is from 2015 and a lot has changed since then. I've added an updated section at the end, to clarify my thoughts since then (mostly unchanged to be honest, except for CSP): https://www.tunetheweb.com/blog/dangerous-web-security-featu...

Thanks fixed. This is why I need editors :-)