Hacker News Reader

Comment by Touche | Hacker News Reader

Prefixing this by saying I am not siding with Google (since people make assumptions). The standard approval process sounds like most merge review processes on any engineering team. There's a sort of assumed good-faith for this process. The fact that 2 coworkers were fine with your change doesn't mean it was made in good-faith and was within the bounds of normal types of changes.

Any engineer with the freedom to make changes without manager approval knows that adding features or making major changes isn't not the sort of thing you just do on your own. You'd go through another process for that.

So I don't buy this argument at all. This was a knowing violation. That does not, however, mean that they punishment was warranted, I don't think that it was.

View on HN

Yeah let's be real, if she programmed a popup to appear over twitter with a message like "Don't slack off dummy UwU" and or something equally ill informed she would have been rebuked at worst.

To say that it wasn't the union overtones that got her fired is naive.

I know 0 large companies who would tolerate what you just described from a security team member.

She’s young and probably a bit naive. I think it’s absolutely a reprimand-worthy offence, and I certainly understand that a security engineer maybe shouldn’t inject code like she did, but that’s why there are reviewers, but they ok’d it. I don’t think it’s something she should have been fired over. I made dumb mistakes early in my career too, after all.

Should she have done it? No, absolutely not. Not like that anyway. Should she have been reprimanded? Yes definitely. Should she have been fired? I don’t think so personally, not for a first time mistake at least (we don’t know if she did other things previously or not, of course)

Different viewing angle needed but Google does similar stuff themselves, e.g:

    On Google.com if you present a Vivaldi user agent and arrive via a redirect, the search text box will be misaligned
    On Google Docs if you present a Vivaldi user agent you will receive a warning

https://vivaldi.com/de/blog/user-agent-changes/

Probably a bit naive?

Security tools, and especially extensions that run with full browser access, are in an exceptionally trusted position. Employees who can inject code into arbitrary websites can in effect get administrator access to anything in the company, as Google is run almost entirely off of web apps of various kinds. It's actually hard to get more trusted than that: without a doubt this woman effectively had a greater level of access than Sundar Pichai or other senior executives.

If there's one thing you don't screw around with in any firm, its mis-using administrator access. Mis-use here means doing things that aren't related to your job description. You just don't do it! What she did would be like a logs engineer deleting internal access logs to cover up activity by political allies, or a GMail engineer spying on conversations between executives. It's complete madness to think you can abuse such a high level of trust in such a direct way and get away with it!

I used to have a certain type of Google account system administrator access. The way I used it was watched very closely, and deservedly so. Eventually it was removed because Google built better security systems that could restrict employee access more, and in my team were happy about this (for one, it meant we were less likely to be hacking targets). The idea of anyone abusing this sort of access for political reasons was unthinkable.

I honestly can't believe people here are defending this kind of behaviour. If Googlers feel it's OK to abuse root@chrome for unionisation related purposes, what else might they start doing? What about people perceived as 'bad'? Google needs to explain what happened here pronto, because apparently she was able to get this change through code review? So she had internal allies who approved her abuse of access? That is tremendously worrying.

Google is very rapidly burning the trust it requires for its business models to function. How can anyone trust the firm when 21 year old activists are able to manipulate Chrome for political causes and Google's own security procedures are unable to stop them?

This is reprimanding for the content of the message, not the scope of the code which would have actual security implications. Furthermore, it is a warning about not violating an actual company policy. This is not far off from the scope this pop-up tool is designed for. While it is clear that this was done as a response to google hiring this firm to dissuade folks from organizing, I could argue that it could be done to warn managers not to use the firms presence as permission to violate a specific policy + law. IANAL but this seems like extremely grey legal area. For example, this could be aimed at managers to remind them that even though this firm is hired, they cannot enforce a ban on organization according to that specific policy in the handbook. I think that's an appropriate use IMO, it would save the company some serious money and headache if it stopped a manager from illegally retaliating against organization.

