Creating a Chrome Web Store developer account

[Costas Athan]

Hello, I have a few questions about creating a Chrome Developer's account.

1. Can I create multiple accounts under the same Google account or just one?
2. Am I supposed to create one account per add-on? I am asking this because I see that under account settings there is an option to share a privacy policy link. Does this mean that I can share just one privacy policy that has to be common for every add-on I publish? Furthermore Google states:
   
   "First you will need to register as a Chrome Web Store developer. We suggest using a new account just for your item instead of your personal account."
   
   Is this also a suggestion for one account per add-on?
   
3. Google also states (https://developer.chrome.com/docs/webstore/register/):
   
   "You must provide a developer email when you create your developer account; here are some tips about which email to use:

   Because you will receive important emails about your extension or you may want to delete one of your accounts, we suggest using a new email account just for publishing your Chrome Web Store items."
   
   Does this mean that deleting the Chrome Developer's account would also delete the connected Google account? If the Developer's account can get deleted separately what's the point of the suggestion?

4. How does someone become a verified publisher?

Thanks in advance for any answers!

[hrg...@gmail.com]

You can create only one developer account per email address.

Each developer account costs you USD$5 and lets you publish up to 20 extensions.

You can have only one privacy policy per developer account. If your extensions don't share the same privacy policy, you can link to different privacy policies in the common policy.

You become verified by verifying ownership of a domain name. For example: "Published by: example.com"

They recommend to create a separate email address so you can keep things separated. Using a single email address for everything is not a good idea in general. You should have an email address related to your workplace, another one that's for your personal life, etc.

[Costas Athan]

"you can link to different privacy policies in the common policy". What do you mean by that? Can I set a different policy per extension?

If each extension has its own website and support email address can I link to them?

Becoming verified will show the same domain for every extension and that's not a good policy after all, except if you are publishing extensions as a company and you use your company's name. But if I publish multiple extensions I don't think that showing Published by: myxtension1.com would be OK when that would refer to a certain extension.

[hrg...@gmail.com]

If your extensions are not related to each other and they have a separate website, then it's best to create a separate developer account for each extension.

You can have only one privacy policy per developer account. But inside that policy, you can do this:

This is the privacy policy for "Extension 1": LINK1

This is the privacy policy for "Extension 2": LINK2

This is the privacy policy for "Extension 3": LINK3

[Costas Athan]

OK. That's a very bad policy. Other add-ons stores like Microsoft's let the developers set email addresses, websites etc. per add-on not globally.

[Cuyler Stuwe]

Microsoft is an incumbent who is eager to cater to developers in order to grow their marketplace and increase user count.

Google used to be in that position when Firefox was popular in the mid/late-'00s, but now that they've been the uncontested "top dog" for years, they've stopped trying so hard to appeal to users and developers.

This is why competition is good, and why it's not so great that Chrome is essentially a monopoly in the browser space.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/2b6122c4-57f0-4475-a379-ab2535853556n%40chromium.org.

[Costas Athan]

It's not just MS. Also Mozilla and Opera let you set separate domains and emails per add-on under the same account. Creating a different Google account for each add-on just for branding purposes is beyond ridiculous.

Anyway, you are right without competition whoever has the monopoly enforce their own policies, but no one is a monopoly forever.

[hrg...@gmail.com]

Microsoft did the same in the early 2000s when IE became a monopoly.

Now Google is falling into the same behavior. Manifest V3 is a great example of what happens when a company becomes dominant. Basically "We already are where we wanted, so we won't spend a dime more on this extensions thingy. Here, have MV3 and sort it out yourselves."

[Simeon Vincent]

Because you will receive important emails about your extension or you may want to delete one of your accounts, we suggest using a new email account just for publishing your Chrome Web Store items - Extensions docs

Apologies for the confusion here. I'm pretty sure that I wrote this passage. As I recall, the main thing I had in mind at the time was that Chrome Web Store has a limit of one group publisher per extension. At the time I was seeing a lot of developers who were getting tripped up by this limitation, so this guidance seemed useful at that moment. In retrospect, though, I think I need to remove this recommendation.

In my opinion the Chrome Web Store enables an individual user (as represented by a Google Account) to maintain multiple unrelated extensions. Moreover, it should not incentivise developers to create multiple accounts. If there are personal or professional reasons why someone might want or need multiple Google accounts, that's fine (so long as that's allowed by Google's account policies, I don't know much about that), but a single developer account should "just work." 

Creating a different Google account for each add-on just for branding purposes is beyond ridiculous. - Costas

