timdierks

On one hand, you can justify the work as a part of making a more reliable platform without per-service shims, but presumably you could have asked the services to adopt a better open API rather than IFTTT-specific integration.

But why did you ignore all the commentary on your TOS? Are you endorsing those terms as the company you want to be?

What does the average user do when they forget their passphrase? (Which they will do constantly.)

How do you determine the keys associated with the people you wish to communicate with? (The web of trust and going to key-signing parties are about a thousand miles from 'everything just works'.)

You have the comparison backwards. The claim is that Google and Amazon don't care about idle power consumption, presumably because their homogeneous computing environments lead to relatively little idle time.

I was going to reply that the author of this article isn't the best finance writer in the world, because Matt Levine is the best finance writer in the world. Then I clicked the link.

I'm relying on https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Detai.... There are HSMs, I guess, but they'r only used to back up the keys when they're stored offline for durable backups. I hadn't seen the claim on the main page, but I'd consider it to be misleading, presuming that the cryptographic details whitepaper didn't totally misstate the design.

I said it above, but I'll reiterate here that Amazon KMS does not use HSMs; they don't provide a lot of detail to help you reason about what that implies for key security. (I agree that there's no reason to believe they're lying or that it's backdoored.) There's also not much discussion about where the authorization checks happen, and the security of key operations is only as secure as the entity to whom that is delegated.

Presumably, your rogue employee won't follow best practices, and there is not a quality audit trail for such abuse in most setups. I think we're in agreement: this is a hard problem and difficult to solve. In your article, that part of the problem statement is a red herring, as Cryptex doesn't solve it.

AWS KMS does not use HSMs. Amazon says it runs on HSAs ("hardened security appliance"), but they don't provide a lot of info on what that means. I would presume that the only thing keeping a limited number of Amazon employees from accessing your keys is policy.

I agree that using AWS KMS is the same architecture as using some other KMS that you run yourself, you just garner the benefit of their software and operational capacity and you buy service; this is the same as any other PaaS service at Amazon or some other vendor.

What's the value of Cryptex, though? Why not just store KMS-wrapped secrets in your config file and have Amazon unwrap them? Then you wouldn't be dependent on any local crypto implementation and you could use other KMS features, such as AEAD.

The recommended solution is still vulnerable to employee compromise: if they can push software that runs as a trusted role, they can steal any secrets that software has access to.

This article confuses me. The author tears down a strawman argument about running centralized key services ("The expensive solution"), then recommends exactly such a solution in Amazon KMS.

The only plausible way this can make sense to me is if he said "Running your own key service is a pain, use Amazon KMS". But that's a simple service question, probably wouldn't have taken up as much space.

I found a reference that the barge was 320 km downrange in the earlier tests. The Bahamas look to be an appropriate distance from Florida, although to the southeast of Cape Canaveral. From SpaceX's planned Texas spaceport, there's nothing at that range but gulf.

Here's the best explanation I've seen: http://h14s.p5r.org/2012/09/0x5f3759df.html

Have you ever been to NYC? Do you have any idea how much extra vehicle capacity would be necessary for Uber to supplant the subways? A subway track has capacity of roughly 25000 people/hour (112 people per car, 10 cars per train, 20 trains per hour) in each direction; that's as much as 10 freeway lanes. Manhattan has 20 subway tracks across its width (5 lines, each with express and local, in 2 directions), so that's at least 200 extra lanes of cars for Uber's disruption to innovate out of nowhere.

It's just the "Post hoc ergo propter hoc" fallacy. (Possibly also overactive pattern recognition; how many spams does he get about art at times unrelated to gallery visits?) Google does not sell such personal information to spammers (or anyone else).

If you visit non-Google websites, it's technically possible for people to discover relationships and target e-mails (e.g. if you entered your email address on website A and then visited website B, cookies can correlate the visits and, among other things, trigger e-mail; also malware and other privacy leakages), but Google does not use its information in the way alleged.

Disclaimer: I work for Google in privacy engineering, but I'm only speaking for myself based on information Google releases: https://privacy.google.com/#google-information.

There are no display ads on Google sites like Maps.

It is, in fact, really hard to be ablet to delete data from an online service, while also not raising the chance of losing it accidentally. But if you treat it as an engineering goal from the start, it's possible. (Disclaimer: I work for Google, and we work very hard on this.)

In extremely illiquid markets, you'll see failures of the ability of the markets to converge on clearing prices. Doesn't mean anything in particular.

How does Amazon claime 11 9's of durability when the chance of an asteroid extinction event is roughly 1000x as high?

This isn't a joke: I can't find any documentation on the risk model that lets them estimate 11 9's and what class of risks it includes.

In NYC, it takes 87 years and $4.5 billion to build 1.5 miles of transit: the 2nd Ave subway was originally approved in 1929 and the first phase won't open until 2016 at the earliest.

I guess at some point, I agree, but this is so far from the problems of forced ranking and application of curves to small numbers of staff that I think it's incommensurate.

I've never seen people pushed like that to make the curve line up, that I can recall. There's a belief that if you have a large enough sample, that the distribution will have a certain shape (that is, it's unlikely that if you have 500 people in a calibration that there won't be a few underperformers). I've never seen that used to change a score, either in an retrospective or anticipatory fashion, but only to assess whether the process is being internally honest, and only at scales that are large enough that the concern isn't particularly affected by sampling error. (That is, if past experience is that a certain outlying part of the curve has roughly 2% of employees in it, I've never seen anyone object because that bucket is empty with a N of 150 or less.)

In my experience, Google didn't have a forced curve ranking then, either. I've been a manager at Google since 2007 or so (with a 3-year gap when I went walkabout 2011-2014), I've probably participated in calibration of many thousands of engineers (and other ladders), and I've never once heard of a calibration score being adjusted to fit some expectation that a certain number of employees needed to be ranked as underperformers.

Well, yes, but you cannot do any useful math on months with that fact. Late in January, plus one "month", gives you early in March; early in July, plus one "month", gives you late in July. I can't imagine what useful intent could lead to this code being correct.

Some of this code is just... WTF? For example, https://github.com/Microsoft/WinObjC/blob/106d8b2738101872a1... ; even setting aside the fact that some minutes don't have 60 seconds, 30.42 days per month?!

From a first-law standpoint, how can it fundamentally require more energy than is released by mixing them?

I've always wondered why desalination is so hard. From a thermodynamics perspective, dissolving salt into water isn't particularly enthalpic (the water doesn't get warmer when you do it), so it's never been clear what the fundamental challenges to reversing that dissolution are.

It's surprising there isn't some chemical reaction to precipitate out the sodium and chloride atoms bonded to something else, or whatever.

Can you provide a cite for the unwritten rule (e.g. 15 points)? Just want to know what expectations are and how they are grounded. I couldn't find any relevant cites or discussion with a search. The FAQ entry sounds like a moderator policy, not a submitter guideline.

Also, I'm curious what work gets created by such dupes (presuming they're moderately low-volume). The vast majority of submissions go quietly to the 1-point grave, it looks like to me; as such, it would seem like there's little to no moderation problem with (some moderate load of) reposts that people have no interest in.

And if people are interested, presumably it's new to them? Not sure why their votes would be less relevant than votes for novel content of similar net interest. IMO, existing dedup'ing and moderating discretion is probably sufficient to keep things clean.

If anything, it would seem like HN should merge dup'ed submissions (so we don't have comments across a dozen different entries) while resetting the time to give them a new shot at the front page. And if people care about Internet Points, figuring out a way to share the karma.

While that's sometimes an element at Google (we tend to be better at building things that engineers love to build and it's harder to do things that engineers don't care for), people are somewhat more enlightened than you fear and can see that the big picture of doing valuable work doesn't mean only doing the fun parts (and one element of managerial leadership is articulating this). Plus, a number of engineers really like fixing bugs, usability fixes, etc.

As to how decisions get made: it varies. Sometimes there's some consensus, and sometimes management / executives make decisions without seeking feedback or even going against the input of the team. But it's then incumbent upon them to persuade and lead the org; if they do this poorly, they don't tend to be as successful in the medium or long term.

Again, Google isn't remarkable in this fashion, even if it's possibly something of an outlier: in any field of endeavor, you'll be more successful if you can persuade people to want to contribute to your mission rather than forcing them to do it. [Cue up the Antoine de Saint-Exupery quote re: longing for the endless immensity of the sea.]

Everyone is a volunteer. Not just at Google, but in many other situations as well.

At Google, pretty much any of the engineers can go and get a job at another company whenever they want. So they tend to have access to internal mobility; Google would rather let them fill a different job at the company than have them quit. Thus, managers (either engineering managers or product managers) don't have a lot of coercive capability.

The path to success is to not be a manager who forces people to do your bidding, it is to be a leader who persuades your colleagues of your vision. At times the tool of command can be used, but it's best used lightly.

My goal is to be service-oriented: my job as a manager is to help my engineers be super-successful, and one of the ways I try to do that is by finding paths for the organization to build great software and leading my team and other teams to cooperating to build it.

Yes, I saw. But I'd never seen it before, found it to be fascinating reading, and there hadn't been a submission in months, so I thought I'd share it again. Evergreen!