you cannot gather the eids in this manner; they are for bidders, not for rtd modules to send back up

Thank you for this advice. However, can you elaborate on why we can't? We need first party IDs to populate our graph and render segments to enable targeting. We take care of all aspects related to compliance in the module, so these ids are only retrieved if there is user consent for Sirdata (Vendor 53), cookies (purpose 1) and activities targeting (purposes 1, 3 and 4). Only our customers with a partner ID and a key can activate the module, and they have the possibility to control the sharing of IDs using the "avoidPostEids" parameter. THANKS

Generally, publishers will be violating their contracts with eid providers to send this to you to store in the graph. most of them have a 'you will not store' and 'permissable use' portions of their contract. Installing your module would cause publishers to breach many of their contracts. I'm fine if you take a whitelist of eids sources to store in configuration instead of just defaulting to all. Then publishers would be knowingly opting into this for specific id providers.

Thank you very much for this clarification :) There is perhaps an important information to bring here, which is that we are talking about graph resolution (in terms of access to a catalog of segments relating to a user), but not about a graph constitution. The majority of these IDs will involve agreements with the ID providers we talk to (already like SSP/DSPs), as most need to be decrypted or they will be useless. This makes the use of a whitelist system almost impossible... But once again the publisher has a control parameter at its disposal, and I think we can consider a blacklist: which id provider should systematically be blocked according to you? Finally, unless I'm mistaken, this use case already exists in the Audigent RTD module (https://github.com/prebid/Prebid.js/blob/master/modules/hadronRtdProvider.js)

whoa good catch!

Sure :) In the user ids module the editor only activates the ids that are useful to him and with whom he works. Among these, Sirdata also works (like the bidders) with some, and will later work with others. a whitelist system implies that if Sirdata enters into an agreement with an ID supplier to acquire the decryption keys, we must have all the configs of all the partners updated, which is "impossible" in the short term. At the same time, I think there are two possibilities: either the id is universal and no contractual limitations exist, or the id is private and the user cannot share it, in which case it is encrypted and without agreement with the supplier it cannot be deciphered. In addition, since the encryption keys are changed regularly, the encrypted ID cannot be used for tracking. So there should be no individual limitation, and if by chance there one day exists an ID that absolutely says it is blocked, it is entirely manageable by a blacklist. That being said, we planned that the editor can block absolutely everything with the "avoidPostEids" parameter, but perhaps your recommendation is that it can block one or a few ids and not all?

I know of many examples of ids that do not fall within this dichotomy: "either the id is universal and no contractual limitations exist, or the id is private and the user cannot share it, in which case it is encrypted and without agreement with the supplier it cannot be deciphered."

we must have all the configs of all the partners updated, which is "impossible" in the short term.

I am afraid I find the risk to the publisher outweighs this concern; circulating within the community for additional feedback. We're also taking a look at Audigent's decision here. If you start working with a new id provider, I would imagine all the publisher configs should be possible to update within just a few months.

There's also near certainty that personal information would be used for reasons other than the reasons stated when it was collected, as you are advocating this change in a minor version, without publishers having the opportunity to ask users for new consent. In general, you need the person's consent to use their personal information for a different purpose than the one you originally collected it for, and your module violates this principle in American state law, as you are collecting eids that are in browser storage, not just newly generated ones, that would be often collected without disclosure to the user associate with graph building.

Also, your transmission of all the encrypted ids when you have no relation with these id providers seems to violate data minimization requirements grounded in United States and state law, as well as law 25 in Quebec.

sourced from the internet: "The Federal Trade Commission (FTC) has taken enforcement actions against companies that have collected, used, or retained personal information for purposes other than the original reason given. The FTC can establish a data minimization rule that considers it an unfair trade practice to collect, use, transfer, or retain personal data beyond what is reasonably necessary.

Data minimization is a privacy principle that states that personal information should only be collected and retained for as long as necessary to fulfill a specific purpose. The FTC has brought enforcement actions against companies that have:
Collected more personal information than they disclose or need
Used or shared personal information for incompatible purposes
Retained information beyond the period for which the data is required"

Thank you for your valuable feedback and for highlighting the privacy risks associated with handling encrypted identifiers (eids). We share your concerns and have carefully considered your recommendations.

In response, we have adjusted our code to provide publishers with control over which eids they share with us via a whitelist system. By default, they will share the ID5 identifier with us, as we intend to run tests that involve ID5 providing us with decryption keys. Additionally, they will share their own identifiers (pubProvidedId and sharedId).

If publishers wish to share other eids with us, such as the zeotap ID or the ramp ID, they can do so after obtaining mutual agreement by using the parameter authorizedEids. Publishers also have the option to share no eids at all by setting authorizedEids to an empty array ([]).

We believe this approach balances the need for data utility with the essential requirement for privacy protection and compliance with contractual obligations.

Thank you once again for your insightful feedback.

Thanks!

sourced from the internet: "The Federal Trade Commission (FTC) has taken enforcement actions against companies that have collected, used, or retained personal information for purposes other than the original reason given. The FTC can establish a data minimization rule that considers it an unfair trade practice to collect, use, transfer, or retain personal data beyond what is reasonably necessary.

Data minimization is a privacy principle that states that personal information should only be collected and retained for as long as necessary to fulfill a specific purpose. The FTC has brought enforcement actions against companies that have:
Collected more personal information than they disclose or need
Used or shared personal information for incompatible purposes
Retained information beyond the period for which the data is required"