Closed Bug 1909492 Opened 7 months ago Closed 7 days ago

Firefox in private mode blocks scripts from *.ondemand.com (ETP)

Categories

(Web Compatibility :: Privacy: Site Reports, defect, P3)

Firefox 130

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: viktor.folmer, Unassigned)

References

(Blocks 1 open bug)

Details

Steps to reproduce:

SAP's domain ondemand.com is currently on the tracking list of disconnectme in category "Email", as some (but not all) subdomains are actually implement tracking mechanisms.
see e.g., https://github.com/disconnectme/disconnect-tracking-protection/issues/355

The domain ondemand.com is hosting SAP and non-SAP content making it impossible for SAP to declare the entire second level domain to be tracking free. However blocking everything from ondemand.com is breaking the checkout in web shops, which are using SAP's payment solution.
The payment solution itself does not use any trackers, but disconnectme is not able to allow-list specific subdomains. They are providing a block list only, which is far too broad.

The web shops on the other side are not willing to tell their customers to switch off tracking protection as they have the right to not being tracked while shopping. Instead they tend to recommend other browsers.

Actual results:

All ressources from *.ondemand.com are blocked by ETP in private mode.

Example:
content from https://digitalpayments-core.cfapps.eu10.hana.ondemand.com is blocked by ETP in private mode making it impossible to pay in a webshop which embeds SAP's payment solution.

Expected results:

Blocking is performed for subdomains which are actually tracking.

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core

Hi Viktor! The Disconnect list does support only blocking certain subdomains. Looking at https://github.com/disconnectme/disconnect-tracking-protection/blob/master/services.json there are lots of subdomain-specific entries.
Perhaps you could clarify with them which domains are not used for tracking. We can't make changes to the list so the appeal process would have to go through Disconnect.

Hi,

Disconnect explained they could only remove the second level domain from the blocklist if:

a) ALL subdomains which are actually tracking are disclosed
b) SAP (as second level domain owner) could give a legal binding statement that ALL remaining (not explicitly mentioned) subdomains do not track

This approach does not work for a hosting service such as ondemand.com.

SAP is providing a SaaS Platform for cloud-based business application and services (similar to AWS hosting offerings). SAP and SAP’s customers are running their cloud services on different subdomains ending with ondemand.com. SAP does not have control over customer’s content and does not forbid their customers to build trackers.

If Firefox is using the blocklist from disconnect as-is and one one bad apple is spoiling the entire second level domain (as disconnect claims), what happens if github.com or amazonaws.com would appear on their list? How can anyone tell that there are no trackers on any subdomain of the hosting services?

For some additional context because I don't think it was fully mentioned on this bug yet:
Firefox blocks ondemand.com in ETP "strict" and in private browsing since it's on the email tracker list.
That's configured here: https://searchfox.org/mozilla-central/rev/a9d6fb8ae147ebd1ff0d7886fd55c812d9b57378/browser/app/profile/firefox.js#2221

(In reply to Viktor Folmer from comment #3)

Hi,

Disconnect explained they could only remove the second level domain from the blocklist if:

a) ALL subdomains which are actually tracking are disclosed
b) SAP (as second level domain owner) could give a legal binding statement that ALL remaining (not explicitly mentioned) subdomains do not track

This approach does not work for a hosting service such as ondemand.com.

SAP is providing a SaaS Platform for cloud-based business application and services (similar to AWS hosting offerings). SAP and SAP’s customers are running their cloud services on different subdomains ending with ondemand.com. SAP does not have control over customer’s content and does not forbid their customers to build trackers.

If Firefox is using the blocklist from disconnect as-is and one one bad apple is spoiling the entire second level domain (as disconnect claims), what happens if github.com or amazonaws.com would appear on their list? How can anyone tell that there are no trackers on any subdomain of the hosting services?

I don't think github.com is a good example. It doesn't get embedded by websites in a 3rd party context. They support serving files e.g. via their "Pages" feature, which uses the domain github.io. This domain is shared between their customers which get assigned subdomains based on the GitHub username. github.io is on the public suffix list which means cookies are not shared between two different subdomains (e.g. foo.github.io and bar.github.io).
This use-case sounds a bit like the use case you're describing with ondemand.com. Have you considered adding ondemand.com as a public suffix? This may make it easier to argue that not the entire suffix should be listed on Disconnect's list as the domain is shared between multiple customers of yours and you said you're not controlling whether these customers serve tracking content or not.

Flags: needinfo?(viktor.folmer)
Blocks: tp-breakage
Severity: -- → S3
Priority: -- → P3
Component: Privacy: Anti-Tracking → Privacy: Site Reports
Product: Core → Web Compatibility

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED, closing the bug as incomplete.

For more information, please visit BugBot documentation.

Status: UNCONFIRMED → RESOLVED
Closed: 7 days ago
Flags: needinfo?(viktor.folmer)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.