Another few months have passed and the Chrome team has published another set of updates to the Chrome Web Store’s (CWS’s) Program Policies. Typically the Chrome team would announce this kind of update with a blog post as well as an email to developers, this time they only sent out the developer email (reposted publicly by Stefan Van Damme). They probably skipped the blog post this time because of the small scale of the update, both in lines of text and impact.
In this post I’ll be walking through what changed, thinking out loud about likely motivations, and sprinkling in additional context about policies and the broader ecosystem.
Quality Guidelines
This is the only section of the policy text that was updated. Before this update, the Quality Guidelines were a little weird in that they only had a single top level bullet. Well, now there are two!
(2) When designing an extension, it’s important to ensure it functions as a helpful companion to users' browsing experiences by providing complementary functionality. If utilizing a persistent user interface, extensions should actively enhance the user’s current task while causing minimal distractions. Some common violations include:
(2.1) Side panel extensions which hijack a user’s browsing or search experience.
(2.2) Extensions with the primary purpose of serving ads.
This change was almost certainly inspired by the introduction of the Side Panel API (announcement post) and it’s likely abuse vectors. (A few hours later…) Turns out Oliver, a Chrome Extensions DevRel Engineer, basically said as much in this post:
The context was the launch of the Side Panel API … the goal was just to have some language in place to make it clear that similar policies to our existing ones (single purpose, not providing particularly distracting experiences) also apply to the side panel"
For a quick recap, Chrome’s side panel is essentially a separate web page that is attached to the side of your browser window. Since the side panel is persistent, it has a lot of potential to augment and enhance the user’s browsing experience, but with great power etc.
A persistent UI surface virtually guarantees that not-so-great actors will try to crap up the user experience. As such, this new policy text is almost certainly aiming to both steer developers away from abusive patterns and to arm reviewers with tools to take action against those poor user experiences.
2.1 is worth quickly touching on because browser hijacking is a common problem in the extension ecosystem and is a significant source of confusion/frustration for users. (See my last blog post for another related discussion.) I’m honestly a little surprised to see it mentioned here as other policies also cover search hijacking, but, admittedly, not as directly.
As a brief reminder, if you want to expose a generic search box in your extension, you must respect the user’s preferences by using chrome.search.query() in Chromium (or browser.search.search() in Firefox) to execute a search using the currently selected default search provider.
2.2 is interesting to me because as it explicitly prohibits extensions with the single purpose of displaying ads. This may not be common knowledge, but to the best of my knowledge this used to be an acceptable single purpose. Now it’s explicitly prohibited. If nothing else it’s worth acknowledging the shift here.
I don’t think I ever encountered an extension with the sole purpose of injecting a bunch of ads on a page. Well, at least if you don’t count extensions that inject referral links on everything they can. Don’t do that. It used to be a decently effective way to get on the wrong side of a malware verdict for “[interfering] with the operation of the networks, servers, or other infrastructure of … any third-parties” (source).
That may sound harsh, but the problem is that when an extension clobbers existing referral links on a site, they effectively steal the referral traffic created by that site. While referral hijacking and content blocking both interfere with a website’s revenue streams, there’s a critical difference in the incentives. Content blocking has security/privacy benefits for the user and monetize through subscriptions or donations. Referral hijacking doesn’t improve user security (arguably it actually exposes more information via referrals) and every referral link directly benefits the extension’s developer.
Still, it was very easy for a well-meaning but overzealous developer to get caught on the wrong side of referral hijacking enforcement. Before this, the malware policy was the best match to take action on referral hijacking, but malware verdicts cannot be appealed and Google will not share details about the nature of the violation the developer.
Now, I don’t know if this is what Chrome policy folks had in mind, but that this new language might give reviewers a way to notify developers that they’ve crossed the line on ads without having to go straight to a malware verdict. Time will tell how this plays out.
Best Practices and Guidelines
This page has been updated with a few new bullets that highlight a couple of things that often trip developers up. IMO it’s a good set of changes all around.
(1) Research and understand the Chrome Web Store policies. Before developing a Chrome extension, it is important to review the Chrome Web Store Developer Program Policies and ensure your extension complies with all guidelines and requirements.
I think it makes senes to call this out at the top of the list. IMO policy compliance is an under-appreciated and often overlooked aspect of publishing an extension on CWS.
CWS Developer Policies aren’t meant to make developer’s lives harder. For the most part, they are just putting up guard rails in order to protect users. I’ve seen too many extensions that disregard user privacy, products built on the gray areas of policy, and extension developers that are genuinely surprised when they get hit for what seem to me to be obvious policy violations. CWS policies serve as a minimum bar that says “yeah, maybe you shouldn’t be doing that.”
Shameless plug: if you need help with navigating CWS policy compliance or navigating a takedown, I can help. Use the contact link on incremental.software to learn more.
(4) Developers must strictly adhere to strict guidelines regarding the collection, use, and disclosure of user data, and must obtain user consent for any data collection or usage. Apps that access sensitive user data such as financial information, health information, or personal information must comply with additional policies and guidelines.
This is a great addition. Users are increasingly aware of and uncomfortable with software data collection practices. Data collection is also a very common cause of submission rejections and extension takedowns.
Developers stumble around data collection due (in part) to the curse of knowledge. Often extension developers understand what data they’re accessing, what tradeoffs they’re making around privacy and security, why data collection feels appropriate for their use case, and ultimately that they are just good folks trying hard to make something their users will enjoy. In these situations, the problem is often that the developer forgets to communicate these considerations to end users (and by extension reviewers).
Beyond that, users and reviewers aren’t just worried about how the extension might use their data, they’re also worried about what might happen if the extension’s supply chain is compromised or it’s database gets dumped. Developers have a tendency to focus on happy paths and forget to consider how another party might (say a hacker or a new owner) abuse or misuse the data they’ve collected.
Speaking of which, I strongly encourage all extension developers to be extremely cautious of unsolicited emails about extension monetization schemes. I’ve recently written more about this, but as a short summary they want you to add a little JS to your extension so they can harvest your user’s data (see also data broker). This practice is forbidden by CWS policy and will very likely get your extension flagged as malware and there’s no coming back from that. Don’t be the pawn in someone else’s game.
(10) Chrome Web Store policies are subject to change. Google may update the policies at any time, and developers are responsible for keeping up-to-date with any changes and complying with the updated policies. Updates to our policies will be announced via email to the address listed in your developer account.
This new item appears as the final entry in the best practice list and IMO serves as a nice end-cap.
Developers may not realize it, but CWS policies are regularly updated in response to the evolutions of browser extension ecosystem and broader software landscape. User expectations are changing, new threats emerge, active exploits and abuse campaigns are refined, legal requirements are shifting, the API surface evolves, and at the end of the day we’re all just trying to ship software.
I’m also trying to do what I can to help here; I wrote this post with the hope that it will help make the browser extension policy compliance process a little more explicable. If you have any feedback on this post, you can reach me on Mastodon at @dotproto@toot.cafe or use Mastodon to comment directly on this post.