I would not characterize this as evidence that this person is a security risk. It takes existing culture of google, including past incidents like changing the default desktop wallpaper for a protest that was happening, etc.

Also if this is true it is totally insane. Sounds like intimidation tactics to stop exactly what the pop-up warned against.

> They also dragged me into three separate interrogations with very little warning each time. I was interrogated about separate other organizing activities, and asked (eight times) if I had an intention to disrupt the workplace. The interrogations were extremely aggressive and illegal. They wouldn’t let me consult with anyone, including a lawyer, and relentlessly pressured me to incriminate myself and any coworkers I had talked to about exercising my rights at work.

I think you're assuming it's related to the message content, but that's not what Google are saying and it's not how corporations work in my experience. How you do something matters a great deal in any large bureaucracy. If Spiers wanted to remind people they could unionise there are communication systems that exist for people to talk to each other on their own initiative without approval, systems like email or even memegen.

Modifying the behaviour of people's web browsers isn't a channel intended for employees to push personal messages to each other and this should have been really obvious to her. She and her colleagues were trusted with a tremendous amount of power which could be readily abused (see my other comment on this thread), and the expectation was clear that it'd be used only within the bounds of what her management asked her to do, namely corporate security.

When she went outside those bounds and started using her immense technical privileges in ad-hoc ways, and (worse) making arguments like "I got a colleague to approve a code review so it was OK" she gave an extremely clear demonstration that management simply couldn't trust her. It's not about unionisation. It's about someone with the power to steal cookies from her own colleagues going rogue and deciding her own personal political priorities matter more than company policies she had agreed to follow.

The problem is, she insisted to the world (and presumably to Google as well) that she did nothing wrong here. This is a pretty minor thing to fire someone over - but what other option does a company have, when someone makes it clear that they refuse to behave properly?

Whether or not she behaved properly is what I assume to be contested here.

> but what other option does a company have, when someone makes it clear that they refuse to behave properly?

You could tell them to stop instead of firing them after the first offense.

How are you supposed to trust someone to follow the rules in the future if they won’t even acknowledge they broke them?

How can you expect anyone to be anything but defensive of their actions when you essentially fire them on the spot?

People do similar things quite often at Google and I haven't heard any of them getting fired before.

Security team members modifying their tools that are deployed to a large number of employees for fun ?

Part of the job was writing precisely that sort of pop-ups.

No, part of the job was to write pop-ups related to _security_ not to random things.

This was absolutely off limits.

Only sort of related, but one time some of the YouTube engineering team made a code change to kill off usage of Internet Explorer 6 by bypassing the usual code screening process to circumvent management. Their boss reprimanded them but eventually got in on it, without going through the appropriate channels. Then the Docs team saw the banner they showed YouTube users, thought they had actually received approval from management and used it as evidence to convince their managers to implement their own banner (who would have normally refused).

All they received was a small rebuke. In fact, management praised the team for the end result of decimating IE6 usage, as intended.

Then one of the architects of the scheme blogged about it in retrospect years later.

https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

There is a reason I am specifically talking about security team members.

They got lucky with positive press before they were discovered. The article you link to notes:

> If this went at all wrong, a number of us would surely be fired.

It was a configuration change so there were no dangers adding it, so she being a security engineer isn't relevant. The right punishment would be to tell her what channels she can use to send union messages and tell her to just do security related popups in the future. If she continued sending messages like this then fire her, but it is dumb that she got fired over something that would take literally 5 minutes to fix.

Configuration is code. Many an outage has been caused by a bad configuration push.

Configuration which consists of an url and a message to display on said url is not that kind of configuration push.

It's extremely relevant I will reiterate I know literally 0 large companies where this would be tolerated from a security team member.

Google did tolerate exactly the same kind of behavior from the internal OS distribution team before, you could argue that security is even more important there than in a browser plugin.

