Hacker News Reader

Comment by bbarn | Hacker News Reader

I had a developer that I inherited from a previous manager some years ago. Made tons of excuses about his machine, the complexity of the problem, etc. I offered to check his machine out and he refused because it had "private stuff" on it. He had the same machine as the rest of the team, so since he hadn't made a commit in two weeks on a relatively simple problem, refused help from anyone, etc., we ultimately let him go.

When we looked at his PC to see if there was anything useful from the project, his browser had around a thousand tabs open. Probably 80% of them were duplicates of other tabs, linking to the same couple stack overflow and C# sites for really basic stuff. The other 20% were... definitely "private stuff".

View on HN

I’m at the other extreme of “private stuff”. Nothing work related should live on my work machine. It should all be pushed to git or dumped in the wiki (personal pages if nothing else).

On one of my largest projects the IT dept made bulk orders for hardware and doled them out to new hires. 18 months into our new project someone’s hard drive died.

Everyone acted like his dog died. I said no problem let’s go through the onboarding docs. The longest step by far was that the company mandated Whole Disk Encryption but IT hadn’t put it in their old inventory yet. So that was 2/3 of setup time. We found some issues with the docs and fixed them.

Every two to four weeks that summer, someone else’s drive would go. You see, we got all of these machines from the same production run. So the hard drives came from the same production run, which was apparently faulty. The process got a little faster as we went. By the end of the summer it was my turn, and people still looked at me like I needed condolences. I got a faster machine for a few hours worth of work. I’m not sad. All my stuff was in the network already. I lost a couple hours’ of work, tops.

> Nothing work related should live on my work machine.

I thought this was a typo at first. Love this as an engineering koan.

And the corollary – nothing personal should be on your work machine, either

"Nothing work related should live ONLY on my work machine." is the intent.

This is the best way to reduce bus factor and not fall behind documenting key details!

Apologies for the pedantry but reducing bus factor is a bad thing.

3 -> 2 means you now only need two people to be hit by buses to ruin your project.

Any machine in a company needs to be able to be unplugged and thrown out of a window, without leading to significant data loss, only the inconvenience of the price of a new machine and setup time.

There are very few machines in the world that are actually mission critical, and you might not be able to do that (although for them, you can probably switch components with it still running). Anybody else, you are just betting your company on the lack of fires, hardware failure, etc.

My company laptop I don’t do anything I wouldn’t be OK with my manager or IT seeing. Even something as simple as a recipe lookup I do on my phone or personal laptop.

With today’s software for managing corporate machines, and corporate VPN with network security and firewalls abound, anything and everything can be seen.

I have a joke Wi-Fi name that I’ve even considered changing (or at least create a guest network) just to be safe. It’s likely overboard, but I like the idea of just mailing my laptop if I change companies, and no worries at all

Coincidentally I just got a new work machine this week. The IT support staff replacing it scheduled an hour of time to transfer files, set up apps, etc. with me. I was done in 5 minutes. Once I logged in, logged into my cloud services, and verified my faulty port problem with my dock was resolved with new hardware, I was done and as productive in a few minutes as I was before. Install a few tools, copy my scripts from the cloud, make a new key pair for SCM, that's it.

> he refused because it had "private stuff" on it.

There's a huge red flag. "Private stuff" (embarrassing or otherwise) shouldn't be on company machines in the first place.

I agree completely.

However if anyone touches my computer: don't you dare f*%king touch my private key.

(ditto for my browsers sessions database, google cloud credentials directory etc;)

I'm paranoid about it, but not enough to buy a yubikey, apparently.

> However if anyone touches my computer: don't you dare f*%king touch my private key.

Touch the computer, sure, but please don’t touch the screen with your filthy grease fingers.

My work laptop has a touchscreen. I've never used it, but other people use it by accident fairly often. Usually only once each though, the look of shock is sometimes even worth the fingerprint :D

I've never understood people who do this. You can point at the screen, tap with a pen, take the mouse or keyboard and move the cursor, etc. but surely it's bad manners to splodge your finger on someone's screen.

I'm unusually strict about maintaining a separation between work and personal (for instance, I would never allow my personal smartphone to connect to my employer's WiFi), so I wouldn't use personal keys on a work machine at all.

But if those keys (or passwords, etc.) are generated for work purposes, I consider them to be as much company property as the machine itself, so I'm no more protective of them than I am of any other sensitive company data.

Interesting thought.

How do you feel about giving your colleague your password?

My personal opinion is that I can hold someone legally culpable if their account does something like leak financial information; you have a professional responsibility to secure your account from absolutely everyone.

Administrators acting on your account must of course be heavily logged and audited, which is the case.

> How do you feel about giving your colleague your password?

I usually don't, mostly just out of good security habits, but also because most employers specifically prohibit doing that.

Almost always, your colleague can be given his own access to whatever the password is for anyway. If that's not possible, then I'll share the password and change it immediately after my colleague doesn't need access anymore.

> you have a professional responsibility to secure your account from absolutely everyone.

I agree -- that's part of treating credentials the same way as all other sensitive company data. But it's still my employer's data, not mine.

If I quit the company or if my supervisor wants to see the contents of my machine, I'm fine with that. The machine and everything on it belongs to the company anyway.

Ok, but your private key, session tokens and CLI access tokens (kube configs, gcloud etc;) are your password in those situations.

They tie to your identity, thus you must not treat them the same as company secrets, they are professional personal secrets which should not be disclosed or allowed to fall into anyone elses hands (less they be revoked and cycled).

It's not just good security posture it could affect your career quite badly or lead to legal issues.

