Confidențialitate Sandbox pentru web: peisajul în schimbare a confidențialității și impactul asupra site-urilor dvs

Chrome va aduce modificări de confidențialitate prin intermediul inițiativei Privacy Sandbox pe tot parcursul anului 2023, în timp ce construiește noi tehnologii pentru a păstra informațiile private private. Simultan, editorii web și mărcile își schimbă strategia digitală pentru a ajuta la păstrarea veniturilor publicitare și a analizelor de marketing valoroase care se bazează pe cookie-uri terțe.

Acest impuls către confidențialitate extinsă a browserului generează o cerere mai mare de personalizare a site-ului web.

În această sesiune, Sam Dutton, avocat pentru dezvoltatori Google, prezintă schimbările care urmează, împărtășește obiectivele inițiativei Privacy Sandbox și vă ajută să înțelegeți mai bine cum puteți pivota pentru a vă asigura că aveți datele de care aveți nevoie pentru a vă menține afacerea și site-urile. a merge inainte.

Slide-urile sesiunii:

Transcriere:

SAM DUTTON: Bună, sunt Sam Dutton. Sunt un Developer Advocate cu echipa Chrome cu sediul aici, în Londra. Vă mulțumesc foarte mult că mi-ați fost alături astăzi. Deci trei lucruri pe care le voi face în următoarele 25 de minute. Vă voi oferi o prezentare generală a API-urilor Privacy Sandbox. Vă voi explica ce trebuie să faceți acum și vă voi arăta cum puteți deveni un tester și vă voi participa la discuțiile despre API-uri și vă voi oferi feedback.

Deci, permiteți-mi să încep prin a explica de ce avem nevoie de Privacy Sandbox. Mulți dintre voi veți cunoaște prea bine povestea din spate, dar merită să repetăm ​​rapid de ce avem nevoie de asta și cum am ajuns acolo unde suntem astăzi. Prin urmare, Privacy Sandbox este o inițiativă pentru a ajuta la construirea unui set de API-uri de păstrare a confidențialității pentru a sprijini modelele de afaceri care finanțează web-ul deschis pentru un viitor fără mecanisme de urmărire, cum ar fi cookie-urile terță parte.

Acum este posibil să fi văzut acest exemplu de la Google I/O. Este un site tipic cu componente din surse diferite. Și, desigur, componabilitate este una dintre superputeri ale web-ului. Aveți o hartă de la o origine, un scenariu de la alta și așa mai departe și, desigur, publicitate și indiferent dacă ne place sau nu și orice ne-ar rezerva viitorul, publicitatea a devenit o sursă crucială de venituri și un motor pentru afaceri pe web.

Acum, în acest moment al istoriei, cred că browserele și CMS-urile trebuie să accepte cazuri de utilizare în publicitate. Deci care este problema? Ei bine, selecția anunțurilor, măsurarea conversiilor, detectarea fraudei, personalizarea dispozitivului, multe alte cazuri de utilizare s-au bazat pe identitatea între site-uri folosind mecanisme care pur și simplu nu au fost construite având în vedere confidențialitate.

Acum, nu doar cookie-urile de la terți, ci și amprentele digitale sunt folosite pentru a urmări comportamentul utilizatorilor pe site-uri sau alte site-uri solicită informații personale, cum ar fi adrese de e-mail și, în plus, ecosistemele terților sunt cu adevărat complexe, în special pentru publicitate. Nici măcar dezvoltatorii, agenții de publicitate sau editorii nu înțeleg lanțul de aprovizionare pentru serviciile terților.

Deci, cu siguranță, atunci când vizitez un site web, nu știu toți terții implicați și ce fac aceștia cu datele mele și nu sunt doar eu, cercetările arată că oamenilor le pasă cu adevărat să aibă controlul asupra datelor lor. Preocupările privind confidențialitatea determină din ce în ce mai multe alegeri cu privire la ceea ce fac oamenii online, iar autoritățile de reglementare din întreaga lume intensifică cerințele de confidențialitate, iar acest lucru se întâmplă foarte repede.

