90 karma · joined March 26, 2018
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...
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.
Including autofixing if wanted.
Will be in the next release.
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! :-)
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!).
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.
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".