Agreed, but I don't think that's actually required. As I recall the "offered by" (aka verified publisher) feature allows you to select from a list of domains that you have verified on your Google account. This field is exposed on individual extensions rather than on the developer's account, so I'd be extra surprised if this setting applied to all extensions published by a given developer.

At the moment I think the only thing that directly ties an extension to a single developer with respect to branding is the privacy policy link. While this link is a developer account-level setting, the link can take users to a landing page that links out to different privacy policies for each extension you publish. 

"We already are where we wanted, so we won't spend a dime more on this extensions thingy." - Hrg

I genuinely don't understand this comment. I'd love to hear why you feel like Chrome is not putting any resources towards extensions.

When I joined the Chrome team ~3 years ago the Chrome team was on the leading edge of ramping up to invest more in the extensions platform and ecosystem. I don't know how much I can say about resourcing or headcount, so suffice to say that during my time virtually every team that works on extensions has seen significant growth. Chrome isn't holding back investing in extensions extensions. Quite the opposite, actually. 

Simeon - @dotproto

Chrome Extensions DevRel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/48d25160-b46c-499a-8f98-8535ca18bce5n%40chromium.org.

[Costas Athan]

@Simeon Vincent

You said: "At the moment I think the only thing that directly ties an extension to a single developer with respect to branding is the privacy policy link".

I'm afraid you are wrong. You set one contact email that is public for the developer account and that email is shared by all the add-ons. In my case, and probably that's true for many other developers, the domain of the email is connected with the name of the extension, so it doesn't make sense to be used for other add-ons too.

[Cuyler Stuwe]

The perception of limited resources probably comes from a statement you said earlier, which alluded to the notion that service workers are being repurposed as fake “background scripts” in MV3 largely to spare limited development time. There’s also the fact that MV3 itself has been shelved several times, and the team seems to have been behind schedule on a handful of features (eg prior discussions revolving around the documentation being significantly further ahead than implementation).

[Cuyler Stuwe]

On top of this, there’s also the common-sense judgment that because the Chrome Web Store doesn’t directly line Google’s pockets in any meaningful way, Google as a company has little reason to manage it well. It seems from MV3’s design that Google isn’t trying very hard to build an extensible feature-rich browser that users are excited to use. Google was more concerned about helping developers extend the browser into something cool and useful in the past, hence why MV2 is degrees-of-magnitude more useful than MV3.

[hrg...@gmail.com]

On Wednesday, November 10, 2021 at 8:01:41 PM UTC-3 Simeon Vincent wrote:

I genuinely don't understand this comment. I'd love to hear why you feel like Chrome is not putting any resources towards extensions.

The comment is a caricature to express a sentiment.

The sentiment being that we, extension developers, are being screwed over by Google. We are being forced to re-engineer years and years of work because somebody had the genius idea that an IDLE background page somehow consumes too much resources, so a service worker which forces to reload the entire extension plus it's data model every 5 minutes is "surely" much efficient.

I have yet to hear any explanation of how replacing the background page with a service worker is going to benefit users.

It's certainly not benefiting developers, as it has become obvious by the amount of stress and time that we have to put into the MV3 migration. It has been nothing but headaches and 2022 will be pure hell as we will be forced to implement all sorts of hacks in order to keep as much of our extensions' existing functionality.

In the software industry, there's an important principle called "backwards compatibility". Companies like Microsoft understand the value of maintaining a system backwards compatible. Windows is the best example of this. Applications that were written for Windows in the 90s still work in the latest versions of the OS today. No exaggeration, this is actually true.

But of course, maintaining backwards compatibility has costs. And Google has a long history of disregarding backwards compatibility because of its costs.

Why do they want to move the extensions platform towards standard web technologies?

Because that way they don't have to maintain a separate set of technologies.

What will happen if they break compatibility with the existing platform?

All developers around the world will have to re implement their extensions. And the extensions that are not updated will stop working. Period.

Does Google care about this massive disruption?

No, they do not, because it has maintainability costs.

Why would Google spend their human resources maintaining backwards compatibility when they can instead make that cost to be absorbed by all of us, extension developers, by forcing us to adapt our software to theirs (MV3).

I think it's clear enough that a big part of MV3 is about costs and who absorbes those costs.

MV3 is like a magic trick. The magician shows what he wants the spectator to see and hides everything else. That's how the illusion is created.

So, the illusion is that MV3 is an improvement, but in reality only a part of it is improvement. Another part of it is cost reduction at the expense of all of us extension developers.

And the excuse is that all of that is for the benefit of the user, which in reality is only partly true. But which part?

That's where the magic trick lies.

[Costas Athan]