Deci, având în vedere câte companii se bazează pe publicitate online eficientă și câți editori se bazează pe publicitate pentru a-și monetiza site-urile și o mulțime de alte cazuri de utilizare, aceasta este o problemă pentru întregul ecosistem web și nu doar pentru companiile de tehnologie și platformele publicitare. Dar, desigur, deoarece web-ul este o platformă deschisă, propunerile de schimbare trebuie să accepte și feedback, iar browserele precum Chrome nu pot și nu vor să acționeze unilateral.

Browserele nu sunt produse pentru care furnizorii de browsere pot lua decizii izolat, iar realitatea este că web-ul nu a fost proiectat pentru multe dintre cerințele care sunt esențiale pentru platforma de astăzi pentru detectarea fraudelor în publicitate, gestionarea identității și toate aceste alte cerințe, cazuri de utilizare și curând. Deci, avem nevoie de tehnologii create special pentru acest web axat pe confidențialitate și aici intervine Privacy Sandbox.

Prin urmare, Chrome a lucrat cu comunitatea web alături de părțile interesate din industrie și de autoritățile de reglementare pentru a dezvolta noi tehnologii de păstrare a confidențialității care pot susține un ecosistem sănătos și durabil. Acum, odată ce aceste noi API-uri create special sunt disponibile, trebuie să ne asigurăm că companiile au timp să le adopte, astfel încât să putem elimina treptat suportul pentru cookie-urile terță parte în Chrome și să ne continuăm munca pentru a atenua alte tipuri de urmărire.

Acum, setul de bază de principii pentru această inițiativă este potențialul model de confidențialitate pentru web, iar acesta a fost dezvoltat de experții în confidențialitate și de informaticieni de la Google. Acest model de confidențialitate stabilește un set de reguli de bază pentru proiectarea tehnologiilor care îndeplinesc cazurile de utilizare a platformei web despre care am vorbit, respectând totodată nevoile noastre în schimbare de confidențialitate.

În special, propunerea acoperă problema dificilă a modului de activare a conexiunilor între site-uri fără a compromite confidențialitatea. Acum, una dintre inovațiile majore ale API-urilor Privacy Sandbox este aceea de a permite browserului să acționeze în numele utilizatorului, într-un fel revenind la rolul principal al browserului ca ceea ce numim agent utilizator.

Cu tehnologiile actuale, datele sunt colectate, agregate și partajate de terți pentru a urmări navigarea utilizatorilor pe site-uri. API-urile de confidențialitate Sandbox pot permite măsurarea conversiilor licitațiilor publicitare și aceste alte sarcini să fie îndeplinite de browserul utilizatorului de pe dispozitivul utilizatorului.

Așa că trebuie să reconstruim platformele publicitare și web-ul, cu colaborarea între furnizorii de browsere, platforme, agenți de publicitate, editori de tehnologie, utilizatori, autorități de reglementare și comunitatea de confidențialitate și nu în ultimul rând dezvoltatori ca tine care lucrează cu platforme CMS.

Așa că, având în vedere toate acestea, vreau doar să vă ofer un tur al API-urilor Privacy Sandbox. Deci, la Google, aceasta este o inițiativă comună pe web și Android. Privacy Sandbox pe Android se concentrează pe introducerea de noi soluții de publicitate mai private, fără identificatori de aplicații încrucișate.

Web-ul și Android, desigur, împărtășesc aceleași principii și câteva dintre propunerile web sunt dezvoltate și pentru Android. Cu toate acestea, desigur, platformele mobile web și Android se bazează pe tehnologii fundamental diferite.

Deci, aceasta este pe Android o inițiativă distinctă, dar este una pe care cei dintre voi care construiesc aplicații Android și lucrează pe web, veți dori să fiți cu ochii pe asta. Prin urmare, Google a testat noile API-uri în colaborare cu o serie de parteneri la nivel global.

Sute de companii care participă la forumuri publice, fie W3C, explică problemele de pe GitHub și așa mai departe, publicând perspective și analize și participând la mese rotunde din industrie, împărtășind feedback cu Chrome și Android și, desigur, participând la testare.

