For a moment II thought this was just a guide to installing uunbound the DNS server and configure it with ad hosts blocked out, but this is super valuable:

Additionally, adding a rule such as below to your router’s pf.conf will help to block ads on Google devices such as Chromecasts and Youtube apps that are often hardcoded to use Google DNS

vi /etc/pf.conf

pass out quick on egress from any to { 8.8.8.8 8.8.4.4 } rdr-to $adblock-server

Neato!

IRC is great. It’s easy to implement a client for, simple enough to understand, and used pretty widely. It’s still the main protocol I use to keep in touch with people.

The only thing I wish that it would get is server side history, so I could scroll back in a channel without idling or setting up a bouncer.

What’s ECDAA support like in browsers, backend libraries or hardware tokens?

I’ve learned programming by writing IRC bots and this is still my default activity when I learn a new language. It’s fun, because you get to play with sockets, text parsing and you can mix in all the interesting things you like (if you want to): TLS, asyncio, natural language parsing.

I strongly disagree with a CVE tag. If a specific CVE is worth attention it can be submitted under security, most likely with a nice abstract discussing it like the Theo undeadly link or the SSH enumeration issue. Adding a CVE tag will just give a green light to turning lobste.rs in a CVE database copy - I see no added value from that.

for my tiny eslint plugin, I do this:

• Check everything locally:
  • npm run test
  • npm run lint
• Bump version in package.json
• git add
• git commit
• git push
• wait for travis results (to see how other supported nodejs versions do)
• npm publish

Not sure whether I’d call it a security bug, but it’s definitely a bug. Thank you for filing it!

If you want tthe mixed contents warning go away (I.e., website containing insecure content) you might want to serve an “upgrade insecure requests” CSP header.

I’m Freddy and I do security things. Mostly web security: https://frederik-braun.com/archives.html

Does anyone have a sense of the level of effort required to port something like this to run on Firefox?

making the reports eligible for a bug bounty. Neat!

The most interesting about this isn’t the fine. The EU can make Google stop the problematic business practices that Android OEMs have to ship Chrome as default browser.

totally happy with a Microsoft ergonomic keyboard.

The main (only?) argument for putting static sites behind HTTPS is to prevent visitors from getting MITM’d. I’m a little uncomfortable about the unspoken implication that content publishers should be responsible for the security of their visitors but that’s a separate point.

What really annoys me about the push for HTTP on static sites and other benign content is two things:

1. HTTPS is touted as the best thing since sliced bread but we already know the existing TLS certificate trust chain in mainstream browsers is pretty weak. Certificate authorities have suffered serious security lapses and/or incompetence (Symantec, Wosign), or delegate too freely to likewise entities. Pretty much all developed countries in the world either have government-run CAs or can swoop in and “borrow” the private keys of commercial CAs to sign fraudulent certs or (more likely) decrypt traffic as it goes by. There are things happening to make incremental improvements to these problems but right now the mainstream opinion is just to keep putting band-aids on the system. Don’t get me wrong, HTTPS is better than nothing but the whole trust chain is very half-assed and nobody seems interested in fixing it.

2. HTTPS is arguably not the right tool for public, non-secret content. As a static content publisher (yes, I use that term loosely), I don’t want to encrypt my content, I only want to sign it to show that it hasn’t been tampered with. But with HTTPS it’s all-or-nothing. If we had secure DNS (however implemented), this would be fairly straightforward: public key in a DNS record and a signature for the page in the HTTP headers. The browser can show the page as signed, clients who don’t have the technology to verify the signature or who don’t care are free to be MITMed at their leisure.

Great article! I wonder whether the future of HTML escaping libraries will lie with something like ammonia, which actually parses the HTML before emitting a sanitized version, instead of simple text-replacement - at a certain point, I guess it becomes a better idea to just do what a browser would do in order to ensure that your sanitation worked…

The only dependency is a recent 57+ version of Firefox.

Neat collection, thank you!

The architecture of open source applications should be real-world enough

Reminds me of the format we wanted to use in Firefox OS next, which never came to be.

There’s also an IETF draft following a similar goal: https://datatracker.ietf.org/doc/html/draft-yasskin-webpackage-use-cases-01

One idea I had to solve the fundamental insecurity of web-based crypto was to add subresource integrity support to service workers.

Service workers are persistent and are essentially a piece of JavaScript which can intermediate all HTTP requests to an origin, which means a trusted service worker could verify the integrity of all loaded resources according to an arbitrary policy. Then you only need to secure the service worker itself. If you could specify the known hash of a service worker JS file, you could know that all future resource loads from the origin would be intermediated by that JS. Presumably, the service worker JS would change rarely and be publically auditable. (If the inconvenience of not being able to change its hash is too inconvenient, it could chainload a signed service worker file; you can implement arbitrary policies.)

This creates a TOFU environment. One logical extension if this were implemented would be to create a browser extension which preseeds such service workers with their known hashes, similarly to HTTPS Everywhere.

I created an issue suggesting this at the Subresource Integrity WG: https://github.com/w3c/webappsec-subresource-integrity/issues/66