amarkov

I also don't understand the downvote.

I need a specific purpose for processing PII, but that doesn't mean that I need a specific purpose for each individual place that PII ends up going. If my web server or database end up incidentally capturing the data in transit, that's not a violation, any more than it's a violation if I copy the data onto more sheets of paper than are strictly necessary.

Under the terms of the GDPR, user benefit is not required. I can log any PII I'd like as long as the user's given consent for it to sit in that log, or for it to be used in some process that reads from that log.

I probably would want to impose stricter rules on myself for the sake of avoiding regulators. But that's part of the problem. It doesn't seem possible to comply with GDPR as such without an army of consultants to guide you; what you have to do instead is invent a stricter regulation and follow that one instead.

> If a regulator thinks you are bending the rules good luck

That's the other part of the problem. A healthy regulatory system needs some way to say "well, you think I'm bending the rules, but I'm actually compliant in this complex way you hadn't considered". If a GDPR regulator just doesn't know much about software development, and thinks that any rollout-induced delay is undue, how do I argue against that?

Being the target of a government investigation is in and of itself an expensive process. You have to spend a bunch of time preparing your side of the story in exacting detail. You probably need to put a freeze on any changes which might make the regulator think you're trying to cover up previous misconduct.

And of course, if people find out out you're under investigation, a lot of people are going to just assume you did something wrong. You won't be able to fix that no matter what the regulators conclude.

A lot of the problems of the GDPR do indeed go away if you're building your systems from scratch, using data privacy standards significantly beyond what GDPR mandates.

Surely you see why this doesn't weaken the claim that it's hard for existing companies to understand what must be done to comply.

I must delete personal data "without undue delay". This opens up a few questions, which as far as I can tell the text of the regulation provides no guidance for.

* I (like most companies) have a variety of unstructured and/or immutable logs. I can't just DROP FROM table WHERE. Is it acceptable to delete this data by waiting a few days for a retention period to expire, or do I have to retrofit deletion functionality in?

* What if the retention period is a week, or a month? What if I've been advised to establish those longer retention periods for other reasons?

* If a bug is found in the data deletion workflow, is it an undue delay to say we'll tackle it next sprint? Do we need to drop everything and make it a priority now?

* Once we've resolved a personal data deletion bug, is it an undue delay to roll it out slowly over a week? Does it matter if this is our standard rollout process, or if there's a risky hotfix process we're deliberately choosing not to use?

Option C is that the letter was written in bad faith, and the sender intends to "rely on the exact wording rather than the spirit of the law" in order to get me in legal trouble.

That's what the second part is meant to address. The idea is that the US will enter into agreements saying "fair's fair, both your and our police can demand data regarding our respective citizens when our respective privacy laws allow for it".

Good enough to have available as an option, for people who want to scrimp and save for a bit while they ramp up their careers. Not good enough to push people into one long term.

I'm not sure there ever was such a social contract, since the personal space you're describing is a very modern innovation. As late as the 60s, all offices were open plan offices, and single-room occupancy was simply what you got on the cheaper end of the urban housing market.

Right, but thread pools are simple because they don't offer any sort of API for the tasks in the work queue. You're just writing arbitrary code. So rather than reasoning about an abstract execution model, you have to carefully think about every line to make sure you don't accidentally share mutable state.

Futures aren't a natural way to formulate many important concurrency problems. If I want a thread polling an external system and putting records in a work queue for as long as my application is running... well, what's that a future of?

If you can't make yourself understood to the average engineer at a company, I think it's fair to say there's not a good fit between you and the company.

Ensuring deployments are "predictable, routine affairs that can be performed on demand at any time" isn't just a generic business process problem. It imposes significant constraints on how code has to be written and tested.

These are not unrelated observations! The same people who expressed disbelief that your UI is temperamental will react the same way if Slack releases a temperamental UI.

The difference is that they don't work in the same office as Slack. They'll never hear about all the important, completely justified reasons Slack decided to release a bad UI. They'll just notice it happened, and conclude that Slack must hire incompetent UI developers who didn't realize it was bad. Any product with a large customer base has to be pathologically averse to things like this.

I'd definitely believe that every part of query execution is in the hot path, as this paper describes. But most code in any reasonable DB system isn't part of query execution.

Even in a database, most of the code isn't performance sensitive. Making your life a bit harder in the fast path so it's easier in the slow path is at least a tradeoff worth considering.

Dependency injection is a very specific way of passing in data to the constructor. In fact, those specifics are one of the important lessons of dependency injection; it makes a big difference whether your constructor accepts parameters for a database connection or a database connection itself.

Not right; you can't just review the specs of each system. It's very easy to accidentally combine compliant systems in a way that isn't compliant.

Just to pick one example I've seen in practice, system A might have an integration bug causing system B to periodically emit error logs, containing data which system A knows is personal but system B does not.

I'm not sure what you mean by "holes". It seems like it's a fundamental and intended feature of the GDPR that you can't achieve compliance-by-default. You have to explicitly audit every interaction between every system you have, to ensure that either no personal information is present or the interaction complies with GDPR standards.

In many simple cases, Heroku is effectively serverless. But there are situations (in particular monitoring and billing) where you're forced to think about the individual dynos your app is running on.

It seems like a pretty good name to me. The point of the term "serverless" is that you aren't presented with any abstraction of a server; operations like "spin up more servers to handle the load" or "SSH to the server to figure out what's going on" or "reboot the server because it's acting weird" don't exist for you.

The term does get abused to refer to any server cluster with a bit of autoscaling logic, and in that sense it is a misnomer. But I don't think that's what it originally meant.

Right, but this doesn't seem to describe what happened here. Before Amazon moved in, people in San Bernadino weren't working for efficient businesses paying great wages; they just didn't work.

How long should we have kept them unemployed to wait for a new high-paying business to show up?

Does Amazon offer a significantly worse deal to its warehouse staff than Walmart? My impression is that it doesn't, so I don't think this is a problem with tech companies specifically.

Is there? Amazon's retail business runs on a razor-thin profit margin, and in fact Amazon was famous for not being profitable until a few years ago.

You can want transparency all you want, but you're not going to get it. I guarantee that, in any large for-profit software product you use, the devs know of at least one unprivileged read bug which they will not disclose.

I doubt that anyone on the business side considers it uncool to build a small but profitable company. It's definitely cooler than having a VC shove you along the path to an acquisition by BigCorp Ltd.

Engineers sometimes consider those companies uncool, but that's just because they usually can't pay market rate for the best engineers.

Partitioning the S3 bucket scheme is terribly complicated. The senders have to know exactly how every receiver is partitioned, so they can adopt a compatible partitioning scheme when writing to S3. And the receivers have to know exactly how the senders are partitioned, so they can divvy up incoming data appropriately.

Correct. The lawyer in this case asked for permission to withdraw, and the court wouldn't let him. (The court wouldn't agree to reschedule the case, and the defendant neither found another lawyer nor agreed to waive his right to a lawyer.)

In Canada, like in the US, warrants have to be specific about what exactly the police are looking for. If the warrant really was "give us all your data so we can see if you're hiding something", that's not legally okay, and I can't blame them for trying to prevent the disclosure.

In my experience, projects which try to follow that strategy inevitably end up with a handful of core libraries containing 90% of active development. The incentive gradient doesn't work; if a project is time-sensitive, the developer just won't agree to do twice as much work to maintain separation of responsibilities.