Acum nu vă înșelați, Privacy Sandbox are o mulțime de cerințe de acoperit și va fi dificil pe parcurs. Adică, cred că vestea bună este că sfârșitul tuturor acestor platforme va avea platforme mai sigure și mai private pentru utilizatori și mai bune pentru advertiseri, editori, dezvoltatori și, bineînțeles, pentru platforme precum WordPress.

Deci, nu voi descrie toate API-urile Privacy Sandbox. În schimb, aș dori să mă concentrez pe cele trei API-uri principale de publicitate din Privacy Sandbox. Acestea sunt subiecte, FLEDGE și raportare de atribuire. Subiectele noastre și FLEDGE sunt cunoscute ca API-uri de relevanță.

Now Topics oferă semnale de nivel înalt ale interesului unui utilizator pe baza istoricului recent de navigare al acestuia. Și Subiectele pot fi combinate cu semnale contextuale și date primare pentru a selecta anunțuri relevante.

Și FLEDGE acceptă remarketing mai detaliat și cazuri de utilizare a publicului personalizat, în care agenții de marketing doresc să ajungă la publicul care și-a manifestat interes pentru anumite site-uri web sau produse, dar, desigur, pentru a face acest lucru posibil într-un mod de păstrare a confidențialității.

În cele din urmă, Raportarea atribuirii este propunerea Chrome pentru măsurarea campaniei de păstrare a confidențialității, oferind rapoarte de performanță anonimizate și atunci când oamenii văd sau dau clic pe un anunț, apoi continuă să finalizeze o achiziție sau un alt tip de conversie.

Deci, aceste API-uri au trecut printr-o perioadă de testare în Android și în Chrome pe desktop și mobil. Dacă lucrați cu platforme de tehnologie publicitară, trebuie să vă asigurați că înțelegeți că acele platforme intenționează să abordeze aceste cazuri de utilizare și cazurile de utilizare care sunt îndeplinite de aceste API-uri pentru acest viitor, fără cookie-uri terțe sau alte mecanisme de urmărire.

Așa că acum am avut o perioadă de testare tehnică cu API-urile activate folosind steaguri Chrome, iar acum, în versiunea de încercare inițială, activată inițial doar pentru un mic procent din utilizatorii Chrome. Deci, acum ne aflăm în această etapă a testării utilitare, 50% dintre utilizatorii Chrome Canary dezvoltatori și beta au API-urile de încercare pentru originea anunțurilor activate pe paginile care oferă un simbol valid și 5% dintre utilizatorii stabili.

Acum, acesta este un mic procent din traficul general Chrome, desigur, dar este suficient pentru testarea limitată a API-urilor cu utilizatori reali. Și acum ne îndreptăm către lansarea în Chrome Stable, unde API-urile vor fi disponibile pentru toți utilizatorii în mod prestabilit și voi reveni la cronologia pentru asta mai târziu.

Așadar, pentru a reitera, pentru un singur utilizator puteți activa API-urile folosind semnalizatoarele Chrome, dar pentru testare la scară, trebuie să participați la încercarea de origine a Privacy Sandbox și voi împărtăși linkuri mai târziu pentru îndrumări despre cum să faceți toate acestea. .

Deci, apropo, Chrome actualizează, de asemenea, controalele de confidențialitate ale utilizatorilor, cum ar fi interfața de utilizare pentru aceasta, iar comenzile de confidențialitate Sandbox sunt de fapt disponibile ca parte a procesului de origine a API-urilor de reclame. Oamenii vor putea să vadă și să gestioneze interesele asociate cu navigarea lor sau să dezactiveze complet API-urile.

Deci, există de fapt alte trei tehnologii Privacy Sandbox pe care cred că ați dori, de asemenea, să le testați sau, cu siguranță, să le semnalați la oricare dintre furnizorii dvs. terți. În primul rând, CHIPS. Aceasta este cookie-urile având stat de partiție independentă permite dezvoltatorilor să opteze pentru un cookie pentru stocarea partiționată cu un borcan separat pentru cookie-uri pentru fiecare site de nivel superior.

