7 ms·

Chrome limits off-store extension installs

63 points by Osmose 14y ago

SnowLprd 14y ago
This change is being made without any buy-in from the community, ostensibly for security reasons. I'm skeptical, given the inherent incentives involved.
nimbupani 14y ago
I have no issues with the process, but only concerned with the way this change was made. The issue keeps referring to https://code.google.com/p/chromium/issues/detail?id=55584 https://code.google.com/p/chromium/issues/detail?id=55584 for "details", but there is nothing there except statements asserting how much of a "big problem" this is. I think this is a bigger problem with large open source projects in general where implementors are oblivious to which functionalities developers cherish and value. Any change in such features would require a more thorough explanation.
- Osmose 14y ago
  It may be an issue of having multiple channels of communication, and the bug tracker is only one of them. For example, though I work for Mozilla, I'm not terribly good at keeping up with the mailing lists, so every so often something pops up in Bugzilla (which I read more frequently) that seems to have come out of nowhere. And of course stuff happens in our IRC channels that never makes it to a bug; same with internal emails. There's a lot of effort involved in making sure your communication is clear and accessible when you have several different modes of it.
  - nimbupani 14y ago
    This is very similar to issues in W3C specifications. I just think a bug tracker should be the primary reference material to track discussions around a specific bug. I wish there was a way to link to IRC channel discussion around this bug and otherwise if possible. But nevertheless, I think it would be better if implementors summarize discussions outside of the bug tracker into the issue itself.
eigenvector 14y ago
This nicely illustrates the difference between merely being "open source" (Chromium) and being developed in the open (Firefox). At the very least a decision of this magnitude would have been discussed in the community BEFORE being merged in any sane openly governed project.
- justinschuh 14y ago
  I don't know why you're claiming this wasn't developed openly. The bugs are all public (the first was filed ~2 years ago); the code is checked into the public tree and has been enabled on canary for almost a month. It wasn't a heavy-handed or rash change, and the impact on both users and developers is minimal.
  - apendleton 14y ago
    For those of us that have already-deployed off-store extensions in the wild, what options do we have for migrating our users to the new, Webstore-powered versions? Or will their extensions just silently stop updating (or, worse, working altogether)? If it's the latter, your claim that this change will have minimal impact on developers and users is patently false, since you'll be breaking currently-released and -deployed applications that used to work and met the previously-documented requirements, with no warning whatsoever. Further, the suggestion that this is justified because it was committed to a public repository is absurd: are all developers of Chrome applications supposed to follow every single commit to Chromium's repo to ensure that our extensions won't break? What happened to Chrome's supposed immunity to breaking extensions with new releases, which you claimed made your extension model superior to Firefox's?
    - justinschuh 14y ago
      This change adds a few extra steps for an off-store install, unless the user or administrator configures things otherwise. That's it; updates and existing installations aren't affected at all. The details are very clear if you read the discussion or a few of the comments in the bug.
  - 14y ago
jonknee 14y ago
This is a pretty big change to bring in without warning. It would be nice if extensions could be signed but not on the store. I have extensions for internal business apps, they make no sense on the store but having a techy installation process is a big hassle. Google could even host the code (and have the ability to revoke), I just want a way to have "private" extensions that only only delivered to who I want.
- tiziano88 14y ago
  From the discussion: "In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.". Is this not a viable solution for your use case?
  - Kerrick 14y ago
    For one thing, this can't be done without a mouse to drag-and-drop with. This limits the extension of off-store extensions to those who can use a mouse, which is an accessibility issue. Are handicapped users or keyboard-only users just thrown to the wayside these days?
    - tiziano88 14y ago
      I was specifically asking about jonknee's use case, I never claimed that this would be an ideal solution for every other possible scenario. That said, your request to have a mouse-free way to install extensions is totally sensible, and I would be surprised and disappointed if they did not think of alternate ways to do that (perhaps using the command-line).
  - jonknee 14y ago
    I guess we will find out, that sounds like a pretty big roadblock for the skill level of users I am working with. There seem like there's a better solution out there, at leat for my use case. I serve the crx bundle from the same domain that it interacts with, that seems like it could be pretty malware proof.
