Intégration et optimisation des services d'enchères et de mises aux enchères

La proposition de conception des services d'enchères et de mise aux enchères pour Android détaille l'exécution et le flux de données de la mise aux enchères sur Android à l'aide du serveur d'enchères et de mise aux enchères de confiance. Pour garantir que les données en transit ne soient gérées que par des API protégeant la confidentialité et des serveurs de confiance, elles sont chiffrées entre le client et le serveur à l'aide du chiffrement bidirectionnel de la clé publique hybride.

</ph>

Pour lancer l'enchère comme indiqué précédemment, la technologie publicitaire du vendeur sur l'appareil doit procédez comme suit:

1. Collecter et chiffrer les données pour la mise aux enchères sur serveur
2. Envoyer une requête à un service vendeur non approuvé
3. Recevoir une réponse d'un service vendeur non approuvé
4. Déchiffrer la réponse à la mise aux enchères Protected Audience et obtenir le résultat de l'enchère

Protected Audience introduit deux nouvelles API compatibles afin de permettre le lancement de mises aux enchères sur serveur :

1. L'API getAdSelectionData collecte des données pour la mise aux enchères sur serveur et génère une charge utile chiffrée contenant les données d'enchères. Le serveur d'enchères et de mise aux enchères utilise cette charge utile pour lancer une mise aux enchères, générer le résultat de l'enchère et renvoyer le résultat.
2. Les clients de technologie publicitaire sur l'appareil peuvent appeler l'API persistAdSelectionResult pour déchiffrer le résultat généré par la mise aux enchères sur serveur et obtenir l'URL de rendu de l'annonce gagnante.

La technologie publicitaire du vendeur sur l'appareil doit intégrer et créer les éléments suivants pour lancer une mise aux enchères :

1. Collecter et chiffrer des données pour le vendeur de mise aux enchères sur serveur : la technologie publicitaire doit appeler l'API getAdSelectionData pour obtenir la charge utile chiffrée.
2. Envoyer une requête à l'envoi du service de vendeur non approuvé : requête HTTP POST ou PUT contenant la charge utile chiffrée générée par l'API getAdSelectionData à son service vendeur et à ses données non fiables requis par le service vendeur non approuvé pour générer des résultats contextuels.
3. Recevoir la réponse du service vendeur non approuvé : la réponse du service vendeur non approuvé contient le résultat de la mise aux enchères chiffrée et le résultat Protected Audience chiffré.
4. Déchiffrez la réponse à la mise aux enchères Protected Audience et obtenez le résultat de l'enchère: Pour déchiffrer le résultat de la mise aux enchères Protected Audience, la technologie publicitaire du vendeur doit appeler l'API persistAdSelectionResult. Le résultat généré par persistAdSelectionResult aidera les technologies publicitaires à déterminer si le contexte l'annonce ou l'annonce Protected Audience a remporté l'enchère, et l'URI de l'annonce gagnante l'annonce Protected Audience, le cas échéant.

Fonctionnalités compatibles avec la mise aux enchères sur serveur

Notre objectif est de proposer toutes les fonctionnalités actuellement disponibles pour la mise aux enchères sur l'appareil. Voici le calendrier pour la prise en charge de ces fonctionnalités lors des enchères sur serveur :

Mise aux enchères sur serveur à l'aide des API Protected Audience

Dans la version Preview développeur, AdSelectionManager propose deux nouvelles API : getAdSelectionData et persistAdSelectionResult. Ces API permettent aux SDK de technologies publicitaires de s'intégrer aux serveurs d'enchères et de mise aux enchères.

Collecter et chiffrer les données pour une mise aux enchères sur serveur

L'API getAdSelectionData génère l'entrée requise pour les composants d'enchères et de mise aux enchères tels que BuyerInput et ProtectedAudienceInput, puis chiffre les données avant de rendre le résultat accessible à l'appelant. Pour éviter toute fuite de données entre les applis, ces données contiennent les informations de tous les acheteurs présents sur l'appareil. Pour en savoir plus sur cette décision, consultez la section Considérations liées à la confidentialité et les stratégies pour l'optimiser dans la section Considérations liées à la taille.

Pour accéder à l'API, l'accès à l'API Protected Audience doit être activé, et l'autorisation ACCESS_ADSERVICES_CUSTOM_AUDIENCE doit être définie dans le fichier manifeste de l'appelant.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. L'appelant doit définir le champ seller dans la requête, car il permet d'exécuter des vérifications d'inscription avant de répondre à la requête.
2. Le champ coordinatorOriginUri est facultatif.
   1. Si ce champ est défini, il doit correspondre au schéma, au nom d'hôte et au port de la l'URL du coordinateur configurée Déployer le serveur d'enchères et de mise aux enchères du vendeur.
   2. Le coordinateur doit faire partie de la liste des coordinateurs approuvés:

      Fournisseur	URI	Origine de l'URI	Par défaut
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Oui
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Non

   3. Si aucune origine de coordinateur n'est indiquée, le coordinateur par défaut est utilisé.
   4. Même s'il est très peu probable que l'URL de Coordinate soit modifiée, nous vous recommandons vivement de mettre en place un mécanisme de gestion dynamique de cette URL. Ainsi, toute modification future apportée à l'URL pourra être prise en compte sans nécessiter de nouvelle version du SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Une fois la requête validée, les données des acheteurs sur l'appareil sont composées dans BuyerInput et ProtectedAudienceInput. L'objet de charge utile final est ensuite chiffré à l'aide du chiffrement bidirectionnel de la clé publique hybride.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome est généré comme résultat de l'API getAdSelectionData. Elle contient les éléments suivants :

1. adSelectionId : entier opaque pour identifier cette invocation de getAdSelectionData. Le client de technologie publicitaire doit conserver cette valeur adSelectionId, qui sert de pointeur vers l'appel getAdSelectionData. Cet identifiant est nécessaire à l'API persistAdSelectionResult pour déchiffrer le résultat d'enchères du serveur d'enchères et de mise aux enchères. Il est également requis par les API reportImpression et reportEvent.
2. adSelectionData : il s'agit des données d'enchères chiffrées requises par le serveur d'enchères et de mise aux enchères pour lancer des enchères. Cette méthode contient :
   1. Les données d'audience personnalisée filtrées en fonction de la limitation de la fréquence d'exposition, des filtres d'installation de l'appli et des exigences liées aux enchères sur le serveur pour les audiences personnalisées.
   2. Dans une prochaine version, elle contiendra les données d'installation de l'appli.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Traitement des erreurs, des exceptions et des échecs

Si la génération des données de sélection des annonces ne peut pas être terminée pour des raisons telles que des arguments non valides, des délais d'inactivité ou une utilisation excessive des ressources, le rappel OutcomeReceiver.onError() fournit une AdServicesException avec les comportements suivants :

1. Si getAdSelectionData est initié avec des arguments non valides, AdServicesException indique une exception IllegalArgumentException comme étant la cause.
2. Toutes les autres erreurs reçoivent une AdServicesException avec IllegalStateException pour cause.

Envoyer une requête à un service vendeur non approuvé

À l'aide d'AdSelectionData, le SDK de l'appareil peut envoyer une requête au service publicitaire de son vendeur en incluant les données dans une requête POST ou PUT :

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

Le SDK sur l'appareil est responsable de l'encodage de ces données. Nous vous recommandons d'utiliser une solution efficace, telle que l'envoi de la requête au service publicitaire du vendeur en tant que multipart/form-data.

Recevoir une réponse d'un service vendeur non approuvé

Comme indiqué dans la section Explication du système d'enchères et de mise aux enchères, lorsque le service vendeur non approuvé reçoit la demande, il appelle les acheteurs partenaires pour obtenir des annonces contextuelles.

Le service vendeur non approuvé transfère les éléments chiffrés adSelectionData et AuctionConfig au service SellerFrontEnd du serveur d'enchères et mise aux enchères s'exécutant dans un TEE.

Une fois l'enchère Protected Audience terminée, le service SellerFrontEnd chiffre le résultat de l'enchère et le renvoie en réponse au service vendeur non approuvé.

Le service vendeur non approuvé envoie une réponse à l'appareil contenant l'annonce contextuelle et/ou le résultat chiffré de l'enchère Protected Audience.

Lorsqu'il reçoit la réponse, le code de technologie publicitaire du vendeur sur l'appareil peut choisir d'utiliser uniquement l'annonce contextuelle dans la réponse ou, s'il estime que le résultat Protected Audience présente un intérêt supplémentaire, il peut choisir de déchiffrer le résultat Protected Audience en appelant l'API PersistAdSelectionResult.

API PersistAdSelectionResult

Pour déchiffrer le résultat Protected Audience, la technologie publicitaire du vendeur peut appeler la deuxième API Protected Audience persistAdSelectionResult. L'API déchiffre le résultat et renvoie un AdSelectionOutcome, le même objet renvoyé aujourd'hui par une mise aux enchères sur l'appareil.

Pour accéder à l'API, l'appelant doit activer l'accès à l'API Protected Audience et définir l'autorisation ACCESS_ADSERVICES_CUSTOM_AUDIENCE dans son fichier manifeste.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

L'appelant doit définir les éléments suivants dans la requête :

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId : l'identifiant opaque généré par l'appel getAdSelectionData dont l'appelant souhaite déchiffrer le résultat.
2. seller : l'identifiant du vendeur de technologies publicitaires doit être défini dans la requête pour exécuter les vérifications d'inscription avant de la traiter.
3. adSelectionResult : le résultat d'enchères chiffré généré par le serveur d'enchères et de mise aux enchères que l'appelant souhaite déchiffrer.

Réponse AdSelectionOutcome

Si une annonce Protected Audience l'emporte, AdSelectionOutcome renvoie l'URI de rendu de l'annonce gagnante. Une fois l'adSelectionResult déchiffré, les données de rapport sont conservées en interne. Le rappel OutcomeReceiver.onResult() renvoie un AdSelectionOutcome contenant les éléments suivants :

• URI : s'il existe une annonce Protected Audience gagnante, une URL de rendu pour l'annonce gagnante est renvoyée. En l'absence de gagnant, "Uri.EMPTY" est renvoyé.
• adSelectionId : l'adSelectionId associé à cette mise aux enchères sur serveur.

Traitement des erreurs, des exceptions et des échecs

Si la génération des données de sélection des annonces ne peut pas être terminée pour des raisons telles que des arguments non valides, des délais d'inactivité ou une utilisation excessive des ressources, le rappel OutcomeReceiver.onError() fournit une AdServicesException avec les comportements suivants :

1. Si getAdSelectionData est initié avec des arguments non valides, AdServicesException indique une IllegalArgumentException comme étant la cause.
2. Toutes les autres erreurs reçoivent une AdServicesException avec IllegalStateException pour cause.

Considérations liées à la confidentialité

adSelectionData est chiffré pour que les données en transit ne soient accessibles qu'aux API protégeant la confidentialité et aux serveurs de confiance.

Malgré le chiffrement, des fuites de données peuvent se produire en raison de la taille d'adSelectionData. La taille d'adSelectionData peut varier pour les raisons suivantes :

1. Modifications des données CustomAudience présentes sur l'appareil.
2. Modifications apportées à la logique de filtrage CustomAudience.
3. Modifications apportées à l'entrée de l'appel getAdSelectionData.

La modification de la taille d'adSelectionData peut être utilisée pour générer un identifiant multi-applications, comme indiqué dans la discussion à propos de la fuite 1 bit. De nombreuses mesures d'atténuation applicables aux fuites 1 bit s'appliquent également ici.

Pour gérer ces fuites, nous prévoyons de générer les mêmes adSelectionData pour tous les appels à l'API getAdSelectionData. Dans les versions initiales, toutes les CustomAudiences de l'appareil sont utilisées pour créer les adSelectionData, et la charge utile chiffrée est complétée pour masquer les variations de taille. Nous allons également limiter l'influence des paramètres d'entrée de GetAdSelectionData sur les adSelectionData générées.

Cependant, générer les mêmes adSelectionData pour toutes les technologies publicitaires à l'aide de toutes les les données d'enchères sur l'appareil créent une charge utile volumineuse qui doit maintenant être transférée dans chaque appel au serveur ad tech. L'utilisation de toutes les audiences personnalisées sur l'appareil pour générer la charge utile des enchères ouvre également l'écosystème aux utilisations abusives d'entités malveillantes. Nous avons abordé ces problèmes dans les sections Optimisations de la taille et Atténuation des utilisations abusives ci-dessous.

Optimisations de la taille

Le SDK client de technologie publicitaire doit empaqueter les octets chiffrés des adSelectionData dans l'appel contextuel HTTP PUT/POST effectué auprès du serveur de technologie publicitaire. Pour réduire la latence et les coûts du délai aller-retour, il est nécessaire de réduire autant que possible la taille des adSelectionData sans nuire à l'utilité.

Nous prévoyons d'explorer et potentiellement d'introduire les optimisations suivantes dans les versions à venir afin de réduire la taille des adSelectionData :

1. Charge utile générée dans un ensemble fixe de tailles de buckets avec marge intérieure : pour réduire les fuites liées aux variations de taille tout en permettant des charges utiles moins élevées, nous vous suggérons d'utiliser un binning de taille fixe pour la charge utile générée. Si vous limitez le nombre de buckets, par exemple, à 7, le nombre de bits d'entropie divulguée par appel à getAdSelectionData sera inférieur à 3.

   Si les données sur l'appareil dépassent la taille maximale du bucket, les stratégies mentionnées ci-dessous, telles que les valeurs de priorité, seront utilisées pour décider des données à supprimer.

2. Configuration de l'acheteur : nous évaluons la possibilité de laisser les acheteurs définir une configuration de charge utile par acheteur. Cette configuration est utile pour identifier les enchères auxquelles un acheteur souhaite participer. Si possible, lors de l'inscription, une technologie publicitaire d'acheteur peut enregistrer un point de terminaison à partir duquel Protected Audience récupère la configuration de la charge utile à une fréquence régulière quotidienne. Les API protégeant la confidentialité exposent également une API pour permettre aux technologies publicitaires des acheteurs d'enregistrer ce point de terminaison.

   Cette configuration permet ensuite d'évaluer la contribution d'un acheteur aux adSelectionData générées pour chaque requête getAdSelectionData.

   La configuration de la charge utile de l'acheteur permet aux acheteurs de spécifier les éléments suivants :

   1. Liste des vendeurs autorisés : les CustomAudiences de l'acheteur ne sont ajoutées à la charge utile que si un vendeur de la liste d'autorisation est à l'origine de l'appel getAdSelectionData. Nous récupérerions la configuration de la charge utile à une cadence quotidienne pour maintenir la liste d'autorisation à jour.
   2. Limite de taille par vendeur : l'acheteur peut spécifier une taille maximale par vendeur afin de déterminer la taille de données à envoyer dans la charge utile lorsqu'une mise aux enchères est initiée par un certain vendeur. Cela peut être utile si un acheteur souhaite consacrer plus de ressources au traitement des données de mise aux enchères de certains vendeurs. L'interface SellerFrontendService transfère uniquement les données spécifiques à l'acheteur vers chaque BuyerFrontendService. Par conséquent, en définissant une limite de taille par vendeur, un acheteur peut explicitement contrôler la quantité de données ingérées et traitées par le BuyerFrontendService de son serveur d'enchères et de mise aux enchères lancées par un vendeur.

3. Configuration du vendeur : nous évaluons la faisabilité d'une configuration de mise aux enchères par vendeur qui permettrait à ces derniers de définir des paramètres d'enchères afin de contrôler la taille de la charge utile ainsi que les participants. Si possible, lors de l'inscription, la technologie publicitaire du vendeur pourrait spécifier le point de terminaison à partir duquel Protected Audience pourrait récupérer la configuration de la mise aux enchères par vendeur à un rythme régulier. Cette configuration permet ensuite de déterminer la composition et les limites des adSelectionData générées pour chaque requête getAdSelectionData.

   Comme pour la configuration de l'acheteur, une configuration par vendeur permet aux vendeurs de spécifier l'ensemble d'acheteurs qu'ils souhaitent voir dans une mise aux enchères et d'indiquer des limites de contribution par acheteur à la taille de la charge utile.

   La configuration de la mise aux enchères permet aux vendeurs de spécifier les éléments suivants :

   1. Liste d'acheteurs autorisés : pour les enchères initiées par le vendeur donné, seuls les acheteurs de la liste d'autorisation peuvent contribuer aux CustomAudiences pour l'enchère. La configuration de l'enchère doit être mise à jour quotidiennement afin de maintenir la liste d'autorisation à jour en fonction de la liste d'autorisation de l'acheteur côté serveur.
   2. Limite de taille par acheteur : les vendeurs peuvent spécifier une limite par acheteur pour réguler la taille des données importées par chaque acheteur dans la charge utile envoyée à SellerFrontendService. Si l'acheteur dépasse la limite de taille par acheteur, la priorité CustomAudience définie dans la configuration de la charge utile de l'acheteur sera utilisée afin d'obtenir les données dans les limites prévues.
   3. Priorité par acheteur : autorisez les vendeurs à définir la priorité par acheteur. La priorité par acheteur permet d'identifier les données de l'acheteur à conserver dans la charge utile si la taille de la charge utile dépasse la limite définie.
   4. Limite de taille maximale pour la charge utile : l'allocation des ressources peut varier d'un vendeur à l'autre, et vous pouvez définir une limite de taille maximale pour la charge utile de l'enchère par requête. La limite de taille maximale respecte les buckets de taille fixe définis par l'API Protected Audience.

4. Modifications de l'audience personnalisée

   1. Spécifier la priorité de l'audience personnalisée : permet aux acheteurs de spécifier une valeur de priorité dans une audience personnalisée. Le champ priority permet d'identifier les audiences personnalisées à inclure dans une mise aux enchères si l'ensemble des audiences personnalisées de l'acheteur dépasse les limites de taille par vendeur ou par acheteur. Une valeur de priorité non spécifiée dans une audience personnalisée serait 0.0 par défaut.

5. Modifications des données de charge utile

   1. Réduire les données envoyées dans la charge utile : comme indiqué dans la section Optimisation de la charge utile des services d'enchères et de mise aux enchères, une charge utile plus élevée est générée par les données ads de l'audience personnalisée, par les signaux d'enchères utilisateur et par les signaux Android. Une charge utile plus élevée peut être réduite en :
      1. Demandant au client d'envoyer les ID de rendu des annonces (au lieu des objets d'annonces) dans la charge utile.
      2. Faisant en sorte que le client n'envoie aucune donnée publicitaire dans la charge utile.
      3. N'envoyant pas les signaux d'enchères de l'utilisateur dans la charge utile du client.

Bien que les stratégies mentionnées ci-dessus permettent aux technologies publicitaires de définir des configurations pour gérer la composition et les limites de la charge utile des adSelectionData, elles peuvent également devenir un facteur de modulation de la taille des adSelectionData en modifiant les paramètres de configuration. Pour éviter cela, la configuration est récupérée quotidiennement par Protected Audience à partir du point de terminaison configuré.

Optimisation de la latence

Pour que les mises aux enchères sur serveur aient un niveau d'utilité souhaitable, nous devons nous assurer que les API getAdSelectionData et persistAdSelectionResult présentent une faible latence par appel. Bien que nous souhaitions proposer la prise en charge de fonctionnalités pour les API en 2023, notre prochaine version se concentrera sur les analyses comparatives et les optimisations de latence pour les API.

Nous étudions les stratégies suivantes pour maintenir la latence dans des limites acceptables :

1. prégénération de données Protected Audience par vendeur : la configuration des mises aux enchères du vendeur et de la charge utile de l'acheteur sera stable pour une durée considérable (quotidienne), la plate-forme peut précalculer et stocker les données Protected Audience éligibles.

   La plate-forme devrait donc créer un mécanisme permettant de surveiller les mises à jour de l'audience personnalisée et de modifier les données Protected Audience prégénérées en fonction des mises à jour. La plate-forme doit aussi déclarer les SLO retarder la technologie publicitaire entre les mises à jour d'audiences personnalisées et l'apparition variation du adSelectionData généré pour la mise aux enchères sur serveur.

   Étant donné qu'un appareil fournit un modèle de calcul de ressources limité avec des priorités de processus variables, nous reconnaissons que cette installation de prégénération doit s'accompagner de garanties de fiabilité et de SLO élevées.

   La prégénération des données Protected Audience se baserait donc sur

   1. L'acceptation par le vendeur de générer à l'avance des données Protected Audience.
   2. L'éligibilité des acheteurs à participer à une enchère lancée par un vendeur en particulier.
   3. L'identification des audiences personnalisées par acheteur qui feront partie de la charge utile, compte tenu des éléments suivants :
      1. Limites de taille par acheteur, priorité par acheteur et limites de taille maximales définies dans la configuration du vendeur.
      2. Limite de taille par vendeur, priorité d'audience personnalisée définie dans la configuration de l'acheteur.

2. Une meilleure application du filtrage négatif : si le vendeur le souhaite, la plate-forme pourrait précalculer les adSelectionData en générant à l'avance des données Protected Audience et en appliquant un filtrage négatif sur les appels critiques getAdSelectionData. Cela permettrait aux vendeurs de trouver un équilibre entre la réduction de la latence et l'obsolescence dans le filtrage négatif.

   La plate-forme pourrait fournir cette assistance en fournissant une option par défaut dans la configuration du vendeur, avec une limite d'obsolescence et une option de forçage dans getAdSelectionData pour permettre des calculs plus récents si nécessaire. La plate-forme pourrait également fournir une API d'initialisation supplémentaire à appeler avant getAdSelectionData pour préparer l'enchère.

3. Calcul de la charge utile pour plusieurs enchères : dans certains cas, il peut être préférable d'utiliser une API performante en termes de latence, au détriment de l'obsolescence des données. Pour ce faire, la plate-forme peut introduire une API d'initialisation permettant de calculer la charge utile complète et fournir une référence à la charge utile calculée à l'appelant.

   Pour les appels suivants à getAdSelectionData, l'appelant pourrait fournir une référence à la charge utile précalculée à utiliser pour la génération des adSelectionData.

Les trois stratégies mentionnées ci-dessus se trouvent à la phase d'exploration et visent à décrire la direction que la plate-forme peut prendre pour optimiser la latence. À mesure que nous étudions les profils de latence plus détaillés de l'API et des exigences de la technologie publicitaire, nous continuerons à proposer d'autres stratégies.

Atténuation et identification des utilisations abusives

Comme indiqué dans les considérations liées à la confidentialité, adSelectionData est généré à l'aide de toutes les données de l'acheteur sur l'appareil.

Toutefois, si toutes les données de l'acheteur sur l'appareil sont utilisées pour générer le adSelectionData, alors une entité malveillante peut se faire passer pour un acheteur et créer des données d'acheteurs frauduleuses afin de dégrader les performances d'Android, surcharger la charge utile pour augmenter le coût d'une technologie publicitaire pour mettre aux enchères ou définir des enchères, etc.

Atténuation

Certaines mesures mentionnées dans la section sur les considérations liées à la taille, comme la configuration de la charge utile de l'acheteur contenant les vendeurs de la liste d'autorisation et la configuration de la mise aux enchères du vendeur contenant les acheteurs de la liste d'autorisation, aideraient à exclure les données inattendues dans la charge utile.

D'autres mesures prises en compte, telles qu'autoriser les SSP à spécifier la priorité de l'acheteur, à placer un quota par acheteur dans la charge utile générée et à définir une taille maximale par charge utile pour les enchères, peuvent également aider à atténuer l'impact des surcharges malveillantes de la charge utile. Ces mesures sont destinées à permettre aux technologies publicitaires de définir les technologies publicitaires avec lesquelles elles collaborent et de définir des limites acceptables pour la charge utile à traiter.

Comme indiqué précédemment, toutes les mesures d'atténuation mises en place pour lutter contre les abus, ainsi que les restrictions de taille, doivent respecter les considérations liées à la confidentialité.

Identification d'entités malveillantes

Bien que les mesures d'atténuation mentionnées ci-dessus protègent la génération des adSelectionData pour les mises aux enchères sur serveur, elles n'aident pas à identifier les entités malveillantes ni à protéger la plate-forme des utilisations abusives telles que la création d'un nombre sans précédent d'audiences personnalisées d'un acheteur.

Pour garantir la stabilité et la santé de la plate-forme, nous devons trouver un mécanisme permettant d'identifier les entités malveillantes, les vecteurs d'abus et la motivation des attaques spécifiques. Dans les versions suivantes, nous présenterons les explications des vecteurs d'abus potentiels et les protections en place pour les contrer.