I agree. I don't think I've said anything counter to that (or perhaps I wasn't being clear?)

> thus you must not treat them the same as company secrets, they are professional personal secrets

They are company secrets that are tied to my identity. The company owns those secrets, not me. Just like my keycard to get into the building.

> I agree. I don't think I've said anything counter to that (or perhaps I wasn't being clear?)

I think given the context of the thread (don't touch my secrets), saying that you don't have anything you would consider confidential towards your employer or colleagues is a direct contradiction to what I stated.

That's why I'm "arguing" because my employer/colleagues should not have access to my private key, ever.

Ah, OK. Then we do disagree to an extent.

There are several very legitimate times when my employer needs to have access to my keys. If I'm leaving the company, for an obvious instance.

But my core point is that such keys/passwords aren't really mine, they're the company's and in the end, the company gets to decide what I'm to do with them.

I think the building access keycard is a perfect analogy. I'd never let anyone borrow mine on my own volition, but if the company wants to retrieve it from me, that's their prerogative. It's theirs, after all.

If an employer needs someone’s particular keys something probably went wrong or there’s bad processes in place. But that aside I think the default course of action should be to aggressively guard your secrets and tokens since they represent you. Not as personal or private property but to keep someone (be it a fellow employee or a 3rd party attacker) from impersonating you without authorization.

There are exceptions but the circumstances where an employer would need to retrieve my keys without my assistance are extremely rare and in those instances it’s unlikely I’d still be an employee anyway.

We disagree.

The handing of the keycard is necessary to ensure it's destroyed and can't be used as a "proof" you work somewhere (most access cards these days have your name, face and the company logo printed on the front).

The keycard will be removed from the access list to the building even when it's destroyed, they're not considered reusable by most companies.

Your private key is not reusable, it should be destroyed and revoked from all system when you leave a company.

We could destroy the keycard with both parties present, that seems safest. I don't mind turning in a private key permanently and getting a receipt at the time, but it needs to be very clear that it's no longer my responsibility.

I’m not clear how we’re in disagreement here since I agree with this. When I say your keys/creds should be guarded I mean while they’re still valid.

i replied to you and not the parent by accident. sorry.

No worries!

> but to keep someone (be it a fellow employee or a 3rd party attacker) from impersonating you without authorization.

Aside from a third party attacker (which is well-covered by my normal practices), that's a threat model that I'm personally not worried about at all, really. In part because I've never seen or heard of that happening and in part because if it did, I am confident that there are enough records to be able to prove it.

Internal abuse and attacks aren’t as rare as they should be. You’d be amazed what someone will do to risk their job or even career on impulse or poorly considered risks.

Isn't this largely the point of company directory services? The machines/routers/applications/etc are all doing their authentication against the directory service, and permissions are granted and revoked there. Its a large part of running a company with more than a couple employees because when someone leaves you don't need to run around changing passwords and wondering if they still have access to the AWS account to spin stuff up, or punch through the VPN. The account in the directory service is just deactivated and with it all access.

By default this should be what is happening on all but the most ephemeral of machines/testing platforms/etc. And even then if its a formal testing system it should probably be integrated too.

Directory service integration BTW is the one feature that clearly delineates enterprise products from the rest.

> If I quit the company or if my supervisor wants to see the contents of my machine, I'm fine with that. The machine and everything on it belongs to the company anyway.

I'm fine with that, but I still will not share my passwords. I'd be happy to reset the passwords for them if they can't access the data by other means, but as another commenter pointed out, the fact that anything needs to be recovered from my^H^H not my laptop indicates mistakes were made.

He was let go after two weeks? No confrontation nothing?

Sounds very american. In European working culture if you don't show up for two weeks people will be worried that something happened to you and try to work it out with you. This type of all or nothing reaction is a bit sporadic imo.

Sounds very american.

Yeah, it's not like that part of the story was condensed and might have left out a bunch of details that weren't important to the story. So let's give OP a hard time and make judgements about a situation for which we have not even the slightest bit of context.

Oh absolutely, you're right. I am saying that despite whatever may have happened, two weeks is very short. I feel like it would be at least a month here regardless.

It's not that the person didn't show up for two weeks, though; they showed up but refused to actually do any work.

For context, I was brought in with the knowledge he hadn't done anything meaningful since being hired some time before my arrival, and we did reach out and offer help or ask if he needed anything, which he refused, somewhat angrily.

He was let go after two weeks of not doing any work, despite the manager offering to help him.

You might have meant to use a word other than "sporadic." That word describes a recurring event that happens at unpredictable intervals, such as snow in a normally hot desert, or a Linux crash caused by a race condition. Other words that fit the sentence better are "unusual," "unexpected," "unjustified," "inappropriate," "surprising," "extreme," "abrupt," or "out of the blue."

(For what it's worth, I'm American, and I disagree with your assessment. We don't know how long the person was given to make progress, and we don't know what was communicated. To conclude that a two-week period without a commit represents the entire period between the start of the poor performance and the termination is, well, a bit out of the blue.)

I was the final two weeks of a long period of zero productivity, despite many offers of help and asking if he understood, needed help, etc. I never enjoy firing someone, even if they are downright awful or mean, and do my best to avoid it. My own involvement was late in the stage, and the thousand or so tabs that were left open I'm sure weren't 2 weeks worth of effort.

When I was hired I was told he was a problematic hire, that hadn't produced anything for long before my arrival. It was basically "We already know we're going to probably have to let him go but if you want to try to work around it, be my guest". I did try to go in with no judgments, as I always do, but he refused help, and refused to even let anyone look over his shoulder and find why this task was taking an order of magnitude too long.

Reply on news.ycombinator.com