Is there a way to leave feedback to Google for the structure and organization of the Chrome Developer Dashboard?
I visited: https://developer.chrome.com/ but I can't find a way to do it.

[Vladimir Yankovich]

Colleagues, despite the starting theme, it seems we've been talking a little differently about prioritizing and investing in an extensions platform for Google. Allow me to comment on that as well. 

First, I have a strong feeling that most of the general criticism of Google is due to the SW situation in MV3. Not even MV3 itself, but SW. But people can't criticize the same thing 10 times in a row, as a result the form of criticism changes, the real problem is masked by general phrases. But no matter how difficult it is for us, we must keep our thoughts and speech clear.

Secondly, I, like many developers here, am associated with multiplatform products. And it is the knowledge of how support for developers on other platforms is handled that makes us complain about Google. Even if we compare how much care Google shows for its mobile developers. Yes, that's something we wouldn't dare to dream of. But we must be realistic. Profit is a source of investment, the mobile market is oil, extensions is a cornfield. In principle, it could be worse :) 

Third, I often hear Google rebuked in comparison to other browsers - others work better, faster, more caring. This is true, but only in part. First, I used to work on a major browser myself, and second, I am an entrepreneur. And I know how easy it is to surprise customers when you're at the beginning of your journey, when you're building something from 0 to 1. But gosh, how hard is it to pull a rabbit out of a hat when you're developing something from 1 to infinity. Google is huge, Chrome is big, Chrome's extension platform is the biggest on the market. We shouldn't expect here, the same bright development as in other browsers. 

Nevertheless, as a developer of Chromium extensions, I certainly wish that the quality of developer support would grow. For example, that in this forum from Google sound not only Simeon's voice, but also that of his other colleagues, such as experienced engineers. So that I could understand how the distribution mechanisms in the store work and be able to take advantage of them. So that I could request a thorough product review, get confirmation of compliance with all policies, and sleep in peace. Dreams :) By the way, this is all very simple and pretty cheap stuff, any product manager will implement it within a year without a budget, just ask your customers (us) what their pain is. 

One last thing. I'll turn to my colleagues. Be accurate and constructive in your criticism, then the chances that we will be heard and want to help will greatly increase. Calmness and persistence are the key to all doors; negativity is the lock. 

[Cuyler Stuwe]

I just want to be able to build the products that users demand.

Unlike Google (who is now corporation-centric and self-centric), I’m user-centric.

I don’t want to have to explain to users that I’m forcing them to keep a visible tab open in their browser just because that’s the only reasonable way to keep a socket open. I don’t even want my users to have to know what a socket is. But Google is putting us in this situation where we’re going to have to do ridiculous things like that to build the tools that customers demand.

In making things difficult for third-party devs and their users, Google is hurting themselves. For the time being, the decision-makers might be too far removed to even recognize it. But if there is ever going to come a time where people move away from Chrome and toward something else, MV3 is one of those inflection points that has some opportunity to cause it.

[Costas Athan]

Actually, my criticism was on topic about the architecture of the Developer Dashboard.

The Developer's account sets a support email and a privacy policy link globally for every add-on. As a result, in cases where each add-on has its own email address and domain, as well as its own privacy policy, the developer should create a separate Google and Developer account for each add-on only for branding reasons. By the way, each developer account would cost $5.

The stores of every other browser let the developers set both the support email and the privacy policy link separately for every add-on, not globally for the account.

[Vladimir Yankovich]

@salem...@gmail.com, That's a great commentary. Much better than arguments about lack of investment. Mistakes can be made by investing billions. So my point is that it is important that we be accurate and hope that we are heard :) 

@kwstas...@gmail.com, But I honestly don't understand you. Either you have simple utility products that don't even have their own promo sites, in which case there's nothing stopping you from putting all their policies on one page and using one email for support. I know several teams that manage multiple products from one account without any problems.

Or you have a full-fledged product with a website, brand, domain, and so on. But then it's just a sin not to have a separate account for it. I think this is an elementary safety measure. I know a lot of mobile teams that even there publish all the products in different accounts, although it's not necessary at all. 

[Costas Athan]

@

yankovic...@gmail.com

I don't see the point of having separate accounts for every product. I would say that 2-step verification is a sufficient security measure for having all the products under one account and I would personally prefer the comfort of 1 account. All the other browser stores give you the opportunity to do it.

After all, I don't see why Google should force this on every developer. They can give the ability to set emails and domains for every product separately. That wouldn't prevent whoever wishes to have separate accounts to create as many accounts as they like. On the other hand, the current implementation strips the choice from the users!