DropBox was hacked in 2012 (and all email addresses were leaked)[0], so you might have just been getting spam from regular spammers that got a copy of this list.
1,020 karma · joined December 5, 2011
IRCd developer and network staff member here. Dead wrong. I don't think I've seen a single IRCd that keeps logs, and doing so would make it much more expensive to run an IRC network. Additionally, it would be a huge violation of privacy, and we value our users' privacy. The IRCd only logs server events (e.g. network-wide bans, server connection/disconnection, use of administrative tools) and user connections/disconnections (for anti-abuse purposes).
If network staff have logs of something, it was either because their IRC client was present in the channel or because someone else gave them logs.
Most of my network's servers hang around 2-3% CPU usage and <5GB disk usage, and we'd like to keep it that way because we don't want it to cost a lot to host. We have an average of 1000-2000 users per server.
Ingress also had in-game items named after companies, but these items could drop from anywhere and were likely to be added to the game anyway. A couple examples of these are the SoftBank Ultra Link and the "MUFG" (Mitsubishi UFJ Financial Group) capsule.
I think the only time they had a commercial partnership that gave someone in particular an edge was when they introduced Ultra Strike items, which could initially only be obtained on some Motorola-branded Android devices. These can now be obtained on any device, though.
Given that it's the same team working on Pokemon Go, I think it's unlikely that they'll make things annoyingly intrusive or force you to go to specific Pokestops to get certain items.
It's extremely unlikely Netflix will publish how they perform the detection, because that would make it easier for people to get around. My guess is that they know where your account should be located based on payment information or previous detection of region-switching services, and they use these flagged accounts to uncover new region switchers.
It's relevant to mention that CloudFlare already does terminate a class of sites without "due process": malware hosts. What makes malware hosts that much worse than booters? Answer: CloudFlare's IPs can get blacklisted for it.
Running a HTTPd on each server is a bad idea for us since it increases DDoS attack surface area. This would essentially have the same distribution issue that I would need to solve with a DNS-01 client as well, so either way new code is required.
It's theoretically possible to deploy Let's Encrypt now for IRC servers, which removes the cost issue. The new problems become the automated creation and deployment of IRC server certificates. You'll most likely need to use the DNS-01 challenge type, since most IRC servers aren't running a HTTPd and even if they were, you couldn't guarantee that the ACME server would pick the IP of the actual requesting server out of the "pool" records (e.g. irc.example.net). Using DNS-01 means you'll need to write code to interface with your DNS server, which also means securing that interaction (so other people can't modify your DNS records and get signed certs for your domain as well).
I actually manage the (signed) certificates for one of the IRC networks I'm an administrator for. Our two blockers for deploying Let's Encrypt are the aforementioned challenges with DNS-01, and the fact that our software currently validates server-to-server links using the fingerprint of each server's individual certificate, hardcoded into the configuration file. If we're switching certs every 3 months, we'll need some way to either distribute certificate configuration more efficiently or we'll need to change the ircd to verify the certificate chain instead of the fingerprint.
FWIW, our current deployment of signed certs is the "one cert to rule them all" deployed to all servers on our network. This is definitely not ideal, but it's by far the cheapest and easiest option prior to Let's Encrypt. All other options we evaluated were simply way too expensive ($X,000+), extremely labor-intensive (e.g. manually obtaining a new cert for every single server every year/every time something changed), or both.
Source: I was on the Workstation team when the layoff happened.
If you don't configure a password to connect, no password is required.
[1]: https://pubs.vmware.com/workstation-9/index.jsp#com.vmware.w...
HackerRank is just a tool. Its effectiveness depends on how well the company interviewing candidates configures it. I think algorithmic questions are the most popular, but it's completely configurable; you can have it ask whatever you want. It's also possible to manually review submissions. When we used it to evaluate candidates, we'd manually review the code for candidates that scored somewhere in the middle of the range. Depending on what their submission looked like, we'd decide whether or not to proceed with them. (HackerRank lets you see each version of the code attempted by the user, in addition to the final solution submitted.) We actually found it particularly efficient at finding good candidates; there was a very high correlation between interview performance and HackerRank score. If properly configured, HackerRank makes it easier to identify good candidates, which is (IMO) a good thing for everyone. For companies, it means that they spend less time interviewing bad candidates, and for candidates themselves, it means that they might be able to get their foot in the door somewhere where they'd usually get blocked by the "resume scanner" filter (since the company isn't risking engineer time/productivity to send out a simple HackerRank evaluation).
That said, HackerRank isn't perfect. My biggest complaint is the lack of feedback for some failure modes, most notably segfaults and failing non-sample testcases. For segfaults, it simply returns "segmentation fault" and you're expected to be able to find the problem (a similar tool I've seen, coderpad.io, dumps a stack trace). In some algorithmic questions, non-sample testcases include data that is vastly more voluminous than the sample data (which is intended to catch non-optimal implementations of the algorithm), but this isn't obvious at all. It would be nice if the non-sample test cases had titles (e.g. "extremely large input" or "edge case") so you could theorize about why yours failed.
People who have experience using HackerRank have a definite edge over candidates who have never used it before. If you are planning on taking a HackerRank test for a position, I would recommend trying some open questions on their site first. I also recommend having a local text editor, compiler, and debugger ready in case you hit a segfault that isn't immediately obvious. If your solution fails with "Terminated due to timeout", or your code works on all the sample cases but fails/crashes on the hidden cases, then your algorithm is likely not efficient enough (in the timeout case, look for ways to speed it up; in the 'mystery crash' case, look for ways to reduce memory usage). Lastly, if you have extra time after completing a HackerRank test, I recommend making sure your code is as clean as possible and is well-documented (but not over-documented), in case they decide to manually review it.
The Stockfighter-like concept is newer for them; it seems like they're also trying to work the pipeline from the other direction as well (i.e. finding good candidates for companies, instead of just testing candidates that have already applied for a position).
I've never dealt with stricter CPU limits than AWS's. Most providers will not be happy if you peg an entire core to 100% (after all, the physical cores are oversold), but they usually don't mind if the percentage is even as big as 50%.
It's a ridiculous system, but it's unfortunately how media licensing still works.
You could try getting a cheap VPN endpoint device and putting it between your router and your residential internet connection. Then you could VPN to that device to access the (usually-blocked) YouTube while still using your residential IP (assuming the blocking is done on your router).
Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve.
Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic.
Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.