A warning about monetizing extensions with search
This post is based on a comment I shared on the chromium-extensions group.
It’s a frustratingly frequent experience for extension developers: you’re going through your customer feedback sent to your contact email address (a CWS requirement) and you come across something like this:
I’m reaching out to you concerning the potential revenue generation from your Chrome Extension,
. We are keen on offering our premium product, Bing Hosted Feed, which is a high-quality search solution. This represents an excellent chance to incorporate a search feature into your Chrome extension, thereby monetizing your users' search activities. With this integration, you stand to earn up to $500 per month for every 1,000 users, paving the way for an extra passive income stream from your extension.
Even if your extension currently lacks a search function, there’s no cause for concern. We are fully prepared to guide you through a straightforward update process to incorporate the search function. This update is fully compliant with Google Chrome store’s guidelines, and should you find it unsatisfactory, you’re always free to revert the changes at any point.
I don’t fault anyone for being tempted by this kind of offer; it’s hard not to be intrigued by solid money in exchange for a seemingly minor integration. But if something seems too good to be true, it probably is. Despite their claims, I’d bet dollars to doughnuts that what they’re doing doesn’t comply with CWS policy. Worse, these services may well end up getting your extension flagged as malware.
Let’s talk about what these kinds of monetization schemes typically ask of developers, look at some relevant Chrome Web Store policies, and see why integrating with them will likely land you in hot water.
What they want
The people behind these emails want to replace the user’s search engine with something that pays them for that traffic.
Why? Because search is very valuable. While it’s hard to find solid numbers on exactly how valuable, Philippe Ockenden, Microsoft’s Corporate Vice President of Finance, said on an investor call that “For every 1 point of share gain in the search advertising market, it’s a $2 billion revenue opportunity for our advertising business.” That’s big money.
More concretely, the people behind these emails typically want the integrating extension to change the user’s default search provider using Settings Overrides. In some cases, though, they may ask developers to expose a search box in the extension’s UI or on websites. A search box would usually be integrated by adding some pre-defined HTML and their JavaScript library into the target page.
They don’t mention this part, but they’re also looking to minimize their own risk at your expense. They know that CWS can only take action against an extension and its developer. So, if the worst happens and the code they asked you to integrate is flagged for malware, your extension will be taken down and your account will be suspended.
Chrome Web Store policies
Roughly 7 months ago Google revamped the CWS Developer Policies around three principals: be safe, be honest, be useful. These simple statements get to the core of what the policies aim to accomplish: enhance the user’s web browsing experience without deception, fraud, mishandling of data, or disregard for the user’s wishes.
I mention that here because search monetization, by its very nature, can be considered a form of browser hijacking. From Wikipedia:
Browser hijacking is a form of unwanted software that modifies a web browser’s settings without a user’s permission, to inject unwanted advertising into the user’s browser. A browser hijacker may replace the existing home page, error page, or search engine with its own.[1] These are generally used to force hits to a particular website, increasing its advertising revenue.
Let’s walk through some specific policies in order to see how search monetization may put your extension at risk.
Single purpose policy
CWS has long had a “single purpose policy” (SPP) that essentially requires each extension have one well-defined raison d’être. Generally speaking, this means that all of the features an extension exposes must be part of a unifying theme. This policy is currently captured in the Quality Guidelines policies.
One area where SPP enforcement is stricter than average, though, is search. For the purposes of CWS review, changing a user’s default search provider is considered a distinct purpose. In other words, if the search monetization service instructs you to declare a search provider in your extension’s manifest with "is_default": true, that integration is basically guaranteed to violate this policy.
API use
The API Use policies require that developers “use existing Chrome APIs for their designated use case. Use of any other method, for which an API exists, would be considered a violation.” If the extension is exposing a general purpose search box, the extension must use chrome.search.query() (or browser.search.search() in Firefox) to perform the search.
Policies aimed at protecting user privacy
Integrating a search monetization service will likely violate a couple of the policies grouped under Protecting User Privacy.
The Limited Use policies requires that user data only be accessed/collected for purposes directly tied to the extension’s purpose. Any data collected must be limited “to the extent required for a user-facing feature described prominently in the Product’s Chrome Web Store page and in the Product’s user interface.”
Similarly, the Disclosure Requirements policies state that extensions must disclose the data they handle (collect, use, or share) and, if necessary, get informed user consent for that handling.
While one might argue that the extension isn’t collecting search data, it directly facilitates sending user data to a 3rd party service which may collect the user’s data for advertising purposes. That data would not have been collected but for the fact that the user had the extension installed. At best, that’s aiding and abetting – not a great defense to use when trying to get back into good standing.
Finally, the Misleading or Unexpected Behavior policies clearly state that extensions must not “misrepresent the functionality of your product or include non-obvious functionality that doesn’t serve the primary purpose of the product.”
Let’s make this a bit more concrete with an example. Say you had an extension that exposed a search field that looked and mostly behaved like a standard search box in your browser. Now say that when you executed a search using that box, the results page was on a website you weren’t used to seeing. I think it would be fair to say that the search box didn’t behave as expected.
A compliant example
At the moment, I can only imagine one situation where it would be appropriate for an extension to execute a search without using the default search provider: if the extension is exposing specialized search capabilities related to its single purpose.
For example, let’s say there is an extension designed to help users find, collect, reference, and site academic papers. This extension could expose a search box that lets users search through the academic databases and industry journals they are signed into. This type of search is directly related to the extension’s primary purpose, makes sense in context, respects the user’s preferences, and does not introduce new privacy concerns.
Wrap up
Trying to monetize an extension by sending search traffic to a non-standard search provider is, at best, risky business. Browser hijacking is a serious threat to users and anything that looks like it has a very real risk of being classified as malware.
My advice: steer clear of offers to monetize your extension via search revenue sharing.