PR#1176 "feat: Refactor GDPR stuff into a more readable consent class" accidentally broke my GDPR compliance

[grahamc]

In #1176, has_opted_out_capturing and has_opted_in_capturing changed behavior significantly.

Before that PR, those functions called hasOptedIn and hasOptedOut, which were defined as:

export function hasOptedIn(token: string, options: GDPROptions): boolean {
    return _getStorageValue(token, options) === '1'
}

and:

export function hasOptedOut(token: string, options: Partial<GDPROptions>): boolean {
    if (_hasDoNotTrackFlagOn(options)) {
        return true
    }
    return _getStorageValue(token, options) === '0'
}

but after that PR, those functions were redefined:

    public isOptedOut() {
        return (
            this.consent === ConsentStatus.DENIED ||
            (this.consent === ConsentStatus.PENDING && this.config.opt_out_capturing_by_default)
        )
    }

    public isOptedIn() {
        return !this.isOptedOut()
    }

The difference is subtle, but getStorageValue would return null or undefined if the value wasn't set. That means hasOptedIn and hasOptedOut could both return false. But now, isOptedIn is explicitly the opposite of isOptedOut. If there is no preference, isOptedOut will return false, and isOptedIn will return true. This is not correct, and breaks the behavior of has_opted_in_capturing().

Until earlier this year, the recommended way to implement a cookie banner was by checking !(posthog.has_opted_out_capturing() || posthog.has_opted_in_capturing()). Now, any site that has implemented this mechanism is accidentally violating the GDPR by not displaying the cookie banner, even when the user has not consented.

Further, has_opted_in_capturing() has undoubtedly been used in many places to explicitly turn on additional features and behavior that is predicated on the user having opted in.

My hope is that has_opted_in_capturing() will be corrected to represent the user's actual consent.