Seturile primare permit numelor de domenii conexe deținute și operate de aceeași entitate să se declare ca aparținând aceleiași părți primare și Jetoane de stat private. S-ar putea să fi auzit de acest nume inițial ca Trust Tokens. Acesta este un API pentru a transmite o cantitate limitată de informații de la un context de navigare la altul, de exemplu, pe site-uri pentru a ajuta la combaterea fraudei, dar fără a utiliza tehnici de urmărire pasivă.

Deci, mai întâi, să aruncăm o privire mai profundă asupra API-ului Topics. API-ul Topics oferă un mecanism pentru a permite publicitatea bazată pe interese, dar fără a permite terților să urmărească activitatea de navigare a utilizatorilor. Deci, API-ul are, într-un sens, trei componente majore și, în primul rând, publicitatea bazată pe interese necesită o taxonomie a subiectelor de interes.

Taxonomia Topics API arată astfel. Este o listă de subiecte întreținută public, care poate fi citită de oameni, care evită subiectele sensibile. Și acum este probabil ca acest lucru să se schimbe și să se dezvolte în timp în consultare cu ecosistemul web și asta înseamnă că oamenii ca tine avem nevoie de feedback-ul tău cu acest lucru, precum și cu orice altceva.

Deci, API-ul Topics trebuie să deducă interesele unui utilizator pe baza activității sale de navigare, dar, așa cum am spus, să facă asta într-un mod care să le păstreze confidențialitatea. Deci, subiectele de interes de top sunt înregistrate pentru un utilizator în browserul său de pe dispozitivul său pe baza activității sale recente de navigare din nou, de către browserul său de pe dispozitivul său.

Acum, în prezent, Topics face acest lucru folosind învățarea automată pentru a mapa numele de gazdă ale paginilor pe care utilizatorul le vizitează la Topics din taxonomie. Acum, ca și în cazul taxonomiei Topics în sine, această abordare se va dezvolta în timp. Dar deducerea intereselor din activitatea de navigare trebuie să fie echilibrată.

Dacă aveți prea multe detalii despre navigarea corectă a utilizatorului, este rău pentru confidențialitate, dar prea puțină granularitate înseamnă că API-ul nu este util. Cred că, într-un fel, principalul lucru de înțeles aici este că subiectele de interes sunt doar un semnal pentru a găsi ceea ce este relevant pentru utilizatori.

Așa că acum, odată ce subiectele de interes au fost deduse de browser pentru un utilizator, Topics trebuie să ofere apelanților API acces la subiectele de interes pe care le-au observat pentru utilizator.

Deci, pe măsură ce utilizatorul navighează pe web, există două etape pentru API. Un apelant API, ar putea fi o platformă adtech, de exemplu, apelează API-ul pe o pagină pentru a semnala că dorește să observe subiecte pentru pagina curentă și utilizatorul actual.

Acum, mai târziu, apelantul API poate accesa subiectele pe care le-a observat pentru utilizator. Acum toate acestea trebuie făcute fără a dezvălui nimic mai mult despre activitatea de navigare a utilizatorului, în afară de subiectele de interes care au fost observate.

Deci API-ul Topics oferă două modalități de a observa subiectele de interes pentru un utilizator și apoi de a obține acces la acele subiecte care au fost observate, în primul rând cu un API JavaScript sau prin utilizarea antetelor de solicitare și răspuns la o solicitare de preluare.

Prima modalitate prin care un apelant API Topics poate semnala browserului că a observat subiecte pentru un utilizator este să apeleze document.browsingTopics dintr-un iframe încorporat pe site-urile pe care utilizatorul le vizitează.

Acum, mai târziu, apelantul API poate apela aceeași metodă document.browsingTopics pentru a accesa subiectele pe care le-a observat pentru utilizatorul curent. Și motivul pentru care această metodă are nevoie de un iframe apropo, este că contextul pentru observarea Topics trebuie să fie același cu contextul pentru accesarea Topics.

Cealaltă modalitate de a observa și de a accesa Topics este utilizarea antetelor de preluare, solicitare și răspuns. În primul rând, apelantul API trebuie să facă o solicitare de preluare la o adresă URL de la origine, inclusiv obiectul adevărat al subiectelor de navigare din parametrul opțiuni.

Și dacă răspunsul la cererea de preluare include un antet Observe-Browsing-Topics ?1, ei bine, acesta semnalează browserului că apelantul dorește ca browserul să înregistreze că apelantul a observat subiectele de interes pentru utilizatorul curent pentru curentul pagină. Sper că are sens.

Acum, subiectele observate pentru un utilizator pot fi preluate din cererea de preluare a apelantului accesând antetul cererii sec-browsing-topics. Deci, iată întregul proces de la început până la sfârșit. Sunt conștient de timp, așa că nu îl voi parcurge acum, dar îl vom împărtăși mai târziu, astfel încât să puteți vedea cum funcționează, întregul proces și îl vom avea pentru fiecare dintre API-uri.

Și puteți încerca demonstrația Topics care folosește metoda JavaScript iframe pentru a observa și accesa subiecte sau puteți încerca demonstrația noastră care folosește abordarea fetch request header. chrome://topics-internals afișează subiecte pentru utilizatorul curent, subiecte conferite pentru numele gazdelor și informații tehnice despre implementarea API-ului.

De asemenea, puteți rula laboratorul de subiecte pentru a testa inferența subiectelor folosind modelul de clasificare a subiectelor. Acum trei întrebări majore deschise pentru dvs. înainte de a părăsi Topics, cum am putea face o treabă mai bună de a deduce subiecte de interes pentru un utilizator pe baza activității sale de navigare? Cum putem îmbunătăți conținutul și structura taxonomiei pentru a-l face mai util, păstrând în același timp confidențialitatea utilizatorilor? Și cum putem îmbunătăți arhitectura generală a API-ului?

Cred că un lucru de avut în vedere aici este dacă avem subiecte sau ceva diferit, trebuie totuși să le îndeplinim cazurile de utilizare. În continuare, FLEDGE. Prin urmare, acesta este un API pentru opțiunile de anunțuri pe dispozitiv, pentru a difuza cazuri de utilizare pentru remarketing și public personalizat, fără a fi nevoie de urmărire pe mai multe site-uri terță parte.

Cred că acesta este un pic mai mult detaliu de cod cu FLEDGE, deoarece are o treabă mai complicată de făcut decât Topics. Deci, procesul FLEDGE are trei părți. În primul rând, cumpărătorul de anunțuri adaugă utilizatori sau mai degrabă browsere individuale la ceea ce se numesc grupuri de interese. Acestea sunt ca segmentele de public personalizate, dar apartenența la grupul de interese este stocată în browserul de pe dispozitivul utilizatorului.

Acum, la un moment dat, când un utilizator vizitează un site care afișează reclame, cum ar fi site-ul unui editor, un vânzător de anunțuri poate iniția o licitație publicitară pentru a selecta un anunț pentru el, iar cu FLEDGE această licitație poate fi desfășurată pe dispozitivul utilizatorului.

Pentru a selecta un anunț, codul de licitație rulează logica de licitare de la cumpărători și logica de licitație de la vânzător. Și, în sfârșit, browserul postează rapoarte de licitație către punctele finale furnizate de vânzători și cumpărători.

Așa că parcurg FLEDGE pas cu pas foarte pe scurt. În primul rând, imaginați-vă că un utilizator vizitează un magazin online de pantofi, navighează. O platformă adtech sau poate un agent de publicitate însuși face un apel JavaScript pentru a-i spune browserului să se alăture unui grup de interese. Și acest grup s-ar putea numi ceva de genul Trail Running Shoes.

Obiectul de configurare pentru un grup de interese ar putea arăta astfel. În acest exemplu, tehnologia publicitară a magazinului de pantofi ar putea avea un grup de interese pentru remarketing la care ar dori să adauge utilizatorul și l-a numit bine acest grup, Trail Running Shoes. Și platforma tehnologică a magazinului de pantofi apelează la alăturați grupului de interese publicitare pentru a cere browserului utilizatorului să se alăture grupului de interese Trail Running Shoes folosind configurația pe care tocmai v-am arătat-o.

Iar al doilea parametru specifică durata grupului de interese, care este plafonată la 30 de zile. Acum utilizatorul vizitează un site care publică reclame. În acest exemplu, un site de știri. O licitație pentru a selecta un anunț de afișat utilizatorului este desfășurată în JavaScript pe dispozitivul utilizatorului de către vânzător, folosind licitația rulată, iar vânzătorul este probabil o platformă de tehnologie publicitară, dar poate editorul însuși, în acest caz, site-ul de știri.

Acum, această licitație selectează cele mai potrivite oferte de anunț pentru fiecare dintre grupurile de interese din care aparține browserul utilizatorului, împreună cu alți factori de la vânzător și browserul însuși.

Acum privind codul, editorul sau o platformă care vinde spațiu publicitar pe site-ul editorului creează date de configurare pentru licitația publicitară. Vânzătorul cere apoi browserului să desfășoare o licitație publicitară pentru a selecta un anunț în browser, iar valoarea returnată de rularea licitației publicitare este transmisă unui element numit cadru îngrădit, astfel încât site-ul să poată afișa anunțul câștigător.

Acum un cadru îngrădit poate fi folosit pentru a afișa un anunț, dar acesta nu poate interacționa cu pagina din jurul acestuia. Și apoi vânzătorul și cumpărătorul câștigător au fiecare posibilitatea de a efectua înregistrare și raportare, iar asta se face apelând navigator.reportresult.

În cele din urmă, utilizatorul, dacă totul merge bine, atinge sau dă clic pe anunț și acum API-ul de raportare atribuire preia controlul. Și din nou, avem o diagramă care arată întregul proces de la început până la sfârșit, pe care o vom împărtăși cu voi după prezentarea.

Acum, în sfârșit, aș dori să vă spun puțin despre API-ul Privacy Sandbox pentru măsurarea anunțurilor, care este Raportarea atribuirii. Raportarea atribuirii este utilizată pentru a măsura când un clic pe anunț sau o afișare a unui anunț duce la o conversie. De exemplu, când vizualizarea unui anunț pe un site de știri duce la o achiziție de la un magazin online de pantofi.

Acum, ca și în cazul Topics și FLEDGE, acest API este conceput pentru a evita urmărirea pe mai multe site-uri. Deci, API-ul permite două tipuri de rezultate de măsurare, rapoarte la nivel de eveniment și rapoarte rezumative. Deci, permiteți-mi să descriu pe scurt cum funcționează.

Mai întâi, să aruncăm o privire la rapoartele la nivel de eveniment. Prin urmare, linkurile publicitare pot fi configurate cu atribute specifice API-ului de raportare a atribuirii, ceea ce face posibilă contorizarea vizionărilor și clicurilor cu o solicitare din partea conversiilor.

Acum, când un utilizator dă clic pe un anunț sau vede un anunț și apoi face o conversie, browserul generează un raport, iar în acel raport compania de publicitate sau tehnologia publicitară include două date. În primul rând, orice date pe care le doresc despre clicul sau afișarea pe anunț și acestea pot fi foarte detaliate, de exemplu, un ID de reclamă, informații despre editor, marcajul de timp și așa mai departe. Și în al doilea rând, o mică parte de date despre conversia anunțurilor.

Acum, pentru a proteja confidențialitatea utilizatorului, acest lucru nu poate fi prea detaliat. Mai târziu, browserul trimite acel raport despre– Ei bine, acel raport cu datele pe care tocmai le-am explicat tehnicianului publicitar sau agentului de publicitate și care include o întârziere pentru a evita urmărirea utilizatorilor.

Raportul conține două date, date detaliate despre clicul sau afișarea pe anunț, evenimentul și date la nivel înalt despre conversie. Deci acesta este un raport la nivel de eveniment. Acum să aruncăm o privire la rapoartele rezumative.

Acum API-ul browserului pentru a genera un raport rezumat este similar, dar rezultatele și mecanismul sunt puțin diferite. Deci, din nou, atunci când un utilizator dă clic pe un anunț sau vede un anunț și apoi face o conversie, browserul generează un raport, iar în acel raport compania de publicitate sau tehnologia publicitară poate include orice date pe care le dorește despre clicul sau afișarea pe anunț și orice date pe care le are. doriți despre conversia anunțului, dar acest raport este criptat.

Și aceasta este o protecție a confidențialității, deoarece acest raport conține date detaliate despre conversie și impresie. Deci, raportul ar putea fi folosit pentru urmărirea pe mai multe site-uri dacă nu a fost criptat. Apoi, mai târziu, browserul va trimite din nou acest raport criptat, cu o mică întârziere.

Și în acest fel, o platformă adtech va colecta multe rapoarte de la mulți utilizatori și apoi va trimite toate rapoartele unui serviciu de agregare așa cum este numit și acest serviciu va agrega toate aceste rapoarte, le va decripta, va adăuga puțin zgomot pentru a proteja confidențialitatea utilizatorului și apoi returnează rezultatul final, iar rezultatul final se numește raport de sinteză. Conține date de măsurare pentru mulți utilizatori.

Deci, aceasta este măsurarea atribuirii. Sper că are sens. Voi trimite link la multe mai multe resurse pentru a vă ajuta să înțelegeți și să testați API-urile Privacy Sandbox mai detaliat. Dar un ultim lucru pe care aș dori să-l menționez, Privacy Sandcastle.

Aceasta este o demonstrație care combină toate principalele API-uri de confidențialitate Sandbox. A fost construit de echipa noastră din Tokyo. Este încă foarte nou. Dar puteți obține codul de la GitHub și îl puteți rula local și este conceput pentru a vă ajuta să înțelegeți cum se potrivesc toate aceste API-uri.

Înainte să termin, îmi place să fac o recapitulare și să mă uit la cronologia pentru Privacy Sandbox. După cum puteți vedea, ne apropiem de trimestrul în care vom începe livrarea API-urilor, ceea ce înseamnă că vor fi disponibile implicit în Chrome Stable și gata pentru testare la scară de producție. Acum este doar o perioadă scurtă de timp în calendar și mă pot vedea. Sunt aproape de timp aici.

Deci câteva lucruri pe care cred că trebuie să le faci chiar acum. În primul rând, înțelegeți cronologia pentru web și Android. Asigurați-vă că dvs. și furnizorii dvs. terți sunteți pregătiți pentru schimbările care sunt acum iminente. În al doilea rând, auditați-vă site-urile pentru a înțelege unde se bazează pe cookie-uri terță parte și pe alte mecanisme care sunt depreciate. Vom împărtăși linkuri către instrumente și instrucțiuni despre cum să faceți asta după evenimentul de astăzi.

Apoi, întrebați furnizorii dvs. terți, cum ar fi platformele adtech și așa mai departe, cum se pregătesc să-și îndeplinească cazurile de utilizare de bază în absența cookie-urilor terță parte sau a altor mecanisme de urmărire pe mai multe site-uri și, în sfârșit, testați API-urile Privacy Sandbox și oferiți feedback și cereți furnizorilor dvs. terți să facă același lucru.

Și dacă nu sunt bine, întrebați-i de ce nu și spuneți-ne care este răspunsul la această întrebare. Prin urmare, privacysandbox.com oferă cronologie, întrebări frecvente, mai multe informații despre eforturile pe mai multe platforme. Voi distribui adrese URL după acest eveniment, dar puteți găsi o mare parte din conținutul la care m-am referit aici din secțiunea Privacy Sandbox de pe developer.chrome.com.

În special, acesta are resurse care explică cum să ne punem întrebări și cum să ne oferiți feedback și puteți afla mai multe despre încercările de origine pe developer.chrome.com. De asemenea, am creat o serie de videoclipuri și articole scurte pentru a explica conceptele Chrome, cum ar fi încercările de origine, semnalizatoarele Chrome, conținutul intermitent și toate acele lucruri.

Deci mulțumesc pentru ascultare. Asta e de la mine. După cum am spus, dacă aveți nevoie de asistență, vă rugăm să accesați acele resurse sau puteți pur și simplu să îmi trimiteți un mesaj direct SW12 pe Twitter. Multumesc mult.