Skip to content
This repository has been archived by the owner. It is now read-only.

Disabled by Mozilla #26

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

Disabled by Mozilla #26

jeremiahlee opened this issue Oct 21, 2019 · 83 comments

Comments

@jeremiahlee
Copy link
Owner

@jeremiahlee jeremiahlee commented Oct 21, 2019

tl;dr Use Microsoft Edge browser when you need in-page translation.

tl;dr Switch to Google Translate This extension Mozilla blocked that too


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
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
Copy link

@grahamperrin grahamperrin commented Oct 21, 2019

😢 (sad face)

@Armand68
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Copy link

@grahamperrin grahamperrin commented Nov 5, 2019

@grahamperrin
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 👍

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Dec 11, 2019

#26 (comment):

It just gets stuck …

No problem here.

Screen recording – Chrome Store Foxified, Firefox Developer Edition and a non-signed extension:

@sprite-1
Copy link

@sprite-1 sprite-1 commented Dec 11, 2019

Screen recording – Chrome Store Foxified, Firefox Developer Edition and a non-signed extension:

I am using the stable release though, with xpinstall.signatures.required set to false

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Dec 11, 2019

Thanks,

I am using the stable release

Can you install Firefox Developer Edition alongside Firefox?


From https://discourse.mozilla.org/t/s3-translator/48247/2?u=grahamperrin:

… Firefox Beta will not accept unverified extensions. …

– the same is true for Firefox.

Add-ons/Extension Signing - MozillaWiki

@HerrHulaHoop
Copy link

@HerrHulaHoop HerrHulaHoop commented Dec 15, 2019

maybe you misunderstood. For the solution that I suggested, that's not the case.

I tried your method. The extension asked permission for Collection of statistics immediately after installation. So whatever problems Mozilla had with S3.Translator still stands.

I know, you don't trust Mozilla but do you also not trust the developer?

I absolutely do! That is the whole point of this discussion. Mozilla doesn't trust S3.Translator or jeremiahlee but I do. They blocked page-translator for pedantic reasons. Which is why I want the option to override their decision to specifically install few extensions that I'm okay with.

Also, your question is phrased incorrectly. I never said I don't trust Mozilla, that was Shadowex3. I mentioned in my previous message that Mozilla is leagues ahead of the rest when it comes to respecting users. What I don't like is how they've killed so many useful extensions without any sane method of overriding their decisions.

Well, we've gone over this a couple times now. Mozilla isn't going to change their stance and will probably take a while to come out with their own translation service. Until they do, we've got to make due with the alternatives mentioned above.

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Dec 15, 2019

permission for Collection of statistics

Any number of extensions might request this.

whatever problems Mozilla had with S3.Translator still stands.

Not necessarily.

https://discourse.mozilla.org/t/s3-translator/48247/7?u=grahamperrin some history and comparisons.

https://discourse.mozilla.org/t/s3-translator/48247/8?u=grahamperrin invitation to inspect code.

From recent private discussion I know that Mozilla is aware of the topic. Whether they have reviewed the code, I can't guess.

@dessant
Copy link

@dessant dessant commented Dec 15, 2019

Avira Browser Safety has 400k Firefox users, the extension uploads the user's browsing history and executes arbitrary remote code from the publisher, not a third-party trusted source.

The extension appears to have been unlisted from Firefox Add-ons, without receiving a hard block.

https://palant.de/2019/12/11/problematic-monetization-in-security-products-avira-edition/
https://addons.mozilla.org/en-US/firefox/addon/avira-browser-safety/
https://blocked.cdn.mozilla.net/

@GJRobert
Copy link

@GJRobert GJRobert commented Dec 16, 2019

@grahamperrin I appreciate your efforts to make many things work again here and there (including your sharings about Waterfox on Reddit).

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Dec 16, 2019

Equal thanks to everyone else who offered workarounds …

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Dec 23, 2019

From #26 (comment):

Mozilla should notify developers about important extension policy changes,

True; it's important to observe posts from Mozilla.

The 10th June changes were publicised on 2nd May:

… If you have questions about these updated policies or would like to provide feedback, please post to this forum thread.

In addition to Mozilla's posts, which may have been overlooked, there was publicity elsewhere, for example:

The ZDNet article began with this headline:

Mozilla also plans to be more aggressive towards taking down extensions that break its policies, with a focus on security issues.

– and was very well publicised.

Anyone who was aware of the security concern (two years before the block) might have asked Mozilla whether the changes to policy, which became effective on 10th June, might have an impact on Page Translator …


this is partially a communication failure. …

I guess that the significance of Mozilla's posts (and related publicity) was simply lost in the coincidental frenzy around armagadd-on 2.0.

I reckon that it was:

  • less a communication failure
  • more a failure to pay attention

– no disrespect intended. Given the unfortunate coincidence, it's almost entirely understandable that everyone concerned lost sight of Mozilla's forewarning.

HTH

@nl255
Copy link

