Kalium

The GS schedule has location adjustments. They don't always keep up with the actual cost of living in a location. The NYC area means there's a 37% boost to pay, but NYC is not just 37% more expensive to live in than baseline.

For delivering strict network access controls, a clear audit trail at multiple points, and (at a guess) the usage of very temporary credentials to actually log in, yes. Especially if the same infrastructure is used for other, less SaaS-centric data handling tasks or users are in places that like to mandate access to geo-local data (India, China, etc.).

Security measures in operational workflows are only a little bit about what the end user - you - sees. Generally they're really about delivering something less obviously visible to the user but very valuable to the business, investors, and regulators.

Google/Alphabet is willing to mandate - and then enforce - sweeping changes. When they shifted to U2F and forced everyone to use it, phishing all but vanished as an ongoing problem. I don't know if Microsoft is capable of that, technologically or culturally.

You're describing what's popularly known as a "security champion" program. The problem is you're giving a little bit of training and authority to someone who is primarily accountable for marketing/dev/whatever. At best, this sets up a conflict of interest that the person will occasionally navigate successfully. At worst, they now know enough to be even more dangerous.

The problem isn't just knowledge. The problem is getting people to use that knowledge to push back on bad ideas.

You're absolutely right. The token is clunky.

The rest - a VPN to a virtual desktop - is entirely reasonable.

Yes. Generally it can be summarized as "What data security?".

Snark aside, there's usually a reflexive assumption that more data is always better and that anything that gets in the way of more data is bad. Anything that limits how data is analyzed is bad. Anything that limits or restricts their choice of tooling or where they use it is rejected.

Data scientists and engineers are people who are, often, working with a company's crown jewels. They are trusted with data representing the private lives of hundreds of millions of people assembled in a data warehouse. I want them to have a care. To treat this with due gravitas. All too often, all they seem to see is a neat data set to feed into R on their Macbook.

In theory, there are documents out there a startup can read, understand, and follow to get reasonable outcomes. Theory is a wonderful place, I'm told. I'd like to visit someday.

In practice, the answer is to hire a consultancy. There are fractional CISO services out there. It's very likely that a startup without significant security experience in-house does not have the expertise to make good use of any guidance they can find. Every scenario is too specific, every personality dynamic too unique, and every new technology question too novel for there to be easy pre-fab answers that a non-security-practioner can find, understand, and apply in a correct and consistent manner.

As a security person trying to work with marketing and data engineering teams, I've often found them very resistant to learning how to secure things. They generally want to use the tools they know, in the way they know, to do the tasks they understand, on a timeline they find convenient.

Anything that tries to get them to understand the risks they are taking or the sensitivity of the data, much less de-risk their workflows, is treated as an obstacle to be routed around. Often, the best I can hope for is a token effort at negotiation where their goal will be to avoid any and all changes on their part. After which I will have to monitor them carefully, because from experience the odds of them backsliding within a week are uncomfortably high.

Nothing about this is conducive to producing a healthy environment. When people's idea of "easy" is they can download the company's most sensitive data to their laptop to load into Jupyter, any amount of security controls will come as an imposition.

Once they're convinced it's the fastest and easiest way to have a wordpress instance they can publish to as they please, they most certainly are. Or, as in the example, they get the idea that having a database they can analyze will unlock key insights that will drive market share.

It doesn't matter if any of this is true. What matters is they believe it and it leaves them feeling empowered enough to invest.

Making doing things right has to be easy. You also need excellent monitoring, because it's inevitable someone will do something else no matter how easy.

There are plenty of people and teams who just want a button to push to run their build. That's not so hard. Give them a CI/CD system and they'll use it.

The problem becomes the people who want to use weird, wildly divergent build processes made of fifteen shell scripts strung together and downloading arbitrary content from random remote servers because they enjoyed engineering it. They'll insist on having a blank slate of a cloud tenancy because no build system can meet their needs. The CI/CD team does not take this case seriously and will never meaningfully support it. Security is in no way staffed to build out a major extension of the CI/CD service.

Perhaps it's the data team, who has decided they would like to datamine large quantities of private information at their leisure, in contravention of privacy policies and contractual language. So they'll jump through hoops and contortions and share passwords every which way in order to do the thing they want. They will deliberately set out to disable monitoring systems because they resent the implications. At no point will they pause to consider if any of this is a good idea.

It's not just about making it easy to be secure. It's also about being able to find and stop people being insecure. One of the important things a security policy - and security organization - does is set boundaries for what activity is and isn't permitted. Crossing those boundaries needs to be watched closely... and yes, punished.