- 14y ago
justinschuh 14y ago
I thought I explained the reasoning on the bug, but I can give it another go. Users are being tricked into installing malicious extensions, and thus getting compromised in significant numbers (Facebook "like" selling is a major target). We have continuously improving measures in the WebStore to catch malicious extensions, and the volume there is very low. However, we don't have a way of catching malicious off-store extensions. So, the best solution is to disallow other sources by default, and provide technically inclined users and enterprise administrators with the ability to add trusted sources. This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about. I'm also surprised Firefox hasn't proposed something similar, since I'm told they're seeing the same trend.
- icebraining 14y ago
  This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about. What do you mean? In both Debian and Ubuntu I can install a .deb (equivalent to .crx) just fine. I don't have to approve its source beforehand.
  - justinschuh 14y ago
    The extension manifest has update information in it, so when you install a CRX you're inherently configuring an installation source. That's something you have to take into account here.
    - Kerrick 14y ago
      The official Google Chrome .deb for Debian/Ubuntu downloaded from google.com/chrome sets up a software source as well, so you can't say that's not how .deb files work. kerrick@psyduck:~$ ls /etc/apt/sources.list.d/ google-chrome.list kerrick@psyduck:~$ cat /etc/apt/sources.list.d/google-chrome.list ### THIS FILE IS AUTOMATICALLY CONFIGURED ### # You may comment out this entry, but any other modifications may be lost. deb http://dl.google.com/linux/chrome/deb/ stable main
marshray 14y ago
Was there some new law of nature added in the last few years that says as soon as any app platform takes the lead its vendor must begin restricting the distribution channels available to 3rd party developers? Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?
- georgemcbay 14y ago
  "Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?" That's funny because both of them have already done that. Not on Windows, and MacOS, but on WinPhone7/Win8Metro and iOS.
- justinschuh 14y ago
  What? The only thing changing here is a default configuration value that actually gives users and administrators more control. This isn't like iOS or Windows RT, where you have to download an exploit and void your warranty to install software from a third-party source.
  - marshray 14y ago
    Yes, it may be not evil like WindowsRT and iOS and it may improve the security of users. But it's another brick in the wall being erected between 3rd party developers and users. 2000 Microsoft: "Developers, developers, developers" 2012 Apple, Microsoft, Google: "Won't someone please think of the poor users' security! (and give us a NN% cut off the top while you're at it"
  - Kerrick 14y ago
    If I want to distribute an extension that users want but Google won't allow, such as a pornography browsing extension (disallowed by the CWS policies [1]), there's a HUGE change from an end user's viewpoint. I am FORCED to host it elsewhere. Installing an extension from the CWS is as simple as clicking the CWS Install button and accepting the security/permissions warning. Currently, installing an extension from a third-party site is as simple as clicking the site's Install button and accepting the security and permissions warnings. To the end user, these are practically the same experience, and only one extension method must be learned. After this change, the end user will have to learn that extensions are powered by files, that only .crx files are extensions, that a .crx file must be downloaded to install an extension (but only manually if the extension is hosted somewhere other than the CWS), and that they must drag-and-drop a previously downloaded .crx file to a Google Chrome or Chromium tab that has a specific settings page open. This is confusing, and necessitates that a user learn two different workflows to accomplish the same task from different sources. This turns non-CWS extensions into second-class citizens, and it's not as simple as enabling inline installation [2] if your extension would go against Google's policies. [1]: https://developers.google.com/chrome/web-store/program_policies https://developers.google.com/chrome/web-store/program_polic... [2]: https://developers.google.com/chrome/web-store/docs/inline_installation https://developers.google.com/chrome/web-store/docs/inline_i...
