HN user

SpikeGronim

776 karma

I'm a programmer living in Michigan.

Posts1
Comments167
View on HN

ChaCha20 is implemented in hardware on many mobile platforms. It's often a preferred TLS cipher on Android. AES is common in hardware as well.

You can pressurize the gas and put a barometer in the tube in order to detect any breach of the tube. This was used during the cold war and the NSA tapped the communications cable anyway by filling the space around the tube with gas as well. Source: James Bamford's books on the NSA.

I don't think your attack violates the security model of this protocol. One of the proofs in the paper is that if you have a network of good and bad nodes the bad nodes can use tricks like you posted to discover whether a good or bad node sent the message. I think that's all they can discover: did an attacker send this or not? But then again they already knew that, didn't they? So I think your attack is only interesting for 3 nodes.

You generally use Unicorn etc. behind something like nginx. The last time I did that I used nginx to handle thousands of concurrent connections that were forwarded to nCPUs Unicorn instances. Nginx is very good at handling lots of connections, Unicorn is good at handling a Rack app.

Several things make it easier to maintain:

- super fast compile times for fast developer iterations

- you can create an interface (set of methods) that your module owns, and apply it to objects created by other modules without recompiling. If you only need one method you can take that one. It encourages decoupling you from your dependencies.

- the code has one correct formatting convention and a tool that will auto-format your code

- many complex rules for numeric conversions that are implicit in C and cause no end of trouble are explicit and much simpler in Go.

- treating concurrency as a series of sequential process connected with channels makes it MUCH easier to reason about.

They say no evidence of illegality, but there is evidence of poor judgement. Without commenting on the specifics of this incident that's a valid reason to fire a CEO/co-founder/exec. I have no particular knowledge of what happened but if GitHub thinks he showed poor judgement then it is reasonable to ask him to resign.

I am an ex-AWS employee. I can verify that AWS was founded as a new line of business using new servers purchased for AWS. The idea that AWS was started using Amazon's spare capacity is widely repeated but false. Amazon is definitely leveraging their expertise and not their physical machines. Source: I've seen the original pitch deck for Amazon S3.

"W/ the NSA program, you're just a row in a database, if you're not a terrorist* or associate with terrorists nobody gives rat's ass about what you're doing unless one can relate you to another suspicious character. That's national security stuff, sorry if ya don't like it, but tough."

This "if you are not a terrorist don't worry" reasoning is flawed. GCHQ was capturing all Yahoo! webcams. That's not anti-terrorism, that's fodder for blackmail. You also don't surveil WoW to find terrorists. The Snowden leaks have shown many projects that have nothing to do with "national security", but if you say those magic words nobody can oversee what you're doing.

The CIA, NSA should be disbanded and replaced with new institutions. Those institutions should have limited scope and much tighter oversight.

I can confirm that Etsy.com is primarily PHP. We have no externally facing Rails projects. We have some internal tools on Rails.

-- spike@etsy.com

Redis doesn't use libuv, and in fact rejected a patch from MS to add libuv support. The reason is dependency management, not performance. Redis takes very very few dependencies - basically just a C compiler and POSIX. This makes it easier to deploy Redis, and Redis doesn't have to worry about failures in its non-existent dependencies.

TCP cannot tell what the application wants. If the client application never closes the connection then TCP will keep that connection alive indefinitely (assuming you configured it with keep alives). Each connection consumes some resources on the server (primarily send and receive buffers in memory). So if your application never tells TCP to close the connection then it hogs server resources. There are many malicious DoS tactics that go for the same effect.

How do you know if this caller is from the NSA for real? I could get up to all sorts if mischief. Either I can make the NSA look bad, or I can social engineer my way into ISPs by pretending to be the NSA. Good on this ISP though!

Average size is irrelevant. A handful of 1G objects dwarf hundreds of 1 byte objects when computing the average. The overal distribution is interesting. There are actually three: GET sizes, PUT sizes, and stored sizes. They are not identical distributions, especially since the as the PUT size distribution has changed it becomes out of synch with the stored size distribution. Wish I could tell you more, there are some fascinating data points in there but, you know, NDA. Source: form S3 employee.

I saw the exact same thing with Cisco in the NY public school system. They gave my high school something like $50,000 of equipment in a rack to support two machines that submitted grades. We stripped it for parts and put it to better use, it had some really nice switches in it. But it was clearly misspent public money. At least we did put it to use in classrooms, though not as they intended.

If you follow the advice in this paper[1] you will be measuring media errors in your drives. That means re-reading all data every N days, even archived data. Without periodically re-reading and validating (checksumming) the data you can't tell if it has rotted in place. Since the distribution of errors over drives is very exponential you should then pro-actively remove the worst drives in your system. That will avoid an accumulation of errors and sudden multiple drive failure as described here.

Durability is like a diamond: it is forever.

1. http://research.google.com/pubs/pub32774.html

I'll share how wavii does this. We use amazon elb and chef. The first chef recipe that runs on our frontend is "touch /tmp/website_should_drain". The website then returns 404 from the /status health check URL. We wait 30s, update the site, and then rm the draining sentinel file. If the deployment fails the host stays out of the elb. If more than 1/3 host fail we abort the whole deployment. This works well for us and was very simple to implement.

My favorite part is that they shut off their code signing infrastructure "within minutes". Good job Adobe! They are also saying that the root cause was essentially "somebody didn't follow procedures for setting up secure build servers, and we didn't catch it." Such a typical security threat: humans doing the wrong stuff.

Yes, that was my intent. I was asking for the other side to make a clear response and specifically to mention the Apache license in their response. They made a vague, long winded, PR-speak response which did not address any of the issues. I continue to judge them for bad business practices and ethics. If they provide more evidence that paints a better picture I'll listen.