4 ms·

YC W19 Sapling here. We have a freemium browser extension that acts as a grammar checker. Couple thoughts below: 1. Source code. You are allowed to minify sour

YC W19 Sapling here. We have a freemium browser extension that acts as a grammar checker. Couple thoughts below: 1. Source code. You are allowed to minify source code. Chrome actually recommends minifying source to improve performance. If you require certain permissions you'll have to submit un-minified source for security review. 2. Cloud/subscription based models are the way to go if piracy is an issue, but it doesn't make sense for all products. Licensing hasn't been an issue for Sapling fortunately because the "brains" of our app are in the cloud. I know hacker news is very privacy conscious but our language models are too large to run on a user's end machine right now. Spier Pro seems like a useful web-scraping helper. People who can pirate a chrome extension probably can probably run xpath scripts or a free xpath testing extension themselves so if I were Amy I wouldn't worry _too_ much about piracy. 3. Forked Code. There should be no reason to do it. Firefox and Edge have done a lot of work to support most of the chrome apis. You can handle minor edge cases build time with a variable toggle. Keep the same manifest, even. Browsers are good about ignoring keywords in the manifest they don't recognize. My recommendation is to pretend they are the same platform until you find bugs/issues and hard code around them. Theres a handful but it's very manageable. [0] https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.html https://blog.chromium.org/2018/10/trustworthy-chrome-extensi... [1] https://stackoverflow.com/questions/37649620/does-chrome-market-accept-extensions-with-minified-and-or-obfuscated-source-code/56006881#56006881 https://stackoverflow.com/questions/37649620/does-chrome-mar... [2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

diob 6y ago
I've had some extensions that were approved, had no changes, then suddenly disapproved because someone on the chrome team decided to re-review it and didn't understand webpack / minification. I've been so busy I haven't bothered to go try and "fix" the extensions. These are OSS extensions, nothing paid, so I all the code is available for the reviewer to read by the way.
- mastermojo 6y ago
  Yea, I've seen some some stories around Chrome review problems, most recently around pushbullet. I think it the review outcome depends a little bit on a mixture of reviewer and the permissions required. The more permissions an extension asks for the longer the review process, and unfortunately some false positive flags do happen now and then.
AlexITC 6y ago
> 3. Forked Code. There should be no reason to do it The actual problem is that some APIs are different, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox. > Keep the same manifest Actually, it depends on which options you use, for example, i18n placeholders aren't supported in Firefox while they are in Chrome, in Edge, the manifest is drastically different.
- mastermojo 6y ago
  I think an analogy everybody would understand is to think of a regular web app. If you need to add Internet Explorer support to a website that only supports Chrome, does it make sense to fork the website? Almost never. You just inline hardcoded elements and style stuff that only IE browsers understand masquerading as html comments so that other browsers will ignore it. At most, maybe you run/serve a platform specific piece of js/css/html. Maintaining hundreds of lines of duplicate code can become a logistical mess. Most extensions will see 95-100% shared code between platforms.

diob 6y ago

I've had some extensions that were approved, had no changes, then suddenly disapproved because someone on the chrome team decided to re-review it and didn't understand webpack / minification. I've been so busy I haven't bothered to go try and "fix" the extensions. These are OSS extensions, nothing paid, so I all the code is available for the reviewer to read by the way.

mastermojo 6y ago
Yea, I've seen some some stories around Chrome review problems, most recently around pushbullet. I think it the review outcome depends a little bit on a mixture of reviewer and the permissions required. The more permissions an extension asks for the longer the review process, and unfortunately some false positive flags do happen now and then.

AlexITC 6y ago

> 3. Forked Code. There should be no reason to do it The actual problem is that some APIs are different, for example, in Chrome the notifications has a richer set of options but you need to be careful to not use the ones not supported by Firefox. > Keep the same manifest Actually, it depends on which options you use, for example, i18n placeholders aren't supported in Firefox while they are in Chrome, in Edge, the manifest is drastically different.

mastermojo 6y ago
I think an analogy everybody would understand is to think of a regular web app. If you need to add Internet Explorer support to a website that only supports Chrome, does it make sense to fork the website? Almost never. You just inline hardcoded elements and style stuff that only IE browsers understand masquerading as html comments so that other browsers will ignore it. At most, maybe you run/serve a platform specific piece of js/css/html. Maintaining hundreds of lines of duplicate code can become a logistical mess. Most extensions will see 95-100% shared code between platforms.