I place a lot of the blame for the success of this phishing attack with how the Chrome Web Store, and Google more broadly, is operated. If you train your devel

I place a lot of the blame for the success of this phishing attack with how the Chrome Web Store, and Google more broadly, is operated. If you train your developers that you are willing to unilaterally and suddenly disable published extensions for editorial, non-security-related reasons (which the article's screenshots indicate was the excuse) - and that it's completely expected that such an action might occur on Christmas, and a well-founded one based on history - that's a poor developer experience. And on top of that, if Google has the ability for an OAuth app to get extension upload permissions, without screaming as part of the OAuth authorization process "This will provide third parties unrelated to Google the ability to update extensions. Be sure that this is intended." - then that is bad OAuth design that exacerbates the above problem. If you're designing a software supply chain, and you have a choice to allow updates over API, the onus is on you to either ensure your authentication UX causes spear phishing targets to think twice before they let themselves get pwned. And I get that there are certainly different teams working on the OAuth frontend and the Chrome Web Store backend - but if the backend team doesn't have the willpower and/or ability to have red-teamed this exact spear phishing situation, and have escalated their security concerns to the frontend team, that's an organizational failure.