I am not a Googler but I reiterate I know exactly 0 CSOs that would tolerate this. You providing an example outside of security team kindah reinforces my point.

The internal OS distribution team is a security team. They ensure that the OS everyone at Google works on and run their code on is secure.

They report to CSO ? Would be pretty unusual again not a googler but normally that would not be part of security team

Google has a lot of security teams since they do all of their infra themselves. The people who push security patches to peoples OS's is a security team, and they used that channel to push a message similar to this.

from an outsider perspective i can say that to me This is a security tool and it should show popup for restricted sites and/or flagged sites. if its intent was a general notification extension like office emails etc , nobody would have cared. But since it is a security tool even if your action is not malicious the expectation of security only updates is breached, which is what i believe is the core issue. More so the employee is a security engineer, the fact that this is most likely something they would be aware of and proceeded to do this change anyway is something which is extreme-ly worrying. It raises all sorts of questions like how safe is google infrastructure from rouge employees and how does this affect data collected by google and handled by googlers.

I agree that "Don't slack off dummy" would have earned a rebuke, but I wouldn't be surprised if any controversial political activist message would have been grounds for termination, especially with Google's new policy regarding political activism in the workplace. She would likely have been rebuked if she had just posted a flyer in the cafeteria, but she modified an internal tool.

> "Yeah let's be real, if she programmed a popup to appear over twitter with a message like "Don't slack off dummy UwU" and or something equally ill informed she would have been rebuked at worst."

What? Granted, I've only worked for large businesses but that would be grounds for immediate termination at any company I've ever worked at.

From her description of her job position it seems like programming a popup to appear over twitter with a message like "Don't slack off dummy UwU" was exactly what Google wanted her to do in her job.

> As a security engineer who worked on the Chrome browser’s use within Google, Spiers wrote browser notifications so that employees could be automatically notified of the company’s policies and guidelines as they browse the internet. Spiers said that engineers regularly implement such code changes to make their jobs easier and share personal interests.

But programming a popup to appear over a union busting law firm website with a message that such and such law exists was not.

> Spiers wrote a few lines of code that created a pop-up message asserting Google employees’ labor rights whenever her co-workers visited the consulting firm’s website or Google’s community guidelines. The message reads: "Googlers have the right to participate in protected concerted activities." The pop-up would have been visible to anyone at Google. > https://www.vice.com/en_us/article/jgexe8/google-fired-an-en...

> The fact that 2 coworkers were fine with your change doesn't mean it was made in good-faith

The standard for whether a company is legally allowed to fire an employee for organizing isn't whether their action is in "good faith", but whether their action is concerted. The fact that it passed code review is therefore critical evidence.

IANAL, but California is an at-will state. Again, IANAL, but my educated understanding is that you can fire someone for any reason as long as the reason is not illegal. Lastly, IANAL.

Organizing is protected by law. Firing for organizing is intimidation.

Yep, that's what's contested here and is unclear.

Is using whatever mechanism is available to you, including company privileges, in order to organize perfected by law? As a customer support person, would you be able to add "you have the right to sue Google," simply because they did have the right, and I felt like it? Am I allowed to write a script that helps draft automated verbiage to assist you in suing Google?

But IANAL firing some one for telling their co-workers about their right to unionize is an illegal reason to fire someone. I'm not completely convinced that's what happened here but still

Technology makes a lot of these good intentioned laws hard to interpret. You cannot be fired for telling your co-workers that they are allowed to unionize. What if you work for a call center, commandeered an auto-dialer, and called every co-worker in the company with the same message? What about a popup on every page of an internal company website? Is someone allowed to stand up in the middle of the office with a megaphone and tell everyone they can unionize?

> What if you work for a call center, commandeered an auto-dialer, and called every co-worker in the company with the same message?

The law already covers situations like this, in terms of whether or not employees are allowed to use the internal technology tools of their employers in order to organize.

