🐛 Browser Logs SDK is constantly writing to _dd_s cookie

[danielcompton]

Describe the bug

We added cookie watching using the new Cookie Store API for an unrelated feature and I was surprised to see the __dd_s cookie being written every ~1-2 seconds. As far as I can tell, no attributes are being changed, but the write is causing the CookieChangeEvent to fire.

Writing to the cookie store with document.cookie blocks the main thread, so this is not ideal.

I verified this still occurs with the current version of 5.23.3.

To Reproduce
Steps to reproduce the behavior:

1. Open https://app.datadoghq.com/ and log in in Chrome (this has the logging SDK installed)
2. Enter this in the browser console:

   const handleChange = (event) => {console.log("EV", event);}
   window.cookieStore.addEventListener("change", handleChange)

3. See 4 logs get written every 1-2 seconds.

Expected behavior

The __dd_s cookie gets written to very occasionally, as needed.

[BenoitZugmeyer]

Hey @danielcompton, thank you for your feedback! This is a known issue and something we want to improve midterm. We are also exploring using the Cookie Store API. Although this part of our codebase is quite complex so it might take some time.

[udbmnm]

I also encountered this issue, it's not just a matter of changing the cookie every one or two seconds, but rather a loop that keeps modifying the cookie endlessly.

[paul-cla]

Hi DataDog team, this might be one you need to review as a priority - as it is violating cookie policies.

On our website - www.thinkmoney.co.uk - we use OneTrust to setup Cookie blocking with an "accept/reject" banner. The _dd_s cookie is appearing on clean launch of the website, even though it is configured correctly by OneTrust and should be being blocked until accepted.

You can reproduce this by loading thinkmoney.co.uk in a clean browser/incognito etc and viewing loaded cookies. _dd_s is appearing before any interaction on the cookie banner.

[BenoitZugmeyer]

@udbmnm If you can share a way to reproduce the issue you are facing, we could have a look. Contact support@datadoghq.com if there is anything you don't want to share on github.

@paul-cla the RUM Browser SDK defines a cookie when .init() is invoked. To work around this, you have two solutions:

• don't call .init() before the user accpts cookies via OneTrust
• use the user tracking consent API provided by the SDK (see doc)

[DaveM80]

Following the docs

Datadog documentation - Advanced Configuration

OneTrust Documentation - OneTrust Community

This is how we solved it:

const updateConsent = (event) => {
        const categories = event?.detail && window.OnetrustActiveGroups;

        const arePerformanceCookiesAllowed = categories.includes(
            cookieCategories.performance
        );

        if (arePerformanceCookiesAllowed) {
            datadogRum.setTrackingConsent('granted');
        } else {
            datadogRum.setTrackingConsent('not-granted');
        }`
        
                datadogRum.init({
            // ...rest of the config
            trackingConsent: 'not-granted'
        });
        
      useEffect(() => {

        datadogRum.init({
            // ...rest of the config
            trackingConsent: 'not-granted'
        });

        updateConsent();

        window.addEventListener('OneTrustGroupsUpdated', updateConsent);
       
    }, []);

[amortemousque]

Hello @danielcompton,
As there hasn’t been any feedback for the past months, we are assuming this issue is resolved and closing it.
If you’re still experiencing this problem, please feel free to reopen the issue or create a new one.

[danielcompton]

@amortemousque I think there are two problems that have been combined here:

• My issue which is that the _dd_s cookie is being constantly updated when using the browser logs SDK
• A separate issue about manging tracking consent when using RUM

AFAICT these aren't the same problem, and this issue should be reopened? (I don't have permissions to do that).