QortexRtdProvider: Supports new Qortex bid enrichment process

[shilohannese]

Type of change

• Updated RTD adapter

Description of change

This change refactors the Qortex RTD module to use the new version of our context and bid enrichment API

• enables bid enrichment for accounts linked to unique internal group ids that have agreement to use this feature
• sends basic page information to our analysis API to match with already analyzed urls and create new analysis processes for bid enrichment
• adds helper functions for reporting and bid enrichment options available within our technology
• refactors testing and creates new units tests for added logic

[github-actions]

Tread carefully! This PR adds 1 linter error (possibly disabled through directives):

• modules/qortexRtdProvider.js (+1 error)

[github-actions]

Tread carefully! This PR adds 1 linter error (possibly disabled through directives):

• modules/qortexRtdProvider.js (+1 error)

[github-actions]

Tread carefully! This PR adds 1 linter error (possibly disabled through directives):

• modules/qortexRtdProvider.js (+1 error)

[patmmccann]

it seems bizarre to send so much content over the wire, why not send a robot to get copies of pages you don't know the contents of? Also, this prevents anyone from using you from behind a login, as you get the login info

[shilohannese]

@patmmccann Our goal here is to send the information specific to the page that the user is accessing in order to allow a publisher to enrich bids with that page data through our API. This is currently directly feeding into our process and is expected data to begin analysis. Changing to a robot would fundamentally alter our product and its ability to quickly provide page-specific contextual data.

We don't collect or use any login info, and our services require existing business relationships and contracts to create a connection that uses this data

[rrochwick]

Thank you for your response, @patmmccann. We have reviewed your feedback and implemented several new security features to ensure that both Qortex and the publisher are fully informed whenever content data is transferred.

Let me first address your suggestion regarding the use of a robot or page crawler to capture this data. While we currently have the capability for page crawling, it is not always an accurate representation of the content that an end user will see on a publisher's site. This is particularly true for publishers with dynamic content or content that is targeted differently based on factors such as geographic location, device type, operating system, or screen resolution. As a result, data collected directly from the user session will provide our services with the most accurate information, allowing us to give publishers precise contextual data to enhance bid auctions.

The additional security measures we've added in this pull request are as follows:

1. Introduction of the 'disableBidEnrichment' configuration parameter: This will give the publisher full control over stopping all content/contextual data transfers to and from Qortex services.
2. Content transfer prevention until publisher authorization: No content will be transferred to Qortex services until the publisher is confirmed as an authorized user within the Qortex system (via groupConfig.active). The group ID used in the configuration must be found and set as an active account in the Qortex platform. If the group ID is not found or is inactive, no content will be passed to Qortex.
3. Content transfer prevention until Qortex bid enrichment enablement: Even with an active group ID, there is an additional toggle on the Qortex side (groupConfig.prebidBidEnrichment) that must explicitly be set to allow bid enrichment contextuality. If prebidBidEnrichment is not set to "true" on the Qortex platform, we will neither collect publisher content nor send contextual information back to the module.

With these measures in place, there should be no accidental transfer of publisher content without explicit acknowledgment from both the publisher and Qortex.

We appreciate your feedback and continued collaboration.

[JoelPM]

Weighing in after this was discussed at the Prebid.js PMC. I am concerned about Prebid enabling the entire contents of a page to be sent to a third party. Even if the publisher is opted in, this feels like a potentially large user privacy violation. I think it's possible that browser makers would consider it similarly, though that's just a guess. I would hate for Prebid to be flagged as allowing this type of behavior, even with pub consent (and assuming the publisher's privacy policy makes explicit that a user's entire page is being sent to a third party).

Given the publisher opt-in requirement, it feels like the same goal could be enabled by having the pub include a separate script that the RTD plugin interacts with. As a user, though, I would actively avoid any site that does this.

In general, I think Prebid should consider adding this behavior to the list of not allowed activities.

[github-actions]

Tread carefully! This PR adds 3 linter errors (possibly disabled through directives):

• modules/qortexRtdProvider.js (+3 errors)

[rrochwick]

@JoelPM @patmmccann :: Thank you for your valuable feedback. In response, we have refined the data collection process to focus exclusively on heading and paragraph tags. This adjustment ensures that no data is inadvertently collected from forms, user inputs, image tags, or similar elements. Additionally, the text collected will be limited to a maximum of 5,000 characters.

We feel it is important to clarify that the bid enrichment feature does not collect data on every page load for every user. Data is only gathered for new pages that have not been previously encountered by our system. This occurs during the first user interaction with a new page, and subsequent users will not trigger further data collection. For instance, if 100,000 users visit the same page, only the first visitor will contribute to the data capture. This ensures we provide contextual analysis for publisher content without incorporating any user-specific information.

We are focused on gathering page-level content, not user data, to provide a detailed understanding of a site's subject matter. This approach is aimed at enhancing the value of our supply partners' content and facilitating the transparent and efficient sharing of that value through our open-source Prebid.js solution while remaining within your policy guidelines.

[rrochwick]

@ChrisHuie @patmmccann We've made changes to the functionality to alleviate concerns. Our team will be on standby for any future requests. Let us know how we can help move this forward.

[rrochwick]

@patmmccann @ChrisHuie The changes requested by the Prebid PMC have been implemented. Bid enrichment is now explicitly opt-in for publishers and will only be enabled once the Qortex system confirms an agreement is in place and verifies the publisher's authorization to use the service. Additionally, we have updated the documentation to clarify the types of content transmitted, and included a notice advising publishers to review any pages for sensitive content before enabling the feature.

[patmmccann]

I'm okay with this state; but the docs changed in the js project md file arent enough, could you link the docs pull as well. Also, I think we decided to ask the pub committee to weigh in cc @GLStephen

[shilohannese]

@patmmccann Thank you for your response, i'm glad to see that we are getting closer to a ready-state with this release. What changes specifically are you looking for in the documentation? Do you mean the changes made in this PR or in another place? Happy to adjust if needed.

[rrochwick]

Previous commit is to address jsdoc issues ticket

[rrochwick]

@patmmccann Would it be possible to elaborate on what you would like linked with the documentation? I think we are a bit confused on what actions we should take next. Thanks!