That's only possible when the regulatory environment allows it. If your insurance regulators won't allow that kind of flexibility, then they have to look for other options.

This is often approached through the lens of consumer protection. As a result, making thing flexible to allow insurance companies to say "Hey, you really need a new roof, but if you choose not to here's the price of that risk" is not prioritized. Approving rate increases is.

In the US, it's a requirement of mortgage lenders. This makes it less of a legal requirement and more of a de facto requirement, as most homes are purchased via mortgage in the US.

At the risk of being callous, the goal of home insurance is to assess and manage risk. Choosing ignorance in the interests of giving some people a subsidy on the assumption that they may be poorer does not further these goals in any way I can see.

If the goal is redistribution, then using accurate risk data as a starting point seems preferable.

> Also. No matter how bullish you are on the potential of AI, it's horrifying and categorically unethical to use them to decide who to kill. It creates the possibility of atrocity with no accountability.

How much technology is it ethical to use in the decision-making loop for kinetic decisions? I don't think there's an easy answer here that actually engages meaningfully with the question.

I believe you may have overlooked one of my key points: we did not have any useful way to predict those consequences at the time production was being automated that would have marked them out as particularly likely.

Automation started in the 1780s, with the industrial revolution. The initial impacts had a lot to do with creating vast numbers of jobs, driving down the cost of all kinds of consumer goods, and heavily driving urbanization. I can't see any easy way to get from there to the rust belt if I'm someone looking forward in 1780. Right now we can treat this as obvious only because we have the benefit of hindsight. I cannot imagine any way in which the modern history of Detroit would have been reasonably and usefully predictable from 1780 (at the time it was a frontier fort under British military control).

You're right, impacts can be decades off. They can even be centuries off. There were a lot of equally credible people who thought automation was going to have utopian consequences that didn't include people losing their productive economic positions. This isn't a binary, either. There were plenty of other possible outcomes as well. How were people in 1780 to know what we do know? What happens if every predicted outcome is taken seriously? What happens if they're then all wrong, or not right on a sufficient timescale? I know how I would expect that to interact with limited government resources.

At the end of it, I think we're likely limited to dealing with consequences and trivially short-term prediction. Those, at least, we have a reasonable shot of observing.

To clarify, I am not saying blowback is completely unpredictable. You are absolutely right that there are times when blowback can be predicted in a general sense. My argument is that a general directionality of blowback is generally not useful for crafting policy.

You're completely right that it was easy to predict that there would be some consequences to automation and people losing their jobs. Yet I do not think it was easy to predict what shape those would take. As a result, it was functionally impossible to offer useful policy measures. You can say "We should reform society away from believing productivity is king and self-worth is tied to employment", but that's itself not specific enough to be useful. "This may lead to a crisis in society" is similarly rather non-specific. How do you craft policy around "this may lead to a crisis"?

In practice, I see two recurring patterns when people try to predict blowback. First, people use fears of blowback to launder their anxieties. If you look at the conversation around AI, you will see this happening in many forms.

Second, people often use predictions about blowback to advance policies they wanted anyway. Artists want to be hired more and stronger intellectual property laws, the same things they wanted yesterday. Advocates for saving small towns in the rust belt will suggest the same retaining and social safety net policies they suggested yesterday before anyone asked them to predict blowback.

In my opinion, these two patterns are deeply linked. They are both about trying to turn confirmation bias into policy. None of the answers from this are automatically wrong, but none of them are novel. Most worryingly, neither approach offers any kind of way to reliably predict blowback so it can be dealt with via policy.

In my career, I've seen any number of engineering teams devote significant time and effort to trying to solve technical problems that never arose. Not because they were solved in advance, but because the team's predictions about where issues would arise were wildly incorrect. From this, I have drawn the lesson that we are well-advised to approach the task of trying to predict failure in complex systems with deep humility.

The more complex the system, the more humble we need to be. At some point, trying to make any prediction more specific than "something will probably go wrong" becomes a poor use of time.

This is neither the Luddite case nor the techno-optimist case. It's an argument to be skeptical of our own ability to make good predictions about the future except in, as you wisely and correctly say, very general ways.

Automating knowledge work is what enables people to learn from books instead of hiring tutors. Teaching can now be done via tools and printing presses. This in turn means we can have libraries, which many people consider a key public good.

It's perhaps worth pausing to consider if we have any kind of useful ability to predict blowback on anything but a trivial scale. It was fifteen years between the invention of HTTP and the creation of Facebook. It was twenty five years between the invention of HTTP and the Cambridge Analytica breach. I do not think any person could have meaningfully predicted those on those timescales.