slig 14y ago
All the latest malware that I see spreading on facebook came from Chrome extensions. Users don't care, they click and install stuff. Then the extension, which can interact with any page, can spam walls and comments on facebook.
bob_kelso 14y ago
But what happens if someone complains about my extension and Google decides to pull it from the store?
- Kerrick 14y ago
  It happened to me. I am the developer of a joke extension [1] that got reported for abuse one too many times, and Google took my developer account off the Web Store, then they sent me an email about it [2], stating that it was breaking a policy that it simply wasn't. I replied to them explaining the situation [3], and they reinstated my developer account (and that extension) within 4 days [4]. Still, if they had "carefully reviewed" my case and decided against me, I may have had my primary source of income (developing Chrome extensions) taken away from me because of a joke extension. [1]: https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoefjdfiginagghbk https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoe... [2]: https://gist.github.com/514ae4d858027303bc95#file_email.txt https://gist.github.com/514ae4d858027303bc95#file_email.txt [3]: https://gist.github.com/514ae4d858027303bc95#file_reply.txt https://gist.github.com/514ae4d858027303bc95#file_reply.txt [4]: https://gist.github.com/514ae4d858027303bc95#file_response.txt https://gist.github.com/514ae4d858027303bc95#file_response.t...
  - slig 14y ago
    it remembers be about the "I'm rich" iPhone app that was selling for 999 usd. I'm very curious to hear if any user has bought your app.
    - Kerrick 14y ago
      No, nobody has purchased that app. A few people have purchased a $5 recipe app that I made, but nobody has purchased the $999 joke app. If they did, I'd feel really bad and offer them a refund.
tuxidomasx 14y ago
I think restricting access in this way will slow the growth of browser extensions/addons as platforms for launching full-fledged web services and apps. I see more and more web apps relying on extensions for a core part of their functionality, and this is only going to hurt them. For installing non Web Store extensions, I would rather see an extra warning message or notification, rather than a protracted process that many users wont be able to figure out. Extensions are good, but not if they're hard to install.
rsanchez1 14y ago
Such a shame that this appstore mentality is becoming the norm.
Erunno 14y ago
Unfortunately Google's policy doesn't cause only malicious extensions to be removed from their web store. For instance, All Mangas Reader, a combined reader and management tool for online manga sites, was removed from the store for "copyright infringement", although it's the sites that are hosting the mangas doing the infringement and not the extension. Additionally, the copyright problem does not apply to all jurisdictions where the store is accessible. ChromedBird, a Twitter client extension, was also removed because Google didn't like that it contained the "chrome" string (at least this problem was easily alleviated by changing the name to SilverBird). As long as it's still possible to install non-webstore extensions I'll learn to live with that restrictions as it's not an activity I perform often in the first place.
zobzu 14y ago
Yay, another "lets enforce our products to end users" on the cover of "security". Can't wait for Google to remove the checkbox on every Android for "allow 3rd party software install", cause you know, it has to come from Google Play else it's OMG dangerous, and all the users are dumb and check the checkbox and install random apks. And look there's a nice illusion of choice, you need a procedure so complex that almost no one will be willing to do it (and thus you're forced into Google Play). For security. /trustworthy.
- drivebyacct2 14y ago
  What? This is the same as the Android feature. External installs are blocked by default and the user can change that setting and acknowledge the security risk.
