Safari 17 block 3rd party JavaScript SDK in Private Browsing Mode

• Component: Page Loading
• Status: NEW ---

Safari 17 blocking my JavaScript SDK completely in Private Browsing Mode

Hi WebKit team,

I am a product manager working for a large content recommendation company. Our JavaScript SDK is running on more than 9000 leading publishers worldwide and has been certified to be aligned with global legal and privacy regulations and guidelines.

We have the following problem:

-Since the launch of Safari 17 (in iOS, iPadOS, and MacOS) - we can see our JavaScript SDK blocked when the user uses the private browsing mode
- Safari 17 identifies our loading and rendering JavaScript files to be a tracking activity (we see the JavaScript files in the taboola dot com domain console tagged with “Blocked connection to known tracker” log)
- In previous Safari versions, we only got the tracking functionality blocked, allowing JavaScript files that are blocked in Safari 17 to execute

We have the following questions:

- Was there something specific in Safari 17 “Tracking Protection” functionality that now blocks content rendering on the page in addition to tracking activity?
- Can JavaScript running in Safari detect the user has the privacy mode turned on?
- Are there any deterministic rules that cause the blocking? or is this something that done heuristically by reaching certain level of network calls or API requests (for example, calling the storage APIs...) 

Context:

- We can run our JavaScript without performing any form of tracking, either directly by my domain or any other 3rd party vendor we are working with.
We will render our content without performing any form of tracking or fingerprinting
- Besides sponsored content, our JavaScript SDK also powers organic recommendations for our clients. With Safari 17 blocking anything in private browsing mode, we see unfair interference with organic engagement.
- We can also work with you to find the right way to allow or rendering parts, while continuing blocking the tracking ones when it comes to the user using the private browsing mode. 

Please let us know if you provide guidance to allow our JavaScript SDK to render content when the user uses the private browsing mode, adhering to the privacy requirements.

Thank you for helping!

[Radar WebKit Bug Importer]

<rdar://problem/119763610>

[John Wilander]

Thanks for filing!

Private Browsing Mode is an opt-in mode where the user wants additional privacy protections. Starting in Safari 17, we block network loads from known trackers (as you noted that the console log says). We use DuckDuckGo's open source block list to inform ourselves of known trackers.

Opting into more strict privacy protections can be done in other ways too. For instance by installing a content blocker focused on tracker blocking.

We do not offer a way to detect Private Browsing Mode. It should be up to the user to choose which mode they want to use.

We intend to resolve this bug as Behaves Correctly but I'll keep it open for the time being in case you had further questions.

Thank you for providing this information. We understand and respect the user choice. We only want to make sure that we can run non-tracking activities accordingly. 

Regarding the usage of DuckDuckGo lists - I will reach out to them as their current configuration breaks the website layout and interfere with non tracking functionality. 

Do you use their lists dynamically? meaning if they to accept our request, will it reflect immediately or in the next 17.x Safari version? 

I appreciate the help.

(In reply to John Wilander from comment #3)
> Thanks for filing!
> 
> Private Browsing Mode is an opt-in mode where the user wants additional
> privacy protections. Starting in Safari 17, we block network loads from
> known trackers (as you noted that the console log says). We use DuckDuckGo's
> open source block list to inform ourselves of known trackers.
> 
> Opting into more strict privacy protections can be done in other ways too.
> For instance by installing a content blocker focused on tracker blocking.
> 
> We do not offer a way to detect Private Browsing Mode. It should be up to
> the user to choose which mode they want to use.
> 
> We intend to resolve this bug as Behaves Correctly but I'll keep it open for
> the time being in case you had further questions.

Happy holidays and Happy New Year.
We found a way via DuckDuckGo's repos to clear our rendering functionality while preserving the user's privacy - https://github.com/duckduckgo/tracker-surrogates/tree/main/surrogates 

Can you please confirm that Safari is using their lists dynamically, or will we need to wait for the next Safari 17.x version?

[John Wilander]

If surrogates are some kind of stubbed or mocked JavaScript, we don’t use or support them. Please file a feature request if you’d want us to consider such support. Thanks!

(In reply to John Wilander from comment #6)
> If surrogates are some kind of stubbed or mocked JavaScript, we don’t use or
> support them. Please file a feature request if you’d want us to consider
> such support. Thanks!

Surrogates (https://github.com/duckduckgo/tracker-surrogates) are DuckDuckGo formal way to restore broken functionality during tracking protection. Per your previous comment, we assumed that you support this as part of your overall usage in tracking prevention. 

If Safari does not support it - how can you offer a way for 3rd party JS SDKs like us to restore broken functionality during the tracking blocking activity?

Hi - following up on this - what are the options for a publisher/3rd party when functionality breaks due to the tracking prevention?

[John Wilander]

I think you have three options:

1. Make sure websites don't have breaking dependencies on content that may be blocked in this fashion. This goes for all the cases that can cause content blocking, including content blocker extensions.

2. Get off the block list (by not being categorized as needing to be on it). I know you've already looked into this so just restating the option.

1. File a feature request for us to support stubs/mocks/surrogates. Note that new features take time to implement and ship even if we were to decide we want to support it. So it's not an option for the near-term.

[Maciej Stachowiak]

I do not think stubs will resolve this problem. They are minimal functions that prevent unrelated parts of a website from breaking when a tracking script it includes is blocked. They are not meant to replicate any functionality that may be included in the tracking script, which is still blocked even when a surrogate is in place.

Ultimately, this blocking is tracking prevention working as intended.

(In reply to John Wilander from comment #9)
> I think you have three options:
> 
> 1. Make sure websites don't have breaking dependencies on content that may
> be blocked in this fashion. This goes for all the cases that can cause
> content blocking, including content blocker extensions.

it's our JS library is blocked all together. Our clients rely on it to render. Having Safari wrongfully block rendering does not mean that these clients needs to change anything.
 
> 2. Get off the block list (by not being categorized as needing to be on it).
> I know you've already looked into this so just restating the option.

Can you send us a contact in DuckDuckGo that we can work together on this?

> 
> 1. File a feature request for us to support stubs/mocks/surrogates. Note
> that new features take time to implement and ship even if we were to decide
> we want to support it. So it's not an option for the near-term.

Will do

(In reply to Maciej Stachowiak from comment #10)
> I do not think stubs will resolve this problem. They are minimal functions
> that prevent unrelated parts of a website from breaking when a tracking
> script it includes is blocked. They are not meant to replicate any
> functionality that may be included in the tracking script, which is still
> blocked even when a surrogate is in place.
> 
> Ultimately, this blocking is tracking prevention working as intended.

Maciej, thank you for replying. We don't want to replicate or restore any tracking activity, as our JS file that is blocked does not track... we want to ensure that we can render as we did before. Currently DuckDuckGo marks our JS file as tracker and we're looking for ways to restore functionality. using surrogates can nullify the browser native apis usage we're doing (which is not for tracking) - and ensure rendering.