Apache Superset pages have been flagged as Dangerous or Phishing Site by Chrome and Firefox

[mecan-soonee]

I have been using Apache Superset (v4.0.0) for more than 6 months and it worked fine until the past 2 weeks where, accessing the Superset pages have been detected by Chrome and Firefox as Dangerous (or Phishing sites). The Apache Superset was hosted on Debian OS, EC2 instance with MySQL.

At first I thought the sites have been security compromised (being hacked or so). Then I tried brought up another new instance with totally new set up on different EC2 instance (on Amazon Linux 2023, new MySQL DB, with a new subdomain name). The new Apache Superset still being flagged as Dangerous (by Google Safe Browsing). When performing the checks from https://transparencyreport.google.com/safe-browsing/search?url=https:%2F%2Fsuperset.abc.com%2Flogin%2F&hl=en, the results intermittently returned as followings:

Current status
warning
This site is unsafe
The site https://superset.abc.com/login/ contains harmful content, including pages that:
Try to trick visitors into sharing personal info or downloading software

OR

Current status
check_circle
No unsafe content found

The red flags basically affected all Apache Superset pages.

I deep dived further with different type of installations (by PyPI or Docker Compose) on different instances but to no avail.

The only thing found suspicious to me now is the Scarf Gateway. Do you think this could be the root cause of it being marked as Dangerous or phishing site? Accessing to all Superset pages will trigger the following two requests:

1. https://apachesuperset.gateway.scarf.sh/pixel/0d3461e1-abb1-4691-a0aa-5ed50de66af0/4.1.1//null
2. https://static.scarf.sh/a.png?x-pxid=0d3461e1-abb1-4691-a0aa-5ed50de66af0&version=4.1.1&sha=&build=null

I tried to disable it as suggested in the installation guides below, but the request is still persist on every Superset page load:

1. Setting SCARF_ANALYTICS=False in .env or superset_config.py (from official guide)
2. Setting ENABLE_REACT_CRASH_LOG=False (from Google)
3. ENABLE_FLASK_REACT_CRASH=False (from Google)
4. To opt-out of this data collection for packages downloaded through the Scarf Gateway by your docker compose based installation, edit the x-superset-image: line in your docker-compose.yml and docker-compose-non-dev.yml files, replacing apachesuperset.docker.scarf.sh/apache/superset with apache/superset to pull the image directly from Docker Hub.

**For Superset version 4.1.1 (Github repo), the point 4 above is not valid as the existing docker-compose.yml and docker-compose-non-dev.yml does not contain x-superset-image setting to apachesuperset.docker.scarf.sh/apache/superset

Can anyone please advise how can I disable the SCARF telemetry request? As I need to confirm if this is the culprit of my Superset pages being incorrectly flagged red (dangerous).

Or does anyone encounter the similar case where Apache Superset is detected as Dangerous or unsafe site?

**my other websites with the same domain name have no issue. Only the hosted Apache Superset sites are affected. SSL Certificate is valid.

Thanks in advance.

[dosubot[bot]]

Hey there, @mecan-soonee! I'm here to help you with any bugs, questions, or contribution inquiries you might have. Let's tackle this issue together!

To disable the SCARF telemetry requests in Apache Superset, you should set the SCARF_ANALYTICS environment variable to False. This should prevent the telemetry pixel component from being rendered, thus stopping the telemetry requests ^[1].

If you are using Docker Compose, ensure that the SCARF_ANALYTICS environment variable is set to False in your docker/.env file to apply it consistently across your deployment ^[2].

Additionally, for Docker Compose installations, you can opt-out of telemetry data collection by editing the x-superset-image: line in your docker-compose.yml and docker-compose-non-dev.yml files. Replace apachesuperset.docker.scarf.sh/apache/superset with apache/superset to pull the image directly from Docker Hub. However, if your version does not contain this setting, this step may not be applicable ^[2].

If these steps do not resolve the issue, it might be worth checking if there are any other configurations or customizations in your setup that could be affecting the telemetry settings.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[mecan-soonee]

@dosu Thanks for your prompt response to my questions. Like I mentioned, setting SCARF_ANALYTICS = False in docker/.env still did not stop the scarf telemetry requests from being sent out.

[dosubot[bot]]

To completely disable the SCARF telemetry requests, you should ensure that the SCARF_ANALYTICS environment variable is set to False in your terminal and/or in your docker/.env file. If this alone does not stop the telemetry requests, you may need to modify your Docker setup.

Since your version does not have the x-superset-image setting in the docker-compose.yml and docker-compose-non-dev.yml files, you might need to manually ensure that the Docker image you are using is directly from Docker Hub (apache/superset) and not through the Scarf Gateway. This might involve checking your Docker image source and ensuring it is not inadvertently pulling from a Scarf-related source.

Additionally, you can opt out of the telemetry pixel by adding a setting in superset-frontend/package.json:

{
  "scarfSettings": {
    "enabled": false
  }
}

This should help in disabling the telemetry requests. If the issue persists, it might be worth reviewing any other custom configurations or scripts that could be affecting the telemetry settings.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[mecan-soonee]

@dosu I added scarfSettings's enabled = false to superset-frontend/package.json but the scarf requests still being sent out.

Finally I managed to entirely disable the scarf telemetry requests by manually checking out the latest superset 4.1.1 source codes from github, and manually deleted the following TelemetryPixel related files and lines:

    1. deleted file: superset-frontend/src/components/TelemetryPixel/TelemetryPixel.test.tsx
    2. deleted file : superset-frontend/src/components/TelemetryPixel/index.tsx
    3. modified: superset-frontend/src/features/home/RightMenu.tsx by deleting the following section:
        `-      <TelemetryPixel
        -        version={navbarRight.version_string}
        -        sha={navbarRight.version_sha}
        -        build={navbarRight.build_number}
        -      />
        `

Now when accessing to Apache Superset pages, telemetry requests no longer there.

After the fixes above, I submitted a request for a review to Google (as suggested in this link https://web.dev/articles/request-a-review) and the review has been approved (no links to harmful sites and downloads found).

Here is how A Successful Google Review looks like:

Perhaps, I do hope that Apache Superset team could help provide a better options or solution to disable or opt out the Scarf Telemetry requests in Apache Superset, as all the above mentioned configurations did not disable it as it supposes to.

Thank you :-)

[dosubot[bot]]

Hey @mecan-soonee! I'm glad to hear you managed to resolve the issue with the telemetry requests. As a bot, I'm here to help with technical questions, bugs, and engineering knowledge, but I can't directly influence the Apache Superset team's decisions or features. If you think I should have more information or capabilities to help with this kind of request, feel free to reach out to the Dosu Team. They'll be happy to hear your feedback! 😊

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[Mycobee]

This is a big problem. Firstly, it feels unethical to distribute free software with tracking enabled, especially given no meaningful or straightforward way to ensure consent before enabling/disabling it. I too am experiencing this issue on a production site deployed with helm.

I have yet to figure out how to remove this functionality using my values.yaml file, but I will report back when I find out