andrius4669

>because they are forced to contribute

but they aren't. GPL forces to release source, not contribute.

Flawed one, it failed to collect itself.

Not taking input from google about who to block (iirc it still use google's safe browsing list) would be nice. That just doesn't feel safe to me, not to mention idealogical reasons. But that's just my opinion I guess.

https://letsencrypt.org/2015/10/29/phishing-and-malware.html

But you can do the same in JavaScript.

More serious reason is imo js requirement, as I'm not aware of native support of password hashing in HTML forms. Also, different ways of hash keying/salting would make it either complicated or inflexible..

Should't that hate be directed to your ISP?

https://www.gimp.org/news/2018/05/20/gimp-2-10-2-released/ official announcement

https://git.gnome.org/browse/gimp/plain/NEWS changelog

If it comes down to that, bitcoin will probably adopt some post-quantum signature scheme for new wallets.

Probably.

>DNSSEC has a CA-like trust model.

Not really.

You cannot get .tk operator to sign .jp domain (unless they're both controlled by same authority, which usually isn't the case).

Would webasm port make this actually real?

In context of this issue, it's none of these. file:// scheme should not be accessible from http(s):// contexts.

Why not just block ia_archiver useragent in your web server for these paths instead? Also, I'm curious, what that good reason could be?

pretty good presentation on that by djb: https://projectbullrun.org/surveillance/2015/video-2015.html...