jimrandomh 14y ago
I publish an extension, Textcelerator (https://textcelerator.com https://textcelerator.com) off-store. This is the first I'm hearing about this, and it would completely the sign-up flow for my extension. (My extension is in the Chrome store, but my landing page doesn't link there.) Fortunately, it seems this only affects the head versions for now, not the version regular users get on a new install (I just tried it) or an autoupdate, so I have some time to switch links around and make it work. However, I really think there needs to be some sort of deprecation before this is rolled out, probably in the form of a warning on download if Developer mode is enabled, backported to versions 19 and 20.
- BrianEatWorld 14y ago
  Its mentioned further down in the comments, but if youre on the Chrome Store already, you can use Inline Installation. This allows you to use roughly the same flow you use now. https://developers.google.com/chrome/web-store/docs/inline_installation https://developers.google.com/chrome/web-store/docs/inline_i...
BrianEatWorld 14y ago
I have an extension on the Chrome Store, but I also distribute it via bundling and bundling requires an executable. For the bundle, I use the registry method found here: http://code.google.com/chrome/extensions/external_extensions.html http://code.google.com/chrome/extensions/external_extensions... Will this method still work? I originally had the exe simply open a window to our Chrome store listing, but the friction was ridiculous. We would get about 5 installs for roughly every 100 we were paying for.

63 points by Osmose 14y ago

This change is being made without any buy-in from the community, ostensibly for security reasons. I'm skeptical, given the inherent incentives involved.

nimbupani 14y ago

I have no issues with the process, but only concerned with the way this change was made. The issue keeps referring to https://code.google.com/p/chromium/issues/detail?id=55584 https://code.google.com/p/chromium/issues/detail?id=55584 for "details", but there is nothing there except statements asserting how much of a "big problem" this is. I think this is a bigger problem with large open source projects in general where implementors are oblivious to which functionalities developers cherish and value. Any change in such features would require a more thorough explanation.

Osmose 14y ago
It may be an issue of having multiple channels of communication, and the bug tracker is only one of them. For example, though I work for Mozilla, I'm not terribly good at keeping up with the mailing lists, so every so often something pops up in Bugzilla (which I read more frequently) that seems to have come out of nowhere. And of course stuff happens in our IRC channels that never makes it to a bug; same with internal emails. There's a lot of effort involved in making sure your communication is clear and accessible when you have several different modes of it.
- nimbupani 14y ago
  This is very similar to issues in W3C specifications. I just think a bug tracker should be the primary reference material to track discussions around a specific bug. I wish there was a way to link to IRC channel discussion around this bug and otherwise if possible. But nevertheless, I think it would be better if implementors summarize discussions outside of the bug tracker into the issue itself.

eigenvector 14y ago

This nicely illustrates the difference between merely being "open source" (Chromium) and being developed in the open (Firefox). At the very least a decision of this magnitude would have been discussed in the community BEFORE being merged in any sane openly governed project.

justinschuh 14y ago
I don't know why you're claiming this wasn't developed openly. The bugs are all public (the first was filed ~2 years ago); the code is checked into the public tree and has been enabled on canary for almost a month. It wasn't a heavy-handed or rash change, and the impact on both users and developers is minimal.
- apendleton 14y ago
  For those of us that have already-deployed off-store extensions in the wild, what options do we have for migrating our users to the new, Webstore-powered versions? Or will their extensions just silently stop updating (or, worse, working altogether)? If it's the latter, your claim that this change will have minimal impact on developers and users is patently false, since you'll be breaking currently-released and -deployed applications that used to work and met the previously-documented requirements, with no warning whatsoever. Further, the suggestion that this is justified because it was committed to a public repository is absurd: are all developers of Chrome applications supposed to follow every single commit to Chromium's repo to ensure that our extensions won't break? What happened to Chrome's supposed immunity to breaking extensions with new releases, which you claimed made your extension model superior to Firefox's?
  - justinschuh 14y ago
    This change adds a few extra steps for an off-store install, unless the user or administrator configures things otherwise. That's it; updates and existing installations aren't affected at all. The details are very clear if you read the discussion or a few of the comments in the bug.
- 14y ago

jonknee 14y ago

This is a pretty big change to bring in without warning. It would be nice if extensions could be signed but not on the store. I have extensions for internal business apps, they make no sense on the store but having a techy installation process is a big hassle. Google could even host the code (and have the ability to revoke), I just want a way to have "private" extensions that only only delivered to who I want.

tiziano88 14y ago
From the discussion: "In order to install off-store extensions, the user must download them to a directory and drag them onto chrome://extensions/.". Is this not a viable solution for your use case?
- Kerrick 14y ago
  For one thing, this can't be done without a mouse to drag-and-drop with. This limits the extension of off-store extensions to those who can use a mouse, which is an accessibility issue. Are handicapped users or keyboard-only users just thrown to the wayside these days?
  - tiziano88 14y ago
    I was specifically asking about jonknee's use case, I never claimed that this would be an ideal solution for every other possible scenario. That said, your request to have a mouse-free way to install extensions is totally sensible, and I would be surprised and disappointed if they did not think of alternate ways to do that (perhaps using the command-line).
- jonknee 14y ago
  I guess we will find out, that sounds like a pretty big roadblock for the skill level of users I am working with. There seem like there's a better solution out there, at leat for my use case. I serve the crx bundle from the same domain that it interacts with, that seems like it could be pretty malware proof.
14y ago

justinschuh 14y ago

I thought I explained the reasoning on the bug, but I can give it another go. Users are being tricked into installing malicious extensions, and thus getting compromised in significant numbers (Facebook "like" selling is a major target). We have continuously improving measures in the WebStore to catch malicious extensions, and the volume there is very low. However, we don't have a way of catching malicious off-store extensions. So, the best solution is to disallow other sources by default, and provide technically inclined users and enterprise administrators with the ability to add trusted sources. This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about. I'm also surprised Firefox hasn't proposed something similar, since I'm told they're seeing the same trend.

icebraining 14y ago
This is basically the same model that every Linux distro uses, so I'm not sure what the complaints are about. What do you mean? In both Debian and Ubuntu I can install a .deb (equivalent to .crx) just fine. I don't have to approve its source beforehand.
- justinschuh 14y ago
  The extension manifest has update information in it, so when you install a CRX you're inherently configuring an installation source. That's something you have to take into account here.
  - Kerrick 14y ago
    The official Google Chrome .deb for Debian/Ubuntu downloaded from google.com/chrome sets up a software source as well, so you can't say that's not how .deb files work. kerrick@psyduck:~$ ls /etc/apt/sources.list.d/ google-chrome.list kerrick@psyduck:~$ cat /etc/apt/sources.list.d/google-chrome.list ### THIS FILE IS AUTOMATICALLY CONFIGURED ### # You may comment out this entry, but any other modifications may be lost. deb http://dl.google.com/linux/chrome/deb/ stable main

marshray 14y ago

Was there some new law of nature added in the last few years that says as soon as any app platform takes the lead its vendor must begin restricting the distribution channels available to 3rd party developers? Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?

georgemcbay 14y ago
"Wouldn't it be awesome if Microsoft and Apple forbade competing walled gardens (such as Chrome) from running apps on their operating systems?" That's funny because both of them have already done that. Not on Windows, and MacOS, but on WinPhone7/Win8Metro and iOS.
justinschuh 14y ago
What? The only thing changing here is a default configuration value that actually gives users and administrators more control. This isn't like iOS or Windows RT, where you have to download an exploit and void your warranty to install software from a third-party source.
- marshray 14y ago
  Yes, it may be not evil like WindowsRT and iOS and it may improve the security of users. But it's another brick in the wall being erected between 3rd party developers and users. 2000 Microsoft: "Developers, developers, developers" 2012 Apple, Microsoft, Google: "Won't someone please think of the poor users' security! (and give us a NN% cut off the top while you're at it"
- Kerrick 14y ago
  If I want to distribute an extension that users want but Google won't allow, such as a pornography browsing extension (disallowed by the CWS policies [1]), there's a HUGE change from an end user's viewpoint. I am FORCED to host it elsewhere. Installing an extension from the CWS is as simple as clicking the CWS Install button and accepting the security/permissions warning. Currently, installing an extension from a third-party site is as simple as clicking the site's Install button and accepting the security and permissions warnings. To the end user, these are practically the same experience, and only one extension method must be learned. After this change, the end user will have to learn that extensions are powered by files, that only .crx files are extensions, that a .crx file must be downloaded to install an extension (but only manually if the extension is hosted somewhere other than the CWS), and that they must drag-and-drop a previously downloaded .crx file to a Google Chrome or Chromium tab that has a specific settings page open. This is confusing, and necessitates that a user learn two different workflows to accomplish the same task from different sources. This turns non-CWS extensions into second-class citizens, and it's not as simple as enabling inline installation [2] if your extension would go against Google's policies. [1]: https://developers.google.com/chrome/web-store/program_policies https://developers.google.com/chrome/web-store/program_polic... [2]: https://developers.google.com/chrome/web-store/docs/inline_installation https://developers.google.com/chrome/web-store/docs/inline_i...

slig 14y ago

All the latest malware that I see spreading on facebook came from Chrome extensions. Users don't care, they click and install stuff. Then the extension, which can interact with any page, can spam walls and comments on facebook.

bob_kelso 14y ago

But what happens if someone complains about my extension and Google decides to pull it from the store?

Kerrick 14y ago
It happened to me. I am the developer of a joke extension [1] that got reported for abuse one too many times, and Google took my developer account off the Web Store, then they sent me an email about it [2], stating that it was breaking a policy that it simply wasn't. I replied to them explaining the situation [3], and they reinstated my developer account (and that extension) within 4 days [4]. Still, if they had "carefully reviewed" my case and decided against me, I may have had my primary source of income (developing Chrome extensions) taken away from me because of a joke extension. [1]: https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoefjdfiginagghbk https://chrome.google.com/webstore/detail/gnbchcphjnmbmknnoe... [2]: https://gist.github.com/514ae4d858027303bc95#file_email.txt https://gist.github.com/514ae4d858027303bc95#file_email.txt [3]: https://gist.github.com/514ae4d858027303bc95#file_reply.txt https://gist.github.com/514ae4d858027303bc95#file_reply.txt [4]: https://gist.github.com/514ae4d858027303bc95#file_response.txt https://gist.github.com/514ae4d858027303bc95#file_response.t...
- slig 14y ago
  it remembers be about the "I'm rich" iPhone app that was selling for 999 usd. I'm very curious to hear if any user has bought your app.
  - Kerrick 14y ago
    No, nobody has purchased that app. A few people have purchased a $5 recipe app that I made, but nobody has purchased the $999 joke app. If they did, I'd feel really bad and offer them a refund.

tuxidomasx 14y ago

I think restricting access in this way will slow the growth of browser extensions/addons as platforms for launching full-fledged web services and apps. I see more and more web apps relying on extensions for a core part of their functionality, and this is only going to hurt them. For installing non Web Store extensions, I would rather see an extra warning message or notification, rather than a protracted process that many users wont be able to figure out. Extensions are good, but not if they're hard to install.

rsanchez1 14y ago

Such a shame that this appstore mentality is becoming the norm.

Erunno 14y ago

Unfortunately Google's policy doesn't cause only malicious extensions to be removed from their web store. For instance, All Mangas Reader, a combined reader and management tool for online manga sites, was removed from the store for "copyright infringement", although it's the sites that are hosting the mangas doing the infringement and not the extension. Additionally, the copyright problem does not apply to all jurisdictions where the store is accessible. ChromedBird, a Twitter client extension, was also removed because Google didn't like that it contained the "chrome" string (at least this problem was easily alleviated by changing the name to SilverBird). As long as it's still possible to install non-webstore extensions I'll learn to live with that restrictions as it's not an activity I perform often in the first place.

zobzu 14y ago

Yay, another "lets enforce our products to end users" on the cover of "security". Can't wait for Google to remove the checkbox on every Android for "allow 3rd party software install", cause you know, it has to come from Google Play else it's OMG dangerous, and all the users are dumb and check the checkbox and install random apks. And look there's a nice illusion of choice, you need a procedure so complex that almost no one will be willing to do it (and thus you're forced into Google Play). For security. /trustworthy.