So what does the law say?

Right, but retaliation for engaging in a concerted labor effort is specifically an illegal reason to fire someone.

She went through the corporate approved process with her changes. Her only mistake here is being pro union while Google is decidedly anti-union and pro-worker-abuse.

They approved the code that implemented the feature, but I doubt they were responsible for approving the feature to begin with.

I don't know how this works where you are, but when I'm asked to review code for someone, that's exactly what I do but also only what I do - I don't ask them if they have a design document for the change or approval from the features team. It's not my job to verify that.

Yikes make room for someone who wants to do the job

> Prefixing this by saying I am not siding with Google (since people make assumptions).

Prefixing this by saying I'm not making an assumption about who you're siding with, but offering my opinion on the argument you're using.

> The standard approval process sounds like most merge review processes on any engineering team. There's a sort of assumed good-faith for this process. The fact that 2 coworkers were fine with your change doesn't mean it was made in good-faith and was within the bounds of normal types of changes.

Other people have already argued about whether what she added to the extension is in line with the purpose of the extension and whether it was within her purview.

Regardless of that, I would like to point out that we're not hearing that these two coworkers -- or anyone else involved in the process -- have been fired. Only Spiers. If the concern is really about the security and the trust, why is one person singled out?

I have to agree. I'm all for unionization in our industry to improve employee leverage and even more open compensation sharing to help drive comp up... but this is a step too far. Pushing your message in this fashion is clearly irresponsible no matter how "by-the-book" it is.

With that said, the organization and orchestration problem for movements is a very real problem (finding the correct people and disseminating information). This is something businesses are well aware of and they use that to their advantage.

It's an even harder problem when the employer is firing people for trying to organize.

Change the words in the message, and I can't imagine it being anything but a reprimand, at worst. This is a message to other employees that organizing gets you fired.

> There's a sort of assumed good-faith for this process.

I don't understand why two people sign off changes if they assume the person making the changes isn't going to make errors or be "malicious". And I'm not sure why two people sign off changes instead of just one. There's a well understood problem when you have more than one person inspecting product - they both assume the other person is competent and will catch anything they've missed, and they each do a lighter inspection.

Technically it worked so the approvals would have gone through. These people would not have direct insight into her business objectives or intent.

>And I'm not sure why two people sign off changes instead of just one.

Because more eyes catch more bugs. I work in a time like this where we have 2 or even 3 people review stuff; it's extremely common for one engineer to miss stuff that another one catches. It's particularly notable I think with junior vs. senior engineers: I think you really need at least one senior engineer reviewing everything before a merge, but you don't want to keep junior engineers out of the process because then they'll never learn. With trivial tickets, however, you can relax this rule and just have one person review before a merge.

> Because more eyes catch more bugs.

But for product inspection we have pretty good evidence, from millions of human hours of factory work, that it's a bit more complicated.

X makes a widget, and sends it for inspection by Y and Z. Y has a look, but assumes Z will catch anything that Y misses. But Z also assumes that Y will catch anything that Z misses.

You end up with two people doing a superficial inspection and missing problems.

Of course, that's only if they're doing the same inspection twice. If they have different and clearly defined inspection roles the two inspector problem doesn't apply.

If you need 2 approvals at Google, then usually 1 is for readability in a specific language. I.e. one of the reviewers is understood to mostly be looking at code style and not domain logic.

In my experience, you more often get the other phenomena where all reviewers (and some other people who get automatically CC'd) dogpile the review and you potentially have too many comments. Or someone ignores the review and it never gets approved. Cursory reviews were basically never a problem.

I think the punishment is warranted for the fact that it is an internal security tool. I don't know of any large company that would allow this kind of code commit without that level of punishment being taken. She was trying to be sincere in her actions but comes off as completely naive that what she was doing was a serious violation. I don't see her winning this to any degree and at 21 it will be a big learning lesson.

Reply on news.ycombinator.com