@nl255 nl255 commented Jan 1, 2020

Have you considered turning it into a Waterfox extension instead? By that I mean changing the name or whatever is necessary so that it no longer trips the blocklist and then simply not submitting it to Mozilla to be signed at all? Surely Mozilla wouldn't go to the trouble of updating their blacklist to block extensions that don't even run on (vanilla) Firefox at all due to never having been signed in the first place.

@grahamperrin
Copy link

@grahamperrin grahamperrin commented Jan 1, 2020

The block list does include non-signed extensions.

@nl255
Copy link

@nl255 nl255 commented Jan 1, 2020

The block list does include non-signed extensions.

Does it include extensions that were both written after signing became mandatory but were never submitted to Mozilla for signing? Because that just doesn't make sense unless they are trying to "protect" Waterfox and Pale Moon users as well.

@endolith
Copy link

@endolith endolith commented Jan 28, 2020

By that I mean changing the name or whatever is necessary so that it no longer trips the blocklist and then simply not submitting it to Mozilla to be signed at all?

Would that work? If so I really hope someone can do it.

@Mitezuss
Copy link

@Mitezuss Mitezuss commented Jan 30, 2020

Just can sign the extension for private use... (having a acc in mozilla) and will be work

@devjao
Copy link

@devjao devjao commented Jan 31, 2020

@Mitezuss
Copy link

@Mitezuss Mitezuss commented Jan 31, 2020

@devjao

Check

https://extensionworkshop.com/documentation/publish/signing-and-distribution-overview/

Distributing your add-on

https://extensionworkshop.com/documentation/publish/submitting-an-add-on/

Need set ON YOUR OWN

Before sign, need edit the manifest.json and edit

applications": {
"gecko": {
"id:":

Changing the ID (at least a digit) for exclude from the blacklist

regards

Edit: the default ID is

"id": "{79f4bfc6-b1da-4dc4-85cc-ecbcc5dd152e}",

So, you just change a letter (HEX code), for sample: (7 -> 4)

"id": "{49f4bfc6-b1da-4dc4-85cc-ecbcc5dd152e}",

Note: there should be not installed another addon with same ID, because, if there are, will be problem.

Too can rewrite all the ID, for sample:

"id": "pagetranslator@itisback.org",

remember this addon need be signed FOR OWN USE

Ps: sorry i have bad english =) (not my lang)

@devjao
Copy link

@devjao devjao commented Jan 31, 2020

@HerrHulaHoop
Copy link

@HerrHulaHoop HerrHulaHoop commented Jan 31, 2020

I'm interested to know if this works as well. Would be the best way forward for me since I still haven't gotten used to the workarounds.

@Armand68
Copy link

@Armand68 Armand68 commented Jan 31, 2020

I am interested to...

@endolith
Copy link

@endolith endolith commented Feb 1, 2020

Is there a way to just publish the add-on without the signature that's on the blacklist so we can all just use that version?

@sprite-1
Copy link

@sprite-1 sprite-1 commented Feb 3, 2020

Is there a way to just publish the add-on without the signature that's on the blacklist so we can all just use that version?

Yes but it just just gets blocked again

@endolith
Copy link

@endolith endolith commented Feb 3, 2020

How would it get blocked by Mozilla if Mozilla doesn't know about it?

@sprite-1
Copy link

@sprite-1 sprite-1 commented Feb 3, 2020

I assume people report this as well as every other clone addon of this that gets published.

There have been others that are pretty much clones of this and they all get blocked eventually, it's a cat and mouse chase

@devjao
Copy link

@devjao devjao commented Feb 3, 2020

@Armand68
Copy link

@Armand68 Armand68 commented Feb 3, 2020

Another alternative is add a bookmark with the URL:

How do you write it in the file? If one just write «javascript: (etc.: the end of your code)» in a file text, even with an .js extension, it does'nt work !

@sprite-1
Copy link

@sprite-1 sprite-1 commented Feb 3, 2020

@Armand68 what file? You just right click on the bookmarks bar and create a new bookmark then paste the code here:
image

As for me, I prefer it sitting on the address bar as a tiny icon which is why I opt to use the addon instead

@Armand68
Copy link

@Armand68 Armand68 commented Feb 3, 2020

Oh yes, it's works perfectly. Many many thanks...

@pbodnar
Copy link

@pbodnar pbodnar commented Oct 17, 2020

@jeremiahlee, I sympathize with you, the lack of openness to discussion from Firefox (Andreas Wagner) is unfortunate.

For now, I'm using the Simple Translate extension which seems to be just enough for my basic translation needs. Hopefully they won't block it as well, provided it uses just REST API calls (I didn't check that myself).

@HerrHulaHoop
Copy link

@HerrHulaHoop HerrHulaHoop commented Apr 11, 2021

Just found Translate Web Pages, which seems to do translations using Google's API instead of executing remote code. It works perfectly for me so far and probably won't be blocked by AMO. Give it a go!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests