Outdated url

This whole block barely adds any value beyond your documentation. Are you sure you want to maintain it?

Thanks for the heads up, I've removed this part

I'm confused, you still have this file in your pr?

Hi @patmmccann, sorry we thought you meant just the cache block in that configuration json, but in general yes - we'd like to maintain this example page as it is the way to demo and test the module. For now this is convenient as not many client-side adapters implement echoing the full oRTB device object to their servers. We'll also add the output of the enriched oRTB object to the page itself - should be handy for testing on mobile devices. Thanks

Hopefully not too many drivers viewing ads ;)

You have to use our injection methods or simply rely on the script already being injected by another method

@patmmccann thanks for the comment. Just wanted to clarify:

1. by "our injection methods" - do you mean loadExternalScript API from adloader.js?
2. If so we'd need to add our module code into _approvedLoadExternalJSList, I assume it should also be part of this PR, right?
3. by "another method" do you mean that the user may insert the script tag themselves at the point of embedding Prebid.js into the page when providing configuration, or is it something else?

Yes, yes, yes

If you're using prebid to inject, we prefer you lock versions and pr the project when the script changes

The script is generated by the 51Degrees Cloud API that is version-locked through its URL: https://cloud.51degrees.com/api/v4/<your_resource_Key>.js, however the script itself is generated based on resource-key and properties user selects for it - so we would not be able to store its content as part of this repo. The javascript template and device detection library used by the cloud are open source (as mentioned in our docs):

• https://github.com/51Degrees/javascript-templates/
• https://github.com/51Degrees/device-detection-dotnet

What's going on here, why not just get the high entropy hints in js

Thanks for the comment. Agreed that in general it's a good idea to use getHighEntropyValues API. The injected script actually uses it as a fallback in the case when navigator did not send User-Agent Client Hints as part of the first request. Having the navigator send the User-Agent Client Hints by itself seems to be a bit more performant and also transparent to the user that they give permission to a 3rd party to process those as prescribed by the spec

FWIW - PBJS-core will add high entropy device.sua if the publisher sets some config...

pbjs.setConfig({
       firstPartyData: {
         uaHints: ['platform', 'architecture', 'model', 'platformVersion', 'fullVersionList']
       }
});

This may be something you want to suggest in your doc?

Thanks for raising this, @bretg. A lengthy comment ahead, but we hope it will become a basis for more documentation. Breaking it down below.

PBS modules

The First Party Data Enrichment module with uaHints mentioned above is very relevant for 51D Prebid Server Modules, and we'll actually add it to the server modules docs, because 51D PBS modules are more precise when device.sua is present in the request.

Prebid.js module

51D Prebid.js module injects a dynamically generated script based on the evidence available. It also falls back to the GetHighEntropyValues API, but does not rely on it as a first (or only) choice route - please see the illustrative cases below. Albeit it seems easier, GHEV API is not supported by all browsers (so the decision to call it should be conditional) and also even in Chrome this API will likely be a subject to the Privacy Budget in the future.

In summary we use Delegate-CH http-equiv as the preferred method of obtaining the necessary evidence because it is the fastest method, and future proof. Delegate-CH enables the Chromium-based browser to send the User-Agent Client Hints to a 3rd party right away on the very first request unlike Accept-CH + Permissions-Policy http response headers which would let it send them on subsequent requests. Hence this check in the code that outputs the warning in debug mode.

Illustrative Cases

• if the device is iPhone/iPad then there is no point checking for or calling GetHighEntropyValues at the moment because iOS does not support this API. However this might change in the future.
  Platforms like iOS require additional techniques to identify the model which are not covered via a single API call, and change from version to version of the operating system and browser rendering engine. When used with iOS 51Degrees resolves the iPhone/iPad model groups using these techniques. That is one of the benefits the module brings to the Prebid community as most solutions do not resolve iPhone/iPad model groups. More on Apple Device Detection here.

• if the browser is Brave on Android then there is similarly no point requesting GHEV as the API is not supported.

• if the browser is Chrome then the Delegate-CH if enabled by the publisher would enable the browser to provide the necessary evidence. However if this is not implemented - then the dynamic script would fall back to GHEV which is slower.

As the code for these features changes frequently the relevant snippets are in the data file rather than the core source code. As the web diverges the ability to dynamically adapt is going to be very important. Reducing the depency on Javascript and maximising server side stable controlled environments is part of the 51Degrees approach.