Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabled by Mozilla #26

Open
jeremiahlee opened this issue Oct 21, 2019 · 29 comments

Comments

@jeremiahlee
Copy link
Owner

@jeremiahlee jeremiahlee commented Oct 21, 2019

tl;dr Switch to Google Translate This extension


Oct 24, 2019:

I wrote about the situation on my blog.

Vote up on


Original post:
Page Translator, the self-distributed variant hosted here, has been remotely disabled by Mozilla. The reason is listed as "executing remote code".

https://bugzilla.mozilla.org/show_bug.cgi?id=1589974

I have reached out to Mozilla in the above Bugzilla ticket and on Twitter.

Page Translator—as described—loads external JavaScript from Google or Microsoft to translate a page in-line. As noted in #12, Mozilla AMO prohibited extensions distributed through AMO from loading external JavaScript. However, self-distributed extensions were permitted to load external JavaScript.

If this policy has changed, I was not aware of it. It is possible the policy for AMO-distributed and self-distributed add-ons has merged.

I want my Page Translator extension to be made irrelevant by Firefox having built-in language translation, like Google Chrome and Microsoft Edge. It is a critical feature used by millions of people daily. It bridged a feature gap. Mozilla killing this add-on without replacing it hurts users.

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 21, 2019

I have written amo-admins@mozilla.com per the terse instruction of Andreas Wagner..

Hello AMO Admins,

My extension Page Translator received a hard block today. https://bugzilla.mozilla.org/show_bug.cgi?id=1589974

My extension inserts the Google Translator or Microsoft Translate JavaScript widget onto a page when invoked by the user. Unfortunately, loading their code from their CDN is the only way those services permit their use.

I understand the AMO policy of prohibiting externally loaded JavaScript. This is why my AMO-hosted extension was removed. I accept that, as it is your policy.

The hard block today, however, affected the self-distributed side-loaded extension. Previously, there was a MDN page for extension distribution that said self-distributed extensions could load external code. (It seems that the MDN pages have moved to https://extensionworkshop.com/ and do not have an edit history.)

Has the policy for loading external code been unified for both AMO-distributed and self-distributed add-ons?

If so, I accept your decision and would encourage you to explicitly state this change.

If not, I would appreciate the re-enabling of my self-distributed extension.

Thank you for your care in protecting the Web.

Best,
Jeremiah Lee

@grahamperrin

This comment has been minimized.

Copy link

@grahamperrin grahamperrin commented Oct 21, 2019

😢 (sad face)

@Armand68

This comment has been minimized.

Copy link

@Armand68 Armand68 commented Oct 22, 2019

😢😢😢😢

I am angry, Jeremiah: your add-on is marvellous - and obviously secure.

Thanks for your work, anyway.

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 22, 2019

I'm an American living in Stockholm. It pains me to have to use Chrome regularly now when interacting with Swedish government websites. I wish I had a better option for myself and to share with you. 😢

@juanro49

This comment has been minimized.

Copy link

@juanro49 juanro49 commented Oct 22, 2019

Bad News :-(
For the moment, I enabled old integrated translator in Firefox with my Yandex API (Google and Bing doesn't work now) https://instatecno.com/como-habilitar-el-traductor-en-firefox/ while Mozilla launches its new integrated translator https://ubunlog.com/mozilla-ya-esta-trabajando-en-el-desarrollo-su-propio-sistema-de-traduccion-automatica/

Yandex isn't the best translator (I prefeer DeepL, Micosoft Translator or Apertium.org) but for the moment is the unique option without page-translator extension

@rahidz

This comment has been minimized.

Copy link

@rahidz rahidz commented Oct 22, 2019

Thanks to some kind folks on Reddit I was able to get the add-on back up and running, but the steps are complex enough to deter most users (extracting, editing, and re-compressing the XPI, plus having to be on a developer version, plus having to edit about:config). Hope Mozilla changes their minds on this soon (and hopefully Google isn't pressuring them to remove this in any way).

@mustafababil

This comment has been minimized.

Copy link

@mustafababil mustafababil commented Oct 22, 2019

I was looking for an extension just like this one, and came across with the bad news. Hope Mozilla fixes this issue, and saves me from using Chrome whenever I need page translation.

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 22, 2019

You might try this extension: https://github.com/andreicristianpetcu/google_translate_this

It does the same thing in the same way as Page Translator and likely will be blocked by Mozilla, but this is a cat and mouse game worth playing if you rely on full-page in-line language translation.

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 22, 2019

Hi Jeremiah! 💛 I agree that Mozilla should notify developers about important extension policy changes, this is partially a communication failure.

The other pressing issue is that users have lost the right to run private extensions in the release version of Firefox, without needing to hand over their source code to Mozilla.

While there are security benefits to disallowing unsigned extensions by default, it is not clear why there is no option to turn off this behavior, perhaps by making it configurable only with administrator rights.

There is a workaround though that does not require you to compile Firefox or use a different edition. This is how you allow unsigned extensions in Firefox on Arch Linux, the same files can be edited on Windows and macOS, restart the browser after changes:

  sudo tee /usr/lib/firefox/defaults/pref/config-prefs.js &>/dev/null <<EOF
  pref("general.config.obscure_value", 0);
  pref("general.config.filename", "config.js");
  pref("general.config.sandbox_enabled", false);
  EOF

  sudo tee /usr/lib/firefox/config.js &>/dev/null <<EOF
  // keep this comment
  try {
    Components.utils
      .import('resource://gre/modules/addons/XPIDatabase.jsm', {})
      .XPIDatabase['SIGNED_TYPES'].clear();
  } catch (ex) {
    Components.utils.reportError(ex.message);
  }
  EOF

If any Firefox engineers are reading this, please don't try to subvert the above workaround, it requires multiple steps and administrator rights to set up, and we must all agree that it is of little sense for Firefox to try defending against unwanted programs or malware that has root access on the device.

It would be best to offer an official way to allow installing local, unsigned extensions, and make the option configurable only by root, while also showing appropiate warnings about the potential risks of installing unsigned extensions.

We must consider introducing sensible default options in Firefox, while also educating users and allowing them to override certain features, instead of placing marginal security benefits above user liberties and free choice.

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 22, 2019

Response from Mozilla:

Hi Jeremiah,

as far as I recall, the restriction that remote code is not allowed has
applied forever, both for self-hosted and listed extensions. In any
case, our current policy does not allow it. I'm aware this causes issues
for add-on using widgets from websites and apologize for the
inconvenience. You may look into checking if there is a REST api that
could beused instead.

Thanks for getting in touch.

--
Philipp Kewisch
Add-on Review Team
Mozilla

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 22, 2019

I wrote about the situation: https://www.jeremiahlee.com/posts/page-translator-is-dead/
I included a screenshot and Internet Archive link to the policy that permitted loading external code for "unlisted" add-ons.

Vote up on HN: https://news.ycombinator.com/item?id=21328470
or Lobsters: https://lobste.rs/s/ppprkq/sad_state_language_translation_firefox

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 22, 2019

A Firefox engineer has disabled the above configuration option, less than two hours after I posted the workaround in this thread.

I appreciate the vigilance, but it would be even better to actually publish a technical reasoning for why do you folks believe Firefox is above the device owner, and the root user, and why there should be no possibility through any means and configuration protections to enable users to run their own code in the release version of Firefox.

https://phabricator.services.mozilla.com/D50136

I will need to find a workaround for one of my private extensions that controls devices in my home network, and its source code cannot be uploaded to Mozilla because of my and my family's privacy.

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 22, 2019

I believe that beginning to distribute tools that patch Firefox and give back power to users and allow them to install unsigned extensions is necessary when an organization is taking away our rights without giving us a compelling reason for doing so.

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 22, 2019

The issue for disabling the config option that gives us a workaround for running unsigned extensions is tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=1514451

@JanZerebecki

This comment has been minimized.

Copy link

@JanZerebecki JanZerebecki commented Oct 23, 2019

It should be possible to implement the functionality of page-translator via a more popular extension that is designed to inject arbitrary data into websites, including remote code, e.g. https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ .

@serovar

This comment has been minimized.

Copy link

@serovar serovar commented Oct 23, 2019

The addon works for me on Firefox 69 stable with extensions.blocklist.enabled set to false in about:config

@bovine3dom

This comment has been minimized.

Copy link

@bovine3dom bovine3dom commented Oct 23, 2019

@dessant somewhat off-topic: there are a number of Mozilla-approved ways to install unsigned extensions, especially on Linux. See tridactyl/tridactyl#1927

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 23, 2019

Thanks @bovine3dom, I'll consider releasing a cross-platform patching tool for Firefox to make the workarounds accessible for everyone if Mozilla goes forward with forcing the AutoConfig sandbox in release builds.

All of the workarounds require administrative access, though AutoConfig is the most convenient. I do not understand what is the threat model of not allowing the root user to configure Firefox, since malware could just replace the entire Firefox binary.

Blocking users from installing unsigned extensions without offering a cross-platform way to disable the feature brings minimal security benefits while concentrating power in the hands of the browser vendor. Not even Google is this heavy-handed, they allow installing local extensions in Chrome after users enable an option, although a warning is shown on browser restarts about the presence of external extensions, which can be dismissed.

Forcing signed extensions in the release version of Firefox is also uncompetitive, because it prevents third-party browser extension stores from gaining foothold.

@serovar

This comment has been minimized.

Copy link

@serovar serovar commented Oct 23, 2019

it's too risky a workaround; I should not recommend it to anyone.

While I agree that it is a terrible workaround, for now it's the only one that works on stable and beta channels.

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Oct 24, 2019

I responded to Mozilla:

Thank you, Philipp, for the kind response. We both want to make Firefox the best browser possible and I'm just trying to understand.

I found an archive of the former policy. https://web.archive.org/web/20180311125311/https://developer.mozilla.org/en-US/Add-ons/AMO/Policy/Reviews

On this page, you will see that "unlisted" (self-distributed) add-ons are permitted to execute remote code. This was the approach recommended to me by AMO reviewers when my listed add-on was de-listed. I understand there is a new policy, but it is a new policy. I would have liked the opportunity from you to withdraw my add-on, rather than have it hard blocked.

I am super excited by what Mozilla announced today regarding client-side language translation. I have always wanted my add-on to be made irrelevant. Please consider what the thousands of people who relied on in-page language translation provided by Page Translator must do until Mozilla can ship its revolutionary language translation. Our best option for now is to use Chrome. How many are going to come back to Firefox once it has feature parity with Chrome?

I have described the technical arguments for affording nuance to the current policy here: https://www.jeremiahlee.com/posts/page-translator-is-dead/

Best regards,
Jeremiah

Response from Mozilla:

Hi Jeremiah,

of course, I appreciate your support and am sorry for the inconvenience
and potential miscommunication back when moving to self-hosted. While it
seems there were limited cases where it was allowed, please also see the
footnote under which conditions. If you are injecting the widgets onto
web pages it does not seem these criteria were met.

I've read your article, but unfortunately this is not a restriction we
will be lifting.

If you find a way to provide this feature in compliance with our
policies, we'd be willing to lift the block in a way that you could
submit a new version for your users.

Thanks,
Philipp

This is it. I'm done with Page Translator, but you don't have to be. Fork the repo. Distribute the code yourself. This is now a cat-and-mouse game with Mozilla. Users will have to jump from one extension to another until language translation is a standard feature or the extension policy changes.

@mjfa12

This comment has been minimized.

Copy link

@mjfa12 mjfa12 commented Oct 27, 2019

Thank you for the work you put into this. You extension was always my favourite for web translations. And you are right... chrome it is... for now at least.

@dessant

This comment has been minimized.

Copy link

@dessant dessant commented Oct 31, 2019

To give users more control over their extensions, support for sideloaded extensions will be discontinued.

https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/

@jeremiahlee

This comment has been minimized.

Copy link
Owner Author

@jeremiahlee jeremiahlee commented Nov 3, 2019

Sadly, the extension I had been recommending since Page Translator got killed was just killed for the same reason. andreicristianpetcu/google_translate_this#19

As I've said, I'm done with Mozilla's user-hostile game. Switch to Edge on Windows or Chrome elsewhere when you need translation.

@sprite-1

This comment has been minimized.

Copy link

@sprite-1 sprite-1 commented Nov 3, 2019

Well since I only use a select few curated extensions in Firefox anyway, I guess it's fine to disable extensions.blocklist.enabled if it means I can use the addons that I need. It's not like I install new addons every other day.

@grahamperrin

This comment has been minimized.

@grahamperrin

This comment has been minimized.

Copy link

@grahamperrin grahamperrin commented Nov 6, 2019

extensions.blocklist.enabled

@HerrHulaHoop wrote:

… I get that it's a "security issue" to disable it, but as long as people don't click on Install button for random extensions, it should be fine.

Think beyond installation. Think updates, automated updates, and so on. Think of the Mozilla-recommended extensions that repeatedly fail to publish release notes at AMO. Think beyond random.

I know of at least one highly respected non-random extension that – through a succession of updates – became disreputable. Eventually blocked by Mozilla, and the block was entirely proper.

To disable use of the blocklist is described as terrible; as dangerous; and so on, and I don't disagree with these perceptions of the approach. It is deeply contentious … whilst reactions in GitHub are fairly restrained, I see high emotion elsewhere.

Happily, the update to https://www.jerJemiahlee.com/posts/page-translator-is-dead/ made no mention of the approach 👍

@devjao

This comment has been minimized.

Copy link

@devjao devjao commented Nov 9, 2019

This is not a good news, as I checked last week I can't suddenly use the probably "the best translator for firefox yet", simple click and done. I hope this gets resolved. Btw, the other extension is also now blocked by firefox

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.