From Beta 67 Firefox improperly including JSECOIN among ALL cryptocurrency miners




2 months ago
Last month


(Reporter: ecnels, Unassigned, NeedInfo)


(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)



(3 attachments)



2 months ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.88 Safari/537.36 Vivaldi/2.4.1488.36
Firefox for Android

Steps to reproduce:

As of Beta 67, the Checkbox for by-default blocking all cryptocurrency miners is discriminating against JSECOIN: A 100% Voluntary, Opt-In Miner and potentially other GOOD miners.

Actual results:

With the Cryptoiner Checkbox selected, scripts run which block JSECOIN.

Expected results:

Because JSECOIN is 100%, explicit USER-OPT-IN, users will always be asked whether they want their CPU used for mining at JSECOIN-hosted-sites. The Default behavior of Firefox is to NOT even allow the question to be asked (see the Firefox code: "license": "Copyright 2010-2019 Disconnect, Inc. / This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. / This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. / You should have received a copy of the GNU General Public License along with this program. If not, see",
"categories": {
"Advertising": [
{. . .
"JSE": {
"": [
"performance": "true"

This is incorrect as it by default, lumps JSECOIN into the wrong category (Involuntary/Unknown use of a users computer cycles, versus Known and Desired use of a users computer cycles by that Site Visitor). There needs to be a Checkbox that By-Default allows Opt-In Miners, (or it's equivalent), because Opting-In should be the user's choice. It's the secret monetizing by stealing user CPU cycles that is to be discouraged, not legitimate means of monetizing anything with which users explicitly agree.

Search in the enclosed .txt file for JSE to see that JSECOIN is incorrectly Blocked as though it's a stealth miner without user-permission to run (which JSE MUST HAVE in order to run on a users system).


Comment 1

2 months ago


2 months ago
Component: Untriaged → Tracking Protection

Comment 2

2 months ago
Comment on attachment 9060748 [details]

Flags: needinfo?(ecnels)
Attachment #9060748 - Flags: review+

Steven, Arthur, is this something you want to take to disconnect or should we close this bug?

Flags: needinfo?(senglehardt)
Flags: needinfo?(arthur)

Comment 4

2 months ago

Sorry Folks that I'm a bit rusty on this process; for example, I received the email below from Mozilla indicating my patch was approved.

The question is, do I need to make the code changes and submit them via:

I'm readily capable of removing the JSECOIN checks from that code, but would need Push Access to the Repository. The email sent to me from Mozilla (below) explains commit access steps, but I had not submitted an actual code-patch candidate - just the Bug Report on what needed to be done. Do I need to make the code changes and actually submit the approved patch or is the actual code change to be done by another person (senglehardt?, arthur? other)?

Best Regards,


Email from Mozilla on 2019-04-27:

Congratulations on having your first patch approved, and thank you for your contribution to Mozilla.

Once the patch is correctly formatted and all the nits are addressed, you should ask the person who reviewed your patch to push it to the try server for testing.

Once it comes back passing all our tests, your patch will be ready to check in! To get your patch checked in you can add "checkin-needed"
to the Keywords field on the bug summary page, and one of our helpful Code Sheriffs will come by to merge it into the Mozilla codebase.

Contributors with commit access can set up Mercurial to make their lives much easier. You can get learn how to get access to the Try Server here:

And you can learn more about how Mozilla uses Mercurial here:

While that's underway, we'd be happy to work with you on something new; you can take a look at our list of Good First bugs, where someone who knows the code can help you get started:

Also, this Issue has been added to

Bugzilla is not hooked into our module owner or code check-in system. It optimistically assumes any reviewer is an appropriate reviewer and sends that mail. I guess it figures why would anyone bother asking for a review from someone who wouldn't "count". In this case it looks like you reviewed your own patch and that definitely won't work. Code-review in bugzilla is actually deprecated and will be removed sometime in the near future, and the system we are using now (Phabricator) is slightly smarter (but only slightly).

You need to get review/approval from one of the Module owners or peers:

Thanks for the report. Marking as invalid for two reasons: JSEcoin's opt-in has a number of flaws (detailed below), and we do not maintain Disconnect's list. If you'd like to request a reclassification of a domain you can do so on Disconnect's upstream repository:

In my opinion, JSECoin's opt-in does not come close to constituting meaningful consent. For context, I've attached a screenshot of the opt-in prompt. Here are a few issues:

  1. The opt-in is cross-site. Meaning if a user clicks "Continue" on a single site they are automatically opted in to mining on all future sites. This is particularly concerning given that sites may coerce users to opt-in, such as the example in my second screenshot. The dialog box gives no indication that the user's decision is global.
  2. The notice is vague (i.e., "By continuing you agree to donate surplus resources."). Without knowledge of cryptocurrency mining, what does "surplus resources" mean? Do we expect the average site visitor to understand this dialog?
  3. Opting out is distinctly harder than opting in. By design a user can "Continue" with or without opting in, so why does the "Continue" button default to yes? To deny future prompts a user needs to click "Privacy & Opt-out" and then click "You can opt-out of JSE crypto-mining across the whole network by clicking here". These types of dark patterns are concerning given that the "Continue" button is a global opt-in.
  4. The opt-in can be trivially bypassed by any site that embeds the mining script. As an example, see my test page: (live version here: This allows mining to start on my page, but doesn't globally opt-in -- it does appear they attempt to prevent automated interaction with the "Continue" button, e.g., randomized element IDs. But a more sophisticated approach could be successful.
Flags: needinfo?(senglehardt)
Flags: needinfo?(arthur)
Closed: 2 months ago
Resolution: --- → INVALID

Comment 8

2 months ago

O.K. Thanks Steven - I've got the message and will forward it to JSECOIN Management and Developers.

Best Regards!

That's helpful. Thank you for the report!

Comment 10

Last month

Hi Steven, I'm one of the developers on the JSE project.

I'll respond to each point separately and then look at what we can do to get removed from the list.

  1. The opt-in is cross site, this is intended as if someone opts-in to the JSE mining project we believe they should not have to re-opt-in every time they visit a website in the network. We have some publishers that use multiple sub-domains or tld's as well. We could potentially put content in the notification to state the opt-in is global but space is of a premium, especially on mobile devices where we don't have much room in the notification bar. See below.

  2. I think "surplus resources" is non-technical enough that most users would understand. We could be more detailed and less vague and explain that the mining uses less CPU, RAM and data usage than an average video advertisement but I think this may make it harder to understand for the majority of users. The more information we put in the notification the smaller font size we have to use which I think is important as well. We want to inform users as best as possible but also not put a lot of text in the notification that they wont actually read.

  3. We can make the opt-out link work directly as a single step/click.

  4. The client-side code can and always will be able to be bypassed. As you've seen we've gone to quite a bit of effort to make it as difficult as possible. When we were working on this we decided to focus on server-side code to prevent misuse as these can't be manipulated by malicious web masters. Server side checks are in place to prevent publishers from profiting from bad practices. We use tensorflow to do fraud analysis on the traffic patterns and any kind of automatic opt-in would be detected and a suspension put in place before the 7 day pending period for payouts was reached.

Obviously we want to work with you to ensure our project meets your requirements to prevent blacklisting.

So potential compliance changes:

  • Opt-out link > direct (one click), no explanation page.
  • Text change from
    "By continuing you agree to donate surplus resources"
    "By continuing you agree to donate surplus computational resources across all JSE publisher websites"
    ^ I'm open to suggestions on this.

Can you confirm that these steps will meet with your requirements for whitelisting?

Thanks for reaching out! I've flagged Disconnect on your questions. They can loop us in if it's necessary. They can be reached directly at:

You need to log in before you can comment on or make changes to this bug.