If we cannot currently usefully predict blowback, then what reason is there to try to anticipate it as a matter of policy?

I'm doing my best to tell this user that their imagination is possibly on to something, but mostly this is a waste of energy. I'm exaggerating the realistic possibilities to help them feel good about themselves because it makes it easier to sneak in the idea that this is not a useful or productive line of thought.

The approach of "Smart people have thought of that, there are very few chemically useful alternatives" is the kind of thing that entrenches a person in their insistence that this is just a wide-scale failure of imagination. Witness their comment about "earthlike biology perspective". They want to believe a wider, weirder universe is possible. As a rule, it helps people feel heard to tell them they're right about something.

So yes. I'm going to present it as a staunch certainty that something else is possible but currently unknowable, invisible, and irrelevant. I'm doing this in the hopes that the message gets through that this is not simply parochialist arrogance at work, from which they might nobly dissent.

Yes.

You're right. Absolutely, completely correct. There's almost certainly other ways life can start. Other processes that can result in intelligence. Other paths of technological development.

The issue, as I understand is, is that all of those are completely unknown. We have absolutely no useful idea of how to look for wildly different life in places we haven't thought to look.

What we do know with certainty is that Earth's chemistry can result in life. We do know that it can result in intelligence. We do know what paths our technological development took. We even have some idea what these things might look like from afar. All together, we have exactly one data point that lets us search for similar data points.

Are there other, different world, with different life? Very possibly. We humans are well aware of this. We just don't have a way of knowing if we've found anything. So as a matter of managing limited resources, there's a tendency to stick to what we know can work.

It doesn't have to be deliberate. For a lot of people, aggression is their immediate defensive response.

If your entire life is based around your car, it's your most important and powerful symbol of autonomy, wealth, and personal liberty. The prospect of someone in government deciding one day that the life you live is no longer welcome and your touchstone is evil is incredibly jarring, at the very least.

If you also live in an area where you cannot imagine how you could possibly live without using your car frequently, the prospect of a car-free city sounds a lot like you're being hung out to dry by people who don't care what happens to you.

These reactions are a combination of poor messaging by those affecting change and a failure of a imagination by the car-bound. The first, at least, is avoidable.

The classic example of admissions does not have a missing confounding variable. It's a case of aggregation at the wrong level.

It's my experience that housing exists on a spectrum, rather than being strictly for business or tourism or long-term living. Any space that could rent furnished apartments by the week to business travelers could also be renting unfurnished by the year to residents. I've seen hotels turned into apartments and the reverse.

Housing, like money, is often fungible. It's not something we should expect to strictly classify away into wildly different categories in every case, even if this is pretty convenient from a governance perspective.

Depending on what you're doing, a hotel can be a poor fit for your needs. I've spent weeks in hotels at once, and for me it got absolutely miserable quickly. A studio apartment instead was much, much better.

That might work if your company hired the pen testers, it's a lot less likely to work if they were hired by a client. In the latter case, the overhead of all the required explanation and smoothing of ruffled feathers for the client likely costs a lot more than implementing the stupid timeout in the first place.

Pen testers are often very resistant to pushback. They get it a lot, and usually on things that are real concerns.

Have a solid value proposition and communicate it clearly to potential customers. Do this consistently over time, and customers will find you quickly when they need you.

My possessions were not nationalized at least a dozen times yesterday. It hasn't changed my behavior much, nor that of any company worth mentioning. Perhaps your life has been different from mine.

The absence of a major punishment is not a strong reward. It provides no incentives except to avoid the specific things that produce that punishment.

> Google search was incredible? Ad sense let publishers earn money online? Great. Then let's reward them for that instead of letting them take 60-70% of the ad publishing market.

This one sticks out among your examples - that dominant position and the profits from it is the reward. How else would you have a reward work?

This isn't an idle question. Right now companies are doing things that generate their own financial rewards. What other way would you have it work, beyond just some notion of differently?

Yes, assuming the responses are usefully different, accurate, and you get responses in a timely manner.

Yes and no.

Yes, with the additions of sheer scale, a vast number of services, multiple layers, and the difficulty of defining "down" added in. I think the difficulty of reporting useful error messages is proportional to the number of places an error can reasonably happen and the number of connections it can happen over, and by any metric Meta's got a lot of those.

No, in that detecting when you should be reporting a useful error message is itself a complex problem. If a service you call gives you a nonsense response, what do you surface to the user? If a service times out, what do you report? How do you do all this without confusing, intimidating, and terrifying users to whom the phrase "service timeout" is technobabble?