Does the Chrome store not require that the dev account associated with these extensions be on the official corporate domains? That would seem like an easy way to prevent spoofing of Fortune 100 companies.
See: https://news.ycombinator.com/item?id=27192997 (no one could actually tell which where legit and which were not)
It's possible that things have changed since I created my account nearly a decade ago, or that somehow I got a pass because google manages my domain's email. But they definitely do not force @gmail.com addresses for all devs.
EDIT: See this Microsoft extension [1] for example. It shows @microsoft.com, which is undoubtedly not managed by google like my little old startup's email is!
1: https://chrome.google.com/webstore/detail/microsoft-editor-s...
All the counter-examples I could find in the linked thread are Google Mail (for Business), which is functionally the same as requiring a gmail account in that it requires Google to be your mail-provider.
A lot of people in corporations set things up without necessarily understanding what they're setting up. This includes apps. If you're thinking, "Wouldn't Microsoft know how to set things up correctly?" the answer is "Not necessarily". It's not "Microsoft" setting up some app account, it's a random guy on a random team somewhere in Microsoft, who might not have ever published an app before, much less gotten any training or done much investigation into it.
You need to go to any google signin page, click "Create account" > "For myself" > "Use my current email instead".
You can then use that to make chrome extensions.
But this is how misinformation spreads. Many people only read it and believe it without looking closer.
We just trust that other people know what they are talking about. :)
... Also I could be wrong, I'm trusting the counter examples in that thread. :D
Simple domain validated publishing similar to Let's Encrypt would be way better for devs and users, but that would require Google and Apple to give up control and that doesn't happen in monopoly markets.
Edit: And Microsoft. Between them those 3 companies are the gatekeepers of almost all (signed) app distribution.
You're putting them in the same bucket, but TFA calls out Google (and not Apple) for good reason.
> Between them those 3 companies are the gatekeepers of almost all (signed) app distribution.
And? I'm assuming you're not saying "software should not be signed", in which case I'm missing your point.
You're right. I'm not saying "software should not be signed". What I'm saying is the current trust industry is providing almost no value.
When I run an application on Windows that passes SmartScreen, all I know is that some company somewhere paid for an EV code signing certificate. In most cases, I don't know who the company is and don't have a way of finding out. That doesn't benefit me at all and most normal users misunderstand it to mean the company is trustworthy when that's not the case.
I've seen enough malware and adware signed with EV certificates that I personally place their value at zero. That's also influenced by my own experience in getting code signing certificates where the process used by CAs for identity verification are not anything official, but seem to be a rigid checklist of items that needs to be followed by someone with no cultural or local knowledge of my jurisdiction. IE: Easy to game once you know the process.
So, for me, the way code is currently signed tells me that someone had $2k USD to start a company and buy an EV certificate. That's it.
When I say that simple, domain validated code signing would be more useful for devs and users, I mean that I'd prefer to have the (ex:) UAC prompt tell me "This application is distributed by example.com" rather than "This application is distributed by Example XYZ LLC". I have a much better chance of determining the trustworthiness of the signer by knowing their domain than I do by knowing their registered business name.
And when I say Google and Apple are worse, I mean they've created systems that are completely opaque. It's "trust us" and they've both demonstrated repeatedly that they aren't worthy of being trusted.
As a specific example for Apple, there was a fake Fall Guys app on their store when it was at peak popularity. The fake app used the IP of the real one to trick users. Starting with the assumption that Apple's capable of ensuring that doesn't happen, you assume it's a legit app. If you expect to see what "website" (aka domain) is distributing the app it gets much easier.
Distributed by fallguys.com vs distributed by fallguysapp.com is the worst IP squatting you'd see and I could visit both sites if I wasn't satisfied enough assuming the more valuable domain is the real app creator.
In addition to that, IP squatting via a domain has a well established set of rules for trademark disputes, so a publisher can take action immediately to protect their trademarks rather than begging Apple or Google to take down a fake app.
The problem with a "good" system is that Apple, Google, and Microsoft have to give up control in order to let publishers self police their IP / trademarks and none of them will do that.
IMHO, anyone doing curation should be liable for IP theft and trademark violations. I have that opinion about _all_ online providers. As soon as they start curating or moderating they should be liable as if they're a publisher / distributor.