Hacker News Reader

Comment by hnick | Hacker News Reader

> The issue is that all the policy documents often only contain the One True Way to achieve their goals, while the goals remain unstated. The documents should always come with a rationale.

A reason can be argued against while a policy must just be followed. It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them. Much like when web companies disable your account and won't say exactly why. Not gonna take the risk you prove them wrong, are they?

It would be nice though if all laws had a purpose included.

View on HN

Or policy writers copy n pasted something off web.

In my Mega Tech corp, we have security team that has created hodge podge of conflicting policies. For example, they ask some applications to be internal network only and other are accessible via web. But they can never provide their reasoning and get annoyed when we ask any details.

The worst part is that some of their policies directly contradict with each other. For example, policy is to never run as root inside docker container but then there are some applications provided by them that runs as root in docker. And every time you use it, you have to remind them that these are their apps or else they will ask you to stop running it as root.

Finally, I had pleasure of talking with one of their Security and Compliance expert. They could not even knew how to list file perms in Linux, and other a lot of basic ideas. This person clearly had memorized interview questions but had clearly no understanding of those concepts.

Only way to hide their incompetence is act elite and don't explain their reasoning.

> Or policy writers copy n pasted something off web.

The fact that policy sponsors are more than anything looking to a single answer to end debate and establish uniformity is why policy writers can copy and paste stuff from the web and get it adopted as policy without a clear rationale connected to the organization’s particular circumstances. They aren't conflicting, alternative explanations.

> It's probably by design, because as soon as you put a reason that becomes a target and people start to get ideas about why it doesn't apply to them.

There's more to it than that. There are two separate groups of reasons:

1. The reasons a policy was put in place. ("Why did we do this?")

2. The reasons a policy succeeds. ("Why is this a good idea?")

You can know the reasons in group 1. But nobody cares about those. What matters are the group 2 reasons, and they were probably never known in the first place.

I was working in a throughout computing problem domain. About the time I got there, some asshole in HR had everyone’s (current and former employees) tax information on their work laptop and lost it. Tens of thousands of people, because there was no policy against putting such information on portable equipment.

And as far as I’m aware there still isn’t. No, within the year (might have been a lawsuit, I can’t recall) new policy became everyone’s machine has whole disk encryption. Including engineering. So my software was instantly 30% slower, and a half a day added to setting up any new machine. I don’t know how many times I had to explain that it’s not our code that got slower, the whole company got slower. It took me months of work to get us back to zero.

That person should have been run off and anyone in their dept caught doing the same should have been put on probation. I don’t know how you figure that it’s “fair” for everyone to suffer for the mistakes of one member. In a small team setting? Perhaps. But not for something like this.

Thinking about the policy in terms of punishments and fairness isn’t the right approach. Something happened that cost the company a great deal of resources, so the company is trying to prevent such a thing from happening again.

It may be doing a poor job at that, but it isn’t punishing you and it isn’t about fairness. It’s trying to prevent a future mistake. And because the company is a single entity, it is the company choosing to bear the cost.

It may make your job harder and they may not modify its expectations properly after imposing this cost on you, but that isn’t punishment or fairness. It is poorly thought out systems.

"Something must be done. This is something, so we will do it."

so your job involved none of the company's IP?

I don't know if encryption was the right policy response here (it seems to be a very good idea regardless due to theft/hacking possibilities), but I'm OK with this sort of policy sometimes.

Full disk encryption is a fair response because it won't be feasible to enumerate every type of situation that results in sensitive data being put on the laptop (such as temporary files or source code). If someone was going to just add tax numbers to a list it leaves a lot out; if they say "sensitive data" it leaves a lot open to interpretation; if they list everything they can think of it'll be impossible to properly comply while still getting work done.

So perhaps it was a heavy handed approach handed down mindlessly, but it could also have been someone looking at the bigger picture. Knowing the intent as others said would help.

You act like this policy was intended as punishment instead of as risk mitigation.

Mandating full disk encryption is easy for IT to enforce. A policy of not putting sensitive information on laptops is valuable, but difficult to enforce. Encryption is a sound way to reduce the risk of harm when that policy is inevitably broken.

Full disk encryption also been the company-wide policy of everywhere I've worked in recent memory, fwiw.

I’d add another that’s nice to have:

3. The outcome we expect. (“What will happen if this is working.”)

How does that differ from choice #1, 'The reasons a policy was put in place. ("Why did we do this?")'?

A policy's expected outcome is correlated with why a policy was put in place.

A policy might be put into place because a single event. The expected outcome can drastically differ depending on who writes the policy. E.g. it could be "this type of attack won't succeed again" vs. "even if this or a similar kind of attack succeeds it won't expose our entire data"

That's my exact point. A policy isn't random but created for an effect.

As an examnple: If an HN disclosure leaks passwords and email addresses into the public domain, imposing a policy control is _meant_ to have the effect that such a disclosure would not happen again, or if it does to have a limited scope.

On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.

> On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.

Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook.

This seems like one of those areas where there are unavoidable tradeoffs:

* clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas.

* clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions.

* policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.

You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.

> You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception.

That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.

I'd explain why you're misconceiving the tradeoff, but we have a policy against omitting policy rationales, and that's that. ;)

>Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.

Well, it's supposed to only be a handful: the handful of people who know more than the policymaker.

> You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception

Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU.

That's not a motivation that policy sponsors usually want in print, though.

It’s almost as if there is no single technique for reaching all members of a target audience...

You need two documents, minimum. One with rules, others to justify them.

I think it depends on the person. For myself (and probably many people with the hacker mindset), I don't like useless rules and want a justification or I tend to think I "know better" which is of course sometimes true and sometimes not.

I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own.

A lot of people don't care either way, rules make life simple so there's no need to complicate it further.

> On the other hand, a reason can convince people,

Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.

> A reason can be argued against while a policy must just be followed.

And if you talk to people directing policy efforts (who are often not the ones writing, or even actively choosing, policy but generally are the ones formally signing off), you often don't have to dig very far to find that settling discussions is as important of a rationale for the policy as any of the others. This obviously conflicts with ideals like continuous improvement, but it's true lots of places including those with nominal commitments to continuous improvement.

Reply on news.ycombinator.com