Witamy w listopadowej edycji programu Postęp w Piaskownicy prywatności, w którym przedstawiamy etapy na drodze do wycofania z Chrome plików cookie innych firm i pracy nad zwiększaniem prywatności w internecie. Co miesiąc będziemy udostępniać omówienie aktualizacji osi czasu Piaskownicy prywatności oraz wiadomości z całego projektu. Opublikowaliśmy też aktualne informacje o naszych zobowiązaniach w zakresie Piaskownicy prywatności, ponieważ dbamy o to, aby propozycje były opracowywane, opracowywane i wdrażane z nadzorem regulacyjnym oraz na podstawie opinii brytyjskiego Urzędu ds. Konkurencji i Rynków (CMA) i biura komisarza ds. informacji (Information Commissioner's Office, ICO).
Wydarzenia
Na początku listopada zorganizowaliśmy wydarzenie Chrome Developer Summit, w ramach którego uwzględniliśmy segment Piaskownicy prywatności i kilka powiązanych pytań w ramach sesji Ask Me, o co chcesz. Dodaliśmy podsumowanie, które możesz przeczytać lub obejrzeć, w którym znajdziesz działania i przykłady tego, czego możesz się spodziewać w miarę postępów ofert pakietowych na fazach dyskusji, testowania i wdrażania na dużą skalę.
Wzmocnij granice prywatności między witrynami
Pliki cookie innych firm to kluczowy mechanizm, który umożliwia śledzenie w witrynach. Ich wycofanie to ważny krok milowy, ale musimy też zająć się innymi formami przechowywania danych i komunikacji między witrynami.
Interfejs API zarządzania danymi logowania sfederowanego
Federated Credentials Management (FedCM) to nowa, bardziej zrozumiała nazwa oferty pakietowej WebID. Ta zmiana została uwzględniona na osi czasu Piaskownicy prywatności. Tożsamość sfederowana to kluczowa usługa w internecie, ale ponieważ jest ona wykorzystywana do udostępniania różnych aspektów tożsamości w innych witrynach, szczegóły implementacji pokrywają się ze śledzeniem w wielu witrynach.
Propozycja dotycząca sfederowanego zarządzania danymi uwierzytelniającymi obejmuje szereg opcji: od prostych ścieżek migracji istniejących rozwiązań po bardziej prywatne metody łączenia się z usługami przy minimalnym udostępnianiu informacji.
W listopadzie odbyła się też organizowana 2 razy w roku konferencja BlinkOn. Blink to silnik renderowania używany przez Chromium, a BlinkOn to miejsce, w którym współtwórcy zbierają się, by przeprowadzać prezentacje techniczne i dyskutować o bieżących projektach. Listopadowe BlinkOn obejmował sesję pytań i odpowiedzi w FedCM – nagranie możesz obejrzeć w YouTube.
Zapobieganie ukrytemu śledzeniu
Ograniczamy opcje bezpośredniego śledzenia w witrynach, ale musimy też zająć się obszarami platformy internetowej, w których udostępniane są informacje umożliwiające identyfikację, co umożliwia pobieranie odcisków cyfrowych lub ukryte śledzenie użytkowników.
Redukcja ciągu znaków klienta użytkownika i wskazówki dotyczące klienta użytkownika
Stale zmniejszamy ilość informacji dostępnych domyślnie w ciągu znaków User-Agent w Chrome i udostępniamy ulepszoną, aktywną metodę żądania danych za pomocą wskazówek dotyczących klienta użytkownika. Dodaliśmy nowy omówienie zniżki na klienta użytkownika, w którym zebraliśmy wszystkie bieżące wskazówki i aktualizacje.
Opublikowaliśmy nowe materiały testowe, które pomogą Ci przygotować się do tych zmian. Fragmenty kodu redukującego klienta użytkownika to przykładowe przykłady przekształcenia bieżącego ciągu znaków klienta użytkownika w format zredukowanym. Dostępna jest też nowa pozycja chrome://flags/#force-major-version-to-100, za pomocą której możesz sprawdzić, czy zmiana na 3-cyfrową wersję główną nie powoduje awarii lub awarii Twojej witryny.
Opublikowaliśmy Intent to Ship for Sec-CH-UA-Full-Version-List. Dotyczy to opinii ekosystemu, że obecna wersja Sec-CH-UA-Full-Version była zbyt ściśle powiązana z główną marką przeglądarki, ponieważ zapewniała tylko jedną wartość. Na przykład obecna implementacja pokazuje np.:
⚠️ Nagłówek odpowiedzi serwera
Accept-CH: Sec-CH-UA-Full-Version
⬆️ Nagłówek żądania przeglądarki
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"
Sec-CH-UA-Full-Version: "94.0.4606.124"
Zaktualizowana wersja zawiera te informacje:
⚠️ Nagłówek odpowiedzi serwera
Accept-CH: Sec-CH-UA-Full-Version-List
⬆️ Nagłówek żądania przeglądarki
Sec-CH-UA: "Chromium";v="94", "Google Chrome";v="94", "Other browser";v="99"
Sec-CH-UA-Full-Version-List: "Chromium";v="94.0.4606.124", "Google Chrome";v="94.0.4606.124", "Other browser";v="99.88.77.66"
Niewidomość IP
Adresy IP ze względu na swój charakter często dostarczają unikalnemu identyfikatorowi klienta umożliwiającego niezbędną komunikację między przeglądarką a serwerem. Oznacza to jednak również, że stabilny adres IP w dłuższym okresie pasywnie dostarcza pasywnie dużo informacji, które można wykorzystać do śledzenia w witrynach.
Propozycja rozwiązania problemu nierozpoznawania adresów IP (nazywana też usługą Global Network Address Translation w połączeniu z kontrolowaną i zaufaną usługą CDN lub HTTP-Proxy Eliminification albo Gnatcatcher) opisuje dwuetapowe podejście do tego problemu. Pierwszym z nich jest Near-Path NAT, który skutecznie przekierowuje połączenie przeglądarki przez usługę prywatną adresu IP, która ukrywa adres IP przeglądarki przed odwiedzaną witryną. Druga opcja bazuje na warstwowym naturze internetu, w którym infrastruktura zależna od adresu IP może być całkowicie oddzielona od uruchomionej na nim aplikacji. Propozycja wolnego dostępu do IP omawia metody definiowania zasad podlegających kontroli na potrzeby tworzenia i utrzymywania takiego separacji.
Oba te pomysły znajdują się na wczesnym etapie dyskusji i trwają aktywne postępy w repozytorium, np. opublikowane niedawno zasady „Willful IP Blindness Policy” (Zasady dotyczące ślepoty na własność intelektualną). Dalsza część dyskusji w tej sekcji będzie kontynuowana. Jeśli interesują Cię szczegóły na poziomie sieci, zapoznaj się z artykułem Multiplexed Application Substrate over QUIC Encryption (MASQUE) (grupa robocza w IETF).
Pomiar skuteczności reklam cyfrowych
Jako uzupełnienie wyświetlania reklam bez śledzenia w witrynach potrzebujemy mechanizmów chroniących prywatność, które umożliwiłyby pomiar skuteczności reklam.
Interfejs Attribution Reporting API
Interfejs Attribution Reporting API tworzy funkcje mierzenia zdarzeń w jednej witrynie, takich jak kliknięcie lub wyświetlenie reklamy, które prowadzą do konwersji w innej witrynie bez włączania śledzenia w wielu witrynach.
Wciąż testujemy ten interfejs API, a okres próbny origin został przedłużony na Chrome 97. Bieżące tokeny próbne origin wygasły 12 października. Aby kontynuować testowanie, obecni testerzy muszą złożyć wniosek o zaktualizowane tokeny.
Na blogu znajdziesz dwa nowe posty z najnowszymi informacjami o raportach na poziomie zdarzenia w interfejsie API. Raporty na poziomie zdarzenia w interfejsie Attribution Reporting API przedstawiają pojęcia i procesy, a korzystanie z raportów na poziomie zdarzenia w interfejsie Attribution Reporting API przedstawia szczegóły wdrożenia wraz z towarzyszącym im kodem demonstracyjnym i demonstracyjnym.
Prześlij opinię
Nadal publikujemy te comiesięczne aktualizacje i postępujemy w ramach Piaskownicy prywatności. Chcemy mieć pewność, że deweloperzy otrzymują potrzebne informacje i pomoc. Jeśli zauważysz, że możemy coś ulepszyć w tej serii, daj nam znać na @ChromiumDev. Wykorzystamy te informacje do dalszego ulepszania formatu.
Zapoznaj się z najczęstszymi pytaniami dotyczącymi Piaskownicy prywatności, które stale rozwijamy w zależności od problemów zgłoszonych przez Ciebie do repozytorium pomocy dla deweloperów. Jeśli macie jakieś pytania dotyczące testowania lub wdrażania dowolnej z tych propozycji, proszę o kontakt.