drivebyacct2 14y ago
What? This is the same as the Android feature. External installs are blocked by default and the user can change that setting and acknowledge the security risk.

jimrandomh 14y ago

I publish an extension, Textcelerator (https://textcelerator.com https://textcelerator.com) off-store. This is the first I'm hearing about this, and it would completely the sign-up flow for my extension. (My extension is in the Chrome store, but my landing page doesn't link there.) Fortunately, it seems this only affects the head versions for now, not the version regular users get on a new install (I just tried it) or an autoupdate, so I have some time to switch links around and make it work. However, I really think there needs to be some sort of deprecation before this is rolled out, probably in the form of a warning on download if Developer mode is enabled, backported to versions 19 and 20.

BrianEatWorld 14y ago
Its mentioned further down in the comments, but if youre on the Chrome Store already, you can use Inline Installation. This allows you to use roughly the same flow you use now. https://developers.google.com/chrome/web-store/docs/inline_installation https://developers.google.com/chrome/web-store/docs/inline_i...

BrianEatWorld 14y ago

I have an extension on the Chrome Store, but I also distribute it via bundling and bundling requires an executable. For the bundle, I use the registry method found here: http://code.google.com/chrome/extensions/external_extensions.html http://code.google.com/chrome/extensions/external_extensions... Will this method still work? I originally had the exe simply open a window to our Chrome store listing, but the friction was ridiculous. We would get about 5 installs for roughly every 100 we were paying for.