EDIT: Why did someone flag this? This is literally what CloudFlare said they do – they fingerprint your browser, to track you, and find out if you are a bot DDoSing them – or if you have a normal browsing behaviour.
For that to work they need to fingerprint and track you. Which is why they said they block users with NoScript or on TOR.
> I've been here since the beginning and I think comments have gotten more hostile since then.
I've been reading HN since around 2010 and to me it seems that there is now less hostility about technical topics but more hostility against anyone who isn't 100% politically correct. I also think that the quality of comments has decreased dramatically since.
> No one outside of HN that I interact with discusses HN, and if there's ever discussion of this stereotype here, I've missed it.
Many IRC communities I'm part of know HN and sometimes discuss it and the stereotype in those seems to be that HN users are overly sensitive, hypocritical, greedy and toxic. Many of them are also former HN users who now hate the site.
I think its more hostile than when I started. I'm pretty sure some of the comments about other people's religion wouldn't have stood in 2009[1].
The biggest difference to me is a tactical change of not refuting the other side or even acknowledging their argument, but just bury people you disagree with and take their voice.
Religious flamewars are not allowed here and we point that out whenever we see them. If something like https://news.ycombinator.com/item?id=10574861 comes up again, it would be good email us at hn@ycombinator.com. We don't see everything, so we rely on users to keep us informed.
It wasn't a "Religious flamewars", it was a drive-by of FUD that has been repeated in political threads. I wasn't arguing for superiority of something, I was just pointing out the historical truth and beliefs of a church. Frankly, getting downvoted for quoting the founder/prophet of the church for the origin of the name was a pretty low point on HN for me.
Or just block the sources of abuse while everyone else enjoys and can act on the content. Or just block comments from anonymous nets so they can at least read. Comment sections that are Wild West hurt branding too much for it to be an option.
It seems like we know how to solve this. Put a CAPTCHA on account creation, then allow users to flag posts and auto-ban fresh accounts with high flag rates.
I'm honestly kind of surprised that there isn't more spam from attackers who compromise something close enough to a backbone provider that they can spoof arbitrary IP addresses and still see the return traffic.
Those are possibilities. As is Disqus-style moderation. Nonetheless, it's a lot of extra work with nothing to show for it and possibly dangerous to site experience. That's the problem Tor poses.
The problem isn't unique to Tor. It's anything that allows a spammer to use the same IP address as innocent people, including things that aren't exactly legal, like compromised PCs and routers. Which means blocking Tor blocks the people who follow the law but not the people who break the law.
And the problem is going to get worse as a result of IPv4 address exhaustion because some ISPs are going to have to start using carrier grade NAT (and some already are). The answer to that is IPv6 as ever, but that has the opposite problem. IPv6 addresses are too cheap to meter and using a thing for proof of stake requires the thing to be scarce.
So the thing to show for it is that you can field test your solution prior to the day of Spam Armageddon when a spammer realizes they have a botnet with access to a million billion IPv6 addresses.
"The problem isn't unique to Tor. It's anything that allows a spammer to use the same IP address as innocent people, including things that aren't exactly legal, like compromised PCs and routers. "
That's sort of true. It's technically true that any I.P. address might be the source of malice. Yet, Tor's I.P. addresses will steadily be the source of a ton of malice with no resolution of that problem. Quite different than what happens when someone's ISP tells them there's malware on their machine. There's also economics involved where people have to pay for those machines and are therefore more likely to use them for other, profitable activities. Probably why we see less spam from those accounts.
What remains are WiFi hotspots, libraries, etc. Apparently, they're not drowning services in hatemail and spam because they're still allowed. They could but few are complaining about them.
"And the problem is going to get worse as a result of IPv4 address exhaustion because some ISPs are going to have to start using carrier grade NAT (and some already are). "
Good call. I saw this coming. There were already talks by Ross Anderson IIRC about how critical it was for forensics to get the port number and time-stamp since CG-NAT would make I.P.'s useless. Already is in some areas.
"So the thing to show for it is that you can field test your solution prior to the day of Spam Armageddon when a spammer realizes they have a botnet with access to a million billion IPv6 addresses."
Haha. Interesting way of looking at it. I'm more worried about the routing tables, though, if IPv6 got massive surge of traffic. Never looked to see if they fixed early concerns about how well Tier 1-3 HW would handle it vs IPv4.
> It's technically true that any I.P. address might be the source of malice. Yet, Tor's I.P. addresses will steadily be the source of a ton of malice with no resolution of that problem.
Which makes blocking Tor seem attractive until you still need some defense against the attacks from arbitrary other IP addresses, and once you have those defenses you can use them against malicious Tor traffic and no longer need to block its legitimate users.
> Good call. I saw this coming. There were already talks by Ross Anderson IIRC about how critical it was for forensics to get the port number and time-stamp since CG-NAT would make I.P.'s useless. Already is in some areas.
And even then it's assuming the carrier has port-level logs to compare against. If you have ten million customers who on average make one connection every ten seconds and a connection log entry is 50 bytes then you're writing 50MB/sec of log entries, i.e. >4TB/day. If they keep them at all it's not going to be for very long.
It seems like it would be a lot easier to move identities to some kind of proof of work based pseudonyms than to keep trying to force IP addresses to serve a role they were never designed for and the casting into of which causes no small amount of collateral damage.
> I'm more worried about the routing tables, though, if IPv6 got massive surge of traffic. Never looked to see if they fixed early concerns about how well Tier 1-3 HW would handle it vs IPv4.
Part of it is that IPv6 addresses are allocated in larger blocks, which means less address space fragmentation because nobody runs out and has to come back for another non-contiguous block, which means more addresses per routing table entry. And the rest of it is that memory is cheaper than it used to be.
"and once you have those defenses you can use them against malicious Tor traffic and no longer need to block its legitimate users."
What's your recommendation for a low-cost, low-effort method that solves the Tor and every other I.P. user problem? It has to provide a reduction just as good as blocking Tor with similar effort by admin.
> What's your recommendation for a low-cost, low-effort method that solves the Tor and every other I.P. user problem?
The first step is realizing that you have a behavior problem, not an IP address problem. There is no silver bullet against an adaptive adversary, but this is the sort of thing that proof of stake or proof of work is well suited for. If the user wants to do more than read your website then they need to post some collateral. In the small time case this is just putting a CAPTCHA on account creation. If you're a bank or something then nobody gets in the door unless they have an account with you which has been verified against their government ID etc.
Then anybody who misbehaves forfeits their collateral, i.e. you close their account. Which for normal people never happens, but for malicious parties is designed to happen before the profit from their malice exceeds the value of the collateral. Spammers aren't going to be willing to solve CAPTCHAs all day just to post one message at a time which will be deleted in twenty minutes.
And then the administrative cost disappears because the spammers realize it isn't worth doing and you don't have to spend time deleting spam once they stop posting it.
> It has to provide a reduction just as good as blocking Tor with similar effort by admin.
To which a large point is that blocking Tor isn't particularly effective. People make a lot of noise about the fact that a Tor IP address is some large factor more likely than average to have malicious traffic, but it also represents a larger number of people than most IP addresses. If you look instead at the percentage of all malicious traffic that comes from Tor, it's a minority.
And even allowing Tor traffic and then trying to measure what percentage of all malicious traffic is from Tor is over-representing the effectiveness of blocking Tor by counting malicious traffic that comes from Tor if you allow it but would still come from somewhere else if you didn't.
Net result being that blocking Tor might get you something like a single digit reduction in malicious traffic. Now you need to do something about the other 90%. CAPTCHAs and pseudonym reputation systems and so on. But those things work about as well against traffic from Tor as traffic from anywhere else, which cuts a nice chunk out of the remaining single digit percentage improvement you had been getting by blocking Tor.
Net result is you end up blocking a lot of innocent people to get something like a 2% overall reduction in malicious traffic. And the better you get at solving the problem in other ways, the smaller the benefit of blacklisting IP addresses becomes.
If you're a business, you can't. There's a decision to make:
1. Focus on benefiting anonymous people who either don't contribute shit back to the business or barely do. Freeloaders.
2. Focus on benefiting the founders, customers, and employees (in that order). If you loose some freeloaders, then so be it. If it's their design decision, then so be it time 10. They can always set up an unrestricted forum for people like them to discuss the article and deal with security headaches they bring in.
Wait, No 2 seems to work as most readers and the company are benefiting except for the few that choose not to.
> My secretary also prints out all nonspam email messages addressed to taocp@cs.stanford.edu or knuth-bug@cs.stanford.edu,
She definitely does use email. I don't see what is so wrong with paying someone else to do the necessary time consuming tasks with low priority when you have other high priority things to do. Should there also be no janitors?
Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key.
You want this as a library that's impossible to misuse and a nice CLI on top.
The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.
> Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key.
You need key rotation if you want security, so you need master keys and subkeys (or you'll end up reimplementing them by hand with conventions that everyone will interpret differently). Multiple identities on a key are I guess not strictly necessary but they're a very useful feature. You absolutely need the ability to sign other people's identities. You need to be able to sign and encrypt both text and binary (and do symmetric encryption), and export the result of everything in both text and binary. Smartcard support is a very good idea. Agent support is vital. What things do you think GPG should cut?
> You want this as a library that's impossible to misuse and a nice CLI on top.
Agreed. A rock-solid OpenPGP library would be great. I do think that's one place where there's a lot of real room for improvement.
> The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
IIRC: developer, singular, unpaid and part-time. Also GPG is 20+ years old and doesn't want to change the CLI radically so as a) not to disrupt existing users b) not to disrupt existing scripts.
A frontend or alternative with great UX would be really useful. But who's going to pay for that work?
Right, forgot about those. Still those are just two more commands, which brings us to 5. That shouldn't push the complexity up significantly and doesn't change anything about my argument.
What about binding your primary secure key that is usually stored in a safe on a Yubikey with secondary keys stored on Yubikeys you carry around with you?
What about revoking a secondary key after a laptop or Yubikey got stolen?
I have little direct evidence, but I suspect the problem is a set of programmers that hate the command line and never learned to rely on man pages. When they try gpg, they try --help and see the giant list of options, and immediately panic.
This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
I consider myself pretty comfortable with command lines, given that I more or less live in a terminal window for work purposes.
GPG's particular command-line interface is still a counterintuitive mishmash of stuff that essentially boils down to having to look up a tutorial every single time I want to do anything related to key management. I've actually been known to ask people to email me just so I can fire up a mail client with Enigmail and have it auto-fetch the key into my keyring and set trust on it through their interface. Which, while not great, is light-years better than GPG's native key-editing interface.
Is the command line interface that is confusing? Or is it that the crypto jargon is confusing? I suspect the latter, maybe?
Regardless, just like any feature-rich technical library, this is easily solved by a front-end. For example,
> Enigmail
...is an outstanding front end for many common uses. Unfortunately, the idea of writing a better UI front end for GPG - possibly many, specialized for various tasks - just like we've done for every other complicated piece of technology, it seems like everyone says "it's too complicated" and writes off GPG entirely.
> native key-editing interface
While I agree that interface is not the best (use Enigmail), I don't necessarily find it hard. It's very unrefined, tedious, and can be very annoying.
> Regardless, just like any feature-rich technical library, this is easily solved by a front-end.
Note that GPG is not a technical library. The primary "library" for using GPG consists of some functions that system() out to GPG and pipe data back and forth. I think this is a big impediment to getting better frontends (particularly on platforms other than linuxlike desktops).
That is an order of magnitude more effort than most people are willing to put into it. Try teaching a not-computer-savvy relative to use it and exchange email with them.
The amount of animation on the page makes it really hard to look at.
E: from the graph it seems they are using Tahoe-LAFS[1] for the backend. However I won't be trusting this unless they make the frontend free software as well.
E^2: OpenPGP smartcard authentication would also be a nice feature. Thought of this because they seem to recommend YubiKeys and password managers so why not smartcards as well.
E^3: The reason for OpenPGP smarcard instead of YubiKey is that there is there it at least one completely open hardware and free software implementation for that, the FST-01[2].
I guess, because of the effect of the "internet social media amplification." Ah those foregone times when we'd just be "pranked" directly by a person we can touch, or at most once a day from the media.
Yes. Possibly with a stout stick. For some reason I really, really dislike a whole day when everyone is doing their best to spam me with misinformation for teh lulz.
That name alone should tell you that they don't give a hoot about anything other than WWW and HTTP.