Add configure option to disable Content Analysis SDK

see

• 1871166 [meta] Integrate Content Analysis SDK for data loss prevention
  • https://github.com/chromium/content_analysis_sdk
• FF121+ 1811076 prefs .. false for now

I don't understand where/how it gets used or what it's purpose is (disclosure: i am not a browser engineer) but "enables 3rd party data-loss prevention software to serve as a gate-keeper" doesn't sound like something we want

cc @pierov @richard

added FF128-esr label

changed the description

https://github.com/chromium/content_analysis_sdk

DLP agents are background processes on managed computers that allow enterprises to monitor locally running applications for data exfiltration events. They can allow/block these activities based on customer defined DLP policies.

Burn it with .

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

Being an SDK, I think the optimal solution would be to completely disable it at build time if possible.

Agreed, in the short-term would you object to locking the pref that enables this?

I looked into this a bit and there's not a minimal/clean way to not include this at compile time unfortunately. A patch could be developed with a bit of effort but more than I'm willing to expend at the moment.

marked this issue as related to #42356 (closed)

well this is awful

added Roadmap::Future label

added All Platforms label

added Task label

added 14.0 stable label

changed title from Content Analysis SDK for DLP to Disable Content Analysis SDK for DLP

marked this issue as related to #42751 (closed)

mentioned in issue #42751 (closed)

removed Roadmap::Future label

added Next label

assigned to @morgan

Ok for now this is disabled by pref and it is opt-in via cmd-line to even enable the system. Long-term, we should add a configure option to completely opt-out of including this thing, and attempt to uplift it.

changed title from Disable Content Analysis SDK for DLP to Add configure option to disable Content Analysis SDK

unassigned @morgan

removed 14.0 stable label

added 14.5 stable Uplift labels

removed esr-128 label

mentioned in issue #42356 (closed)

Commits: 5fdb72e1 (vendors third_party/content_analysis_sdk), 1d69a1ae (this add the a flag stored in gAllowContentAnalysis to enable content analysis), 4e86cf34, d4900df4, 14de6888, 81781dff (adds also prompts!), ebf37de3, 412f4cd8, 19759c69, d5af5480.

About the flag: I think the code has been updated later, as the variable is called gAllowContentAnalysis in our source tree. Also, the flag is necessary, in addition to the preference, unless the preference itself was set via enterprise policies (which we disable).

As far as I can tell from a first analysis, the main directories we'd have to nuke are third_party/content_analysis_sdk and toolkit/components/contentanalysis. And if I'm not wrong, files of the former are built from the moz.build in the latter.

So, we could simply remove contentanalysis from toolkit/components/moz.build. There are also other references, such as in toolkit/components/protobuf/regenerate_cpp_files.sh, but this one simply generates some Protobuf files, so it shouldn't be a big deal.

We could try to run a build and see if there's breakage at compile time. I don't know for runtime.

Also, I don't know if upstream would take such a simple patch, but we can try.

I tried this way and it didn't work.

There are several other occurrences of contentanalysis in the codebase, including clipboard, file dialog, printing, and IPC files.

They aren't a lot in each file, but, after excluding third_party/content_an*, toolkit/components/contentan*, I still get 358 result in 40 files.

Some are CSS, some are JS (hopefully lazy loading and gated on the pref), and some are localization files, but there are also some C++ files, which means we'd have to use some #ifdefs, or provide a stubbed API.

I don't think it's worth to do that many changes, as the pref will keep this feature off, and we disabled enterprise policies, which would have priority over the preference.

At most, we could change ContentAnalysis::GetIsActive to always return false, but the pref should be enough already (and if you are whistleblowing against your enterprise you should use Tails anyway and exfiltrate files in another way ).

Also, I guess somebody having a setup with the required agent would have something to block Tor Browser as well .

I originally tried prototyping conditionally including the ContentAnalsys code with a build-flag, and mocking out the content analysis WebIDL implementation with no-op stubs. Unfortunately, there are a number of non-trivial native functions which hang off these implementations as well which would need to be either mocked, or whose callers would need to be ifdef'd out. So the first half was relatively easy, but the second half was more effort than I was willing to expend at the time.

I think longer-term it would be nice for these various systems to be opt-in at compile time, rather than opt-out at runtime and uplift to Mozilla (and some things are which is great e.g. WebRTC, parental controls, etc). Especially given the ever looming threat of APK size restrictions on Android.

removed the relation with #42751 (closed)

removed Next label

added Roadmap::Future label

added Apps::Priority::High label

removed Uplift label

removed Apps::Priority::High label

added Apps::Type::Enhancement label

added Apps::Priority::Low label

added Apps::Impact::Minimal label

added 15.0 stable label and removed 14.5 stable label