Superset pages flagged as malicious and dangerous

[Mycobee]

Bug description

Accessing Superset pages has been detected by Chrome and Firefox as Dangerous (or Phishing sites)

This is causing browsers to break, and no changes have happened on my end. I highly suspect this has to do with scarf.sh, which is running scripts that the browsers are flagging as problematic...specifically from this URL

https://apachesuperset.gateway.scarf.sh/pixel/

I have a cluster deployed with helm, and using a valid and up-to-date tls certificate from letsencrypt. Unfortunately, my clients are no longer able to access the cluster without overriding browser security recommendations.

I tried a variety of mechanism to disable scarf in my values.yaml including

manually setting:

image:
  repository: apache/superset

configOverrides:
  superset_config.py: |
    SCARF_ANALYTICS = False

    FEATURE_FLAGS = {
      "ENABLE_TELEMERTY": False
    }

Screenshots/recordings

Superset version

master / latest-dev

Python version

3.9

Node version

dunno...not sure how to figure this out easily from inside the container

Browser

Brave/Firefox

Additional context

Others are having this problem on different platforms:
#31856 (comment)

As an aside, it feels unethical to distribute free software with tracking enabled, especially given no meaningful or straightforward way to ensure consent before enabling/disabling it.

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

@Mycobee Hello there! I'm here to assist you with any bugs, questions, or contributions. Let's dive into this issue and get it resolved!

To address the issue of Superset pages being flagged as malicious due to scripts from scarf.sh, you can manually disable Scarf telemetry requests by modifying the source code. Here are the steps you need to follow:

1. Delete the file: superset-frontend/src/components/TelemetryPixel/TelemetryPixel.test.tsx
2. Delete the file: superset-frontend/src/components/TelemetryPixel/index.tsx
3. Modify superset-frontend/src/features/home/RightMenu.tsx by removing the TelemetryPixel component section:

<TelemetryPixel
  version={navbarRight.version_string}
  sha={navbarRight.version_sha}
  build={navbarRight.build_number}
/>

These changes should stop the telemetry requests that might be causing the pages to be flagged ^[1].

To continue talking to Dosu, mention @dosu.

---

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

[Mycobee]

@dosu this is not helpful because my js is already compiled...

I am currently working on a fix to block scarf on the k8s network level

[dosubot]

@Mycobee Oh, I see you're diving deep into the network level! I'm a bot designed to help with bugs, technical questions, and engineering knowledge, but it sounds like you're venturing into territory I can't assist with. If you think I should have more tricks up my sleeve, feel free to reach out to the Dosu Team. They'll be happy to hear your thoughts!

To continue talking to Dosu, mention @dosu.

---

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

[Mycobee]

@dosu i see now the requests are all happening from the frontend, so that was a waste of time. How can I disable scarf easily with my helm chart?

[dosubot]

To disable Scarf using your Helm chart, you can opt-out of the data collection by editing the repository: line in your helm/superset/values.yaml file. Replace apachesuperset.docker.scarf.sh/apache/superset with apache/superset to pull the image directly from Docker Hub. This change will prevent Scarf from collecting telemetry data ^[1][2].

To continue talking to Dosu, mention @dosu.

---

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

[Mycobee]

@dosu that doesnt work. Please provide another option

[dosubot]

To completely disable Scarf telemetry in Apache Superset, you can set the SCARF_ANALYTICS environment variable to false. This method is effective if modifying the Helm chart does not work. Set this environment variable in your deployment configuration to ensure it is applied where your Superset instance is running, such as in your Docker container or Kubernetes deployment:

export SCARF_ANALYTICS=false

If you are using Docker Compose, you can also edit the docker/.env file to include this environment variable, ensuring it is consistently applied across your deployment ^[1].

To continue talking to Dosu, mention @dosu.

---

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

[Mycobee]

I am done talking to the robot, but I am all ears if anyone has any ideas how to dynamically set this in the official registry containers with a precompiled frontend

[rusackas]

It's correct, you can simply disable the Scarf gateway with the SCARF_ANALYTICS env var. You'll want to either disable it or allow your networking config to load the (anonymous) tracking pixel and send its telemetry ping when doing npm install. If you search for Scarf in the docs it provides a bit more info about this.

As for why it's being flagged as malicious in the first place, I'm not sure... @arjundevarajan might be interested or have more insights here.

[Rupantar-Borphukan]

Can I try to solve the issue ?

[Mycobee]

It's correct, you can simply disable the Scarf gateway with the SCARF_ANALYTICS env var

I don't mean to split hairs @rusackas, but I think this is incorrect currently for a Kubernetes deployment with the superset Helm chart.

$ grep -i -e env -e scarf superset/values.yaml 
extraEnv:
  SCARF_ANALYTICS: "false"

$ kubectl exec -it -n superset superset-7764c554cf-zz52f -- bash

root@superset-7764c554cf-zz52f:/app# echo $SCARF_ANALYTICS
false

Browsers are still making calls to scarf analytics with these config options

With a docker-compose environment, there is a superset-frontend directory, in a separate container. That container runs the webpack server. But in the production kubernetes container, the assets are precompiled.

Scarf Analytics are disabled by process.env
source 1
source 2

JavaScript is not my expertise, but I believe this has something to do with build time, not at run time (at least for source 2). That might explain the precompilation specific problem ??

But in the official helm deployment, we do have access to a webpack process as everything is bundled in to 1 container.

Did you read the thread of the similar issue? I linked it in my bug report:
#31856 (comment)

This user had to manually delete files to fix their problem, and it seems they are running docker. So IMO there is enough evidence to look further in to this. Unfortunately, I cannot manually delete files like that user could, since my assets are all precompiled in one big file.

[Mycobee]

@Rupantar-Borphukan , I am not a core contributor to this project. But I do think this issue needs further investigation. There are two publicly reported instances of the bug. And both instances report challenges disabling scarf analytics using the blessed environment variable.

[TristisOris]

We got same issue at some of chrome users. *upd. after few page visits, all browsers show warning now.

SCARF_ANALYTICS=false is not working.
removal TelemetryPixel code also don't work.
docker installation.

[TristisOris]

../superset/docker/pythonpath_dev/superset_config_docker.py something begins work after add SCARF_ANALYTICS=false to this file. But not everywhere.

[rajuw892]

I'm using import { embedDashboard } from '@superset-ui/embedded-sdk this sdk in frontend react code , i'm also getting dangerous site in chrome browser, can someone help me , how to fix this.

[aviaviavi]

@rusackas a few potential things we can do to fix this:

We now support custom variables on our native Scarf pixels which don't use a redirect. This may help appease Brave and other browsers without a loss of functionality.

If it doesn't, we also now support pixels on custom domains, so we could avoid needing to use a scarf.sh URL. I know that can be more challenging from an ASF perspective but just another option.

Happy to help here in any case!

The Scarf team is also reaching out to Brave and others to have us removed from these lists. While we are helping with privacy-conscious observability, there is absolutely no phishing or other malware associated with these URLs.