←back to thread

192 points beedeebeedee | 6 comments | | HN request time: 0.001s | source | bottom
Show context
peterkos ◴[] No.41900587[source]
I'm reminded of a time that an intern took down us-east1 on AWS, by modifying a configuration file they shouldn't have had access to. Amazon (somehow) did the correct thing and didn't fire them -- instead, they used the experience to fix the security hole. It was a file they shouldn't have had access to in the first place.

If the intern "had no experience with the AI lab", is it the right thing to do to fire them, instead of admitting that there is a security/access fault internally? Can other employees (intentionally, or unintentionally) cause that same amount of "damage"?

replies(12): >>41900622 #>>41900627 #>>41900641 #>>41900805 #>>41900919 #>>41901069 #>>41901814 #>>41903916 #>>41909887 #>>41910021 #>>41910134 #>>41910235 #
grogenaut ◴[] No.41900641[source]
From what I've seen in Amazon it's pretty consistent that they do not blame the messenger which is what they consider the person who messed up. Usually that person is the last in a long series of decisions that could have prevented the issue, and thus why blame them. That is unless the person is a) acting with malice, b) is repeatedly shown a pattern of willful ignorance. IIRC, when one person took down S3 with a manual command overriding the safeguards the action was not to fire them but to figure out why it was still a manual process without sign off. Say what you will about Amazon culture, the ability to make mistakes or call them out is pretty consistently protected.
replies(4): >>41900811 #>>41901212 #>>41911207 #>>41914419 #
tgavVs ◴[] No.41900811[source]
> From what I've seen in Amazon it's pretty consistent that they do not blame the messenger which is what they consider the person who messed up

Interesting that my experience has been the exact opposite.

Whenever I’ve participated in COE discussions (incident analysis), questions have been focused on highlighting who made the mistake or who didn’t take the right precautions.

replies(5): >>41900843 #>>41900913 #>>41901176 #>>41901751 #>>41902023 #
grogenaut ◴[] No.41900913{3}[source]
I've bar raised a ton of them. You do end up figuring out what actions by what operator caused what issues or didn't work well, but that's to diagnose what controls/processes/tools/metrics were missing. I always removed the actual people's name as part of the bar raising, well before publishing, usually before any manager sees it. Instead used Oncall 1, or Oncall for X team, Manager for X team. And that's mainly for the timeline.

As a sibling said you were likely in a bad or or one that was using COEs punatively.

replies(3): >>41901015 #>>41901855 #>>41909919 #
mlyle ◴[] No.41901015{4}[source]
In the article's case, there's evidence of actual malice, though-- sabotaging only large jobs, over a month's time.
replies(1): >>41901174 #
fragmede ◴[] No.41901174{5}[source]
All I got from the linked article was

> TikTok owner, ByteDance, says it has sacked an intern for "maliciously interfering" with the training of one of its artificial intelligence (AI) models.

Are there other links with additional info?

replies(1): >>41901326 #
mlyle ◴[] No.41901326{6}[source]
A lot of the original social media sources have been pulled, but this is what was alleged on social media:

https://juejin.cn/post/7426926600422637594

https://github.com/JusticeFighterDance/JusticeFighter110

https://x.com/0xKyon/status/1847529300163252474

replies(1): >>41901343 #
1. fragmede ◴[] No.41901343{7}[source]
Thanks. Google translate off the first link:

> He exploited the vulnerability of huggingface's load ckpt function to inject code, dynamically modifying other people's optimizer to randomly sleep for a short period of time, and modifying the direction of parameter shaving. He also added a condition that only tasks with more than 256 cards would trigger this condition.

Okay yeah that's malicious and totally a crime. "modifying the direction of parameter shaving" means he subtly corrupted his co-workers work. that's wild!

replies(2): >>41901370 #>>41911851 #
2. mlyle ◴[] No.41901370[source]
Some of the sources say that he sat in the incident meetings during troubleshooting and adjusted his attacks to avoid detection, too.
replies(2): >>41904131 #>>41909548 #
3. justinclift ◴[] No.41904131[source]
Wonder what the underlying motive was? Seems like a super weird thing to do.
replies(1): >>41910140 #
4. NetOpWibby ◴[] No.41909548[source]
LMAO that's just diabolical. Wonder what motivated them.
5. tyingq ◴[] No.41910140{3}[source]
Could be just so his work looked better in comparison. Or something more sinister, like being paid to slow progress.
6. yorwba ◴[] No.41911851[source]
"parameter shaving" (参数剃度) is, by the way, a typo for "parameter gradient" (参数梯度), 梯度 being the gradient and 剃度 being a tonsure.