prebid / go-gdpr Goto Github PK

If I try to build first example code:

$ go build main.go 
# command-line-arguments
./main.go:6:3: "github.com/prebid/go-gdpr/consentconstants" imported and not used
./main.go:12:13: undefined: base64

Source code for first example should be:

package main

import (
	"encoding/base64"
	"log"

	"github.com/prebid/go-gdpr/vendorconsent"
)

func DemoConsentStringParsing() {
	encodedString := "BONciguONcjGKADACHENAOLS1rAHDAFAAEAASABQAMwAeACEAFw"
	data, _ := base64.RawURLEncoding.DecodeString(encodedString)

	consent, err := vendorconsent.Parse(data)
	if err != nil {
		log.Printf("Data was not a valid consent string: %v", err)
		return
	}

	log.Printf("There are %d vendors in this consent string.", consent.MaxVendorID())
	log.Printf("This consent string refers to version %d of the Global Vendor List.", consent.VendorListVersion())
	log.Printf("Vendor %d has the user's consent? %t", 3, consent.VendorConsent(3))
}

func main() {
	DemoConsentStringParsing()
}

Hi,

I want to know if you have a due date for TCF v2 support and if you are expected to support both during transition period?

In my case I can receive v1 and v2 in the same time and I want accept the both until TCF v1 is authorized.

Thanks,

Matthieu

I want to check if anyone is working on this.
Otherwise I would want to pick this up.

Going through these documentation.
Any other pointers to get this done would be helpful.

There's a version of this module in the default proxy which doesn't seem to be in the repository itself.

$ GONOPROXY="*" go get github.com/prebid/go-gdpr
go get: upgraded github.com/prebid/go-gdpr v0.8.0 => v0.10.0
$ GOPROXY=https://goproxy.v10s.net/ go get github.com/prebid/go-gdpr
go get: upgraded github.com/prebid/go-gdpr v0.10.0 => v1.9.0

The associated checksums are:

github.com/prebid/go-gdpr v1.9.0 h1:VhthA8zFjbOA3ASltDK2PWBUWXBFwXXdyrabtndOsBU=
github.com/prebid/go-gdpr v1.9.0/go.mod h1:OfBxLfd+JfP3OAJ1MhI4JYAV3dSMQYT1QAb80DHpZFo=

And the contents appears to be the same as v0.9.0. It is the only such version in the proxy's version list.

This breaks go get, which will now only get this version and not v0.10.0 or any future versions unless explicitly asked.

We recently found a rare edge case where this library can panic rather than returning an error.

This occurs if a RangeSection contains fewer RangeEntries than the NumEntries value reports, and that first missing RangeEntry occurs on a Byte boundary.

For example, the 7th RangeEntry in a consent string which has 7 single-element RangeEntries in a row will start on bit 288. This would be the first bit of the 37th byte. If the consent string happens to only has 36 bytes, then the Parse function will panic.

Using the fuzz test string below (or similar)

go test fuzz v1
string("C0000000000000000000000000000000000AAdA000000000000")

the following crash & stack trace occurs:

Fuzz test func:

func FuzzTCF(f *testing.F) {
	// Only one function to be tested
	f.Fuzz(func(t *testing.T, tcfStr string) {
		_, _ = tcf(tcfStr)
	})
}

and tcf func

func tcf(tcf_str string) (tcfData, error) {
	if len(tcf_str) == 0 {
		return tcfData{}, nil
	}
	consent, err := vendorconsent.ParseString(tcf_str) // string is base64 encoded
	if err != nil {
		return tcfData{}, err
	}

	return tcfData{
		tcf_str,
		consent.VendorListVersion(),
		consent.VendorConsent(uint16(TCFFramePlayVendorID)),
		consent.PurposeAllowed(3),
	}, nil
}

index out of range occurs in return value of
/go-gdpr/vendorconsent/tcf2.isSet(...)

Hi,
I would like to check the purpose satisfied PurposeLITransparency, but the interface does not have that. Could you please help me to access that fields

Hello

I detect some consents from a real implementation (cmp id 3) with max vendor id 0 and vendor list id 1 in the last days.

I think it is a mistake from the CMP, since the vendor list id 1 is pretty old (looks like a default value), and when I try to parse with the latest version of this library I got this:

consent BOzZB5dOzZB5dADABAENABAAAAAAAA

error: the consent string encoded a MaxVendorID of 0, but this value must be greater than or equal to 1

however the iab java sdk is capable of decode without exception. In fact there is nothing in the specification saying about max vendor id should be bigger than zero. It is pretty weird, indeed.

for instance, the java library give me this:

TCStringV1 [getVersion()=1, getCreated()=2020-05-14T12:14:52.500Z, getLastUpdated()=2020-05-14T12:14:52.500Z, getCmpId()=3, getCmpVersion()=1, getConsentScreen()=0, getConsentLanguage()=EN, getVendorListVersion()=1, getVendorConsent()={}, getDefaultVendorConsent()=false, getPurposesConsent()={}]

In any case I must contact them to understand why this happens. I think this consent is useless since there is no useful information, but at same time I don't think there is an error here.

I need to ask: how about remove this "max version id" validation? I checked and I see no obvious side effects.

In fact the tcf2 does not check this information, only the v1 does

Thanks

using this site:

http://iabtcf.com/#/encode

I create this consent string: COzSDo9OzSDo9B9AAAENAiCAALAAAAAAAAAACOQAQCOAAAAA.IF5EX2S5OI2tho2YdF7BEYYwfJxyigMgShgQIsS8NwIeFbBoGPmAAHBG4JAQAGBAkkACBAQIsHGBcCQABgIgRiRCMQEGMjzNKBJBAggkbI0FACCVmnkHS3ZCY70-6u__bA

and I can also decode using the web decoder. I just use one vendor and 3 purposes, the rest was the default values

however, using the version 0.8.0 of the library I got this: Error on parsing the number of publisher restrictions: ParseUInt12 expected a 12-bit int to start at bit 276, but the consent string was only 36 bytes long

Using the previous version it was not a problem, so I don't know if it is an issue in the iab site or in the library

Hi,

I would prefer if the Parse and ParseString functions specific to TCF2 returned a ConsentMetadata rather than a boxed api.VendorConsents. This would allow easier access to e.g. the PurposeLITransparency method, and follow the general Go idiom of interfaces for arguments, structs for returns. Unfortunately I don't see how to do this in a compatible way, so I would like to discuss a) is this possible despite some breakage? and b) which kind of breakage is preferred?

The reason it doesn't seem possible is that ConsentMetadata is returned as, and boxed as, as a non-pointer type. So a Parse(data []byte) (ConsentMetadata, error) would have to return a an empty, invalid ConsentMetadata and break the code of anyone checking != nil, but updating the methods and using Parse(data []byte) (*ConsentMetadata, error)would change the type that gets boxed by the version-agnostic Parse.

Personally I think Parse(data []byte) (*ConsentMetadata, error) and using pointer receivers is the better API, but also seems like the breakage more likely to cause runtime errors. (Both cause runtime issues if someone stored the return to an explicit api.VendorConsents, re-boxing it, but the pointer return also affects code that assumes it knows the exact type of a v2 consent boxed by the version-agnostic Parse.)