Inne firmy

Co to jest firma zewnętrzna?

Bardzo rzadko zdarza się, że witryna jest całkowicie samodzielna. Według almanaku internetowego HTTP większość witryn – około 95% – zawiera treści należące do osób trzecich.

W almanaku definiuje się treści należące do innych podmiotów jako materiały hostowane w wspólnym i publicznym źródle, które są powszechnie używane przez różne witryny i nie mają na nie wpływu poszczególnych właścicieli witryn. Mogą to być obrazy lub inne multimedia, takie jak filmy, czcionki lub skrypty. Obrazy i skrypty to nie wszystko. Treści osób trzecich nie są niezbędne do tworzenia witryn, ale równie dobrze mogą być. Prawie na pewno używasz plików wczytywanych z publicznego serwera współdzielonego, np. czcionek internetowych, osadzonych elementów iframe z filmami, reklam czy bibliotek JavaScript. Możesz na przykład korzystać z czcionek internetowych dostarczanych z Google Fonts lub mierzyć statystyki w Google Analytics, dodać przyciski „Podoba mi się” lub „Zaloguj się przez” z sieci społecznościowych, umieszczać mapy lub filmy albo obsługiwać zakupy za pomocą usług firm zewnętrznych; śledzić błędy i rejestrować własne zespoły programistów przy użyciu zewnętrznych narzędzi monitorujących.

Ze względu na ochronę prywatności można użyć nieco innej i mniej ogólnej definicji: zasób zewnętrzny, a w szczególności skrypt zewnętrzny, jest udostępniany ze wspólnego i publicznego źródła, powszechnie używany (jak w przykładzie), ale został też utworzony przez kogoś innego niż właściciel witryny. Jeśli chodzi o ochronę prywatności użytkowników przed innymi użytkownikami, należy pamiętać, że autorstwo zewnętrzne jest kluczowe. W ten sposób przeanalizujesz możliwe zagrożenia, a następnie zdecydujesz, jak i na ich podstawie zdecydować, czy i w jaki sposób skorzystać z zasobów innych firm. Jak już wspomnieliśmy, te informacje pomogą Ci zrozumieć kontekst i zrozumieć, jakie kompromisy musisz podjąć i co oznaczają.

Nie o to chodzi w ogóle, gdy mówimy o „zasobach zewnętrznych”: różnica między zasobami własnymi a zewnętrznymi w rzeczywistości chodzi przede wszystkim o kontekst, w którym coś jest używane. Skrypt wczytywany z innej witryny jest zasobem firmy zewnętrznej. Żądanie HTTP, które je wczytuje, może zawierać pliki cookie, ale tak naprawdę nie są to „pliki cookie innych firm”. Są to tylko pliki cookie innych firm i to, czy są one „zewnętrznych” czy „własnych”, zależy od tego, czy skrypt jest wczytywany na stronie w Twojej witrynie czy na stronie właściciela skryptu.

Dlaczego wykorzystujemy zasoby innych firm?

Firmy zewnętrzne to doskonały sposób na dodanie funkcji do witryny. Mogą to być funkcje dostępne dla użytkowników lub niewidoczne funkcje deweloperskie (np. śledzenie błędów), ale zmniejszają one obciążenie programistyczne, a skrypty są obsługiwane przez inną osobę – zespół programistów usługi, z której korzystasz. Wszystko to działa dzięki kompozycjach sieci: możliwości łączenia różnych elementów w całość, która przewyższa ich sumę.

Web Almanac w archiwum HTTP zawiera przydatny opis:

Firmy zewnętrzne zapewniają Ci niekończącą się kolekcję obrazów, filmów, czcionek, narzędzi, bibliotek, widżetów, narzędzi do śledzenia, reklam i innych dowolnych materiałów osadzonych na naszych stronach internetowych. Dzięki temu nawet najbardziej niezawodni technicy mogą tworzyć i publikować treści w internecie. Bez firm zewnętrznych sieć byłaby raczej nudna, oparta na tekście, akademicka, a nie bogata, wciągająca i złożona, niezbędna do współczesności wielu z nas.

Co mogą zrobić zasoby innych firm?

Uzyskiwanie dostępu do niektórych informacji

Gdy w swojej witrynie korzystasz z zasobów firmy zewnętrznej, niektóre informacje są do niej przekazywane. Jeśli na przykład dołączysz obraz z innej witryny, przeglądarka użytkownika w ramach żądania HTTP przekazuje nagłówek strony odsyłającej z adresem URL Twojej strony, a także z adresem IP użytkownika.

Śledzenie w witrynach

Nawiązując do tego samego przykładu – gdy obraz wczytuje się z witryny zewnętrznej, może on zawierać plik cookie, który jest wysyłany z powrotem do firmy zewnętrznej, gdy użytkownik następnym razem o nią poprosi. Oznacza to, że dana firma może wiedzieć, że korzystasz z jej usługi w Twojej witrynie, i może odesłać plik cookie, potencjalnie zawierający unikalny identyfikator tego użytkownika. Oznacza to, że gdy następnym razem użytkownik odwiedzi Twoją witrynę lub inną witrynę, która zawiera zasób takiej firmy, plik cookie z unikalnym identyfikatorem zostanie wysłany ponownie. Dzięki temu można utworzyć dziennik miejsc w sieci, w których użytkownicy odwiedzają witryny – Twoje witryny i inne witryny korzystające z tych samych zasobów zewnętrznych.

To śledzenie w witrynach: firma zewnętrzna może rejestrować aktywność użytkownika w wielu witrynach, o ile korzystają one z zasobów tego samego dostawcy. Może to być czcionka, obraz lub arkusz stylów – wszystkie zasoby statyczne. Może to też być zasób dynamiczny: skrypt, przycisk mediów społecznościowych, reklama. Dołączony skrypt może zebrać jeszcze więcej informacji, ponieważ jest dynamiczny: może badać przeglądarkę i środowisko użytkownika oraz przekazywać dane z powrotem do źródła. W pewnym stopniu jest to możliwe w przypadku każdego skryptu, podobnie jak w przypadku zasobów dynamicznych, których nie ma w formie skryptu, np. umieszczania filmu w mediach społecznościowych, reklamy lub przycisku udostępniania. Jeśli spojrzysz na szczegóły banera z plikami cookie w popularnych witrynach, możesz zobaczyć listę organizacji, które mogą dodać do Twoich użytkowników plik cookie śledzenia, aby stworzyć obraz ich działań i utworzyć profil tego użytkownika. Mogą być ich setki. Jeśli firma zewnętrzna oferuje usługę bezpłatnie, jednym z ekonomicznych sposobów może być dla niej gromadzenie danych, a następnie zarabianie na nich.

Przydatnym przewodnikiem dotyczącym rodzajów problemów z prywatnością, przed którymi przeglądarka powinna chronić swoich użytkowników, jest model zagrożeń związanych z prywatnością. W chwili jego pisania dokument jest nadal przedmiotem dyskusji, ale zawiera ogólne klasyfikacje istniejących zagrożeń dotyczących prywatności. Zagrożenie ze strony zasobów zewnętrznych to przede wszystkim „niechciane rozpoznawanie użytkowników w różnych witrynach”, które polegają na tym, że witryna może zidentyfikować tego samego użytkownika w wielu witrynach, oraz „ujawnianie informacji poufnych”, gdy witryna może zbierać informacje uznane przez użytkownika za poufne.

To najważniejsza różnica: niechciane rozpoznawanie w różnych witrynach jest niewłaściwe, nawet jeśli firma zewnętrzna nie gromadzi z niego dodatkowych informacji poufnych, ponieważ odbiera użytkownikowi kontrolę nad jego tożsamością. Dostęp do strony odsyłającej i adresu IP użytkownika oraz plików cookie jest niechcianą wiadomością samo w sobie. Korzystanie z zasobów innych firm wiąże się z planowaniem sposobu ich wykorzystania w sposób zapewniający ochronę prywatności. Niektóre z tych zadań musisz wykonać jako deweloper witryny, a inne – w roli przeglądarki, w ramach klienta użytkownika. Oznacza to, że w miarę możliwości zapobiega ujawnieniu informacji poufnych i uniknięciu niechcianego rozpoznawania w innych witrynach. Poniżej podajemy bardziej szczegółowe informacje na temat środków łagodzących i sposobów działania podejmowanych na poziomie przeglądarki i na poziomie rozwoju witryny.

Kod zewnętrzny po stronie serwera

Nasza wcześniejsza definicja firmy zewnętrznej celowo zmieniała podejście po stronie klienta w alercie HTTP (zgodnie z oczekiwaniami w raporcie), tak aby uwzględniały informacje o autorach innych firm, ponieważ z punktu widzenia prywatności firma zewnętrzna to każda osoba, która wie coś o Twoich użytkownikach, a nie Twoją.

Dotyczy to także firm zewnętrznych, które świadczą usługi używane na serwerze i przez klienta. Z punktu widzenia prywatności ważne jest też, by rozumieć, jak działają biblioteka zewnętrzna (np. z NPM, Composer lub NuGet). Czy Twoje zależności przekazują dane poza granicami Twojego kraju? Jeśli przekazujesz dane do usługi logowania lub do hostowanej zdalnie bazy danych, a biblioteki dodają też „telefon domowy” do ich autorów, mogą one naruszać prywatność użytkowników i wymagać audytu. Dane użytkownika zwykle musisz przekazać firmie zewnętrznej, która ma je obsługiwać, co oznacza, że masz większą kontrolę nad tymi danymi. Z kolei firma zewnętrzna oparta na kliencie, czyli skrypt lub zasób HTTP znajdujący się w Twojej witrynie i pobierany przez przeglądarkę użytkownika, może gromadzić część danych bezpośrednio od użytkownika. Nie musisz zapośredniczać w nich procesu gromadzenia tych danych. W większości tego modułu dowiesz się, jak zidentyfikować firmy zewnętrzne po stronie klienta, które zdecydowałeś się uwzględnić i udostępniać swoim użytkownikom. Dokładnie to dlatego, że Twoje możliwości mediacji są mniejsze. Warto jednak zabezpieczyć kod po stronie serwera, aby rozumieć przekazywane przez niego informacje wychodzące i rejestrować oraz blokować wszelkie nieoczekiwane zdarzenia. Szczegółowe informacje o tym, jak to zrobić, wykraczają poza nasze możliwości (i zależą od konfiguracji serwera), ale jest to kolejna część Państwa stanowiska w zakresie bezpieczeństwa i prywatności.

Dlaczego należy zachować ostrożność w przypadku firm zewnętrznych?

Skrypty i funkcje innych firm są bardzo ważne, a naszym celem jako programista stron internetowych powinno być zintegrowanie takich elementów, a nie odsuwanie się od nich. Istnieją jednak potencjalne problemy. Treści osób trzecich mogą powodować problemy z wydajnością i bezpieczeństwem, ponieważ udostępniasz usługę zewnętrzną w swoich granicach zaufania. Jednak treści osób trzecich także mogą powodować problemy z prywatnością.

Gdy mówimy o zasobach innych firm w internecie, warto zastanowić się, czy problemy z bezpieczeństwem to m.in. sytuacje, w których osoba trzecia może wykraść dane z Twojej firmy, natomiast w odniesieniu do kwestii prywatności, czyli między innymi przypadków, gdy uwzględniona przez Ciebie firma wykrada dane użytkowników lub uzyskuje do nich dostęp bez Twojej zgody.

Przykładem problemu z bezpieczeństwem jest kradzież danych karty kredytowej – niezależny zasób umieszczony na stronie, na której użytkownik wpisuje dane karty kredytowej, a potem może wykraść te dane i przesłać je do innego podmiotu. Osoby, które tworzą skrypty skimmera, potrafią bardzo kreatywnie znaleźć miejsca, w których można je ukryć. Podsumowanie opisuje, w jaki sposób skrypty skimmera zostały ukryte w treściach zewnętrznych, np. obrazach użytych w logo witryn, favikonach i sieciach społecznościowych, popularne biblioteki (np. jQuery, Modernizr i Menedżer tagów Google), widżety witryn (np. okna czatu na żywo) oraz pliki CSS.

Kwestie dotyczące prywatności są trochę inne. Firmy zewnętrzne wchodzą w skład Twojej oferty. Aby utrzymać zaufanie użytkowników, musisz mieć pewność, że mogą im zaufać. Jeśli używana przez Ciebie firma zewnętrzna zbierze dane o Twoich użytkownikach, a potem wykorzysta je w niewłaściwy sposób, utrudnia ich usunięcie lub wykrycie, naruszy bezpieczeństwo danych lub naruszy oczekiwania użytkowników, użytkownicy prawdopodobnie odczują to jako spadek zaufania do Twojej usługi, a nie tylko do firmy zewnętrznej. To Twoja reputacja i relacje z Tobą. Dlatego warto zadać sobie pytanie: czy ufasz firmom zewnętrznym, z których korzystasz w swojej witrynie?

Jakie są przykłady firm zewnętrznych?

Mówimy ogólnie o „firmach zewnętrznych”, ale tak naprawdę istnieją różne rodzaje danych użytkowników i mają one dostęp do różnych ilości danych użytkowników. Na przykład dodanie do kodu HTML elementu <img> wczytanego z innego serwera zapewni temu serwerowi inne informacje o użytkownikach niż dodanie elementu <iframe> lub elementu <script>. Są to tylko przykłady, a nie wyczerpująca lista, ale pomagają zrozumieć różnice między różnymi typami elementów zewnętrznych, które możesz stosować w swojej witrynie.

Wysyłanie prośby o zasób z innej witryny

Zasób z innej witryny to dowolny element w Twojej witrynie, który został wczytany z innej witryny i nie jest typu <iframe> ani <script>. Przykłady to m.in. <img>, <audio>, <video>, czcionki internetowe wczytywane przez CSS oraz tekstury WebGL. Są one wczytywane przez żądanie HTTP i jak opisano wcześniej, takie żądania obejmują wszelkie pliki cookie ustawione wcześniej przez drugą witrynę, adres IP użytkownika wysyłającego żądanie oraz adres URL bieżącej strony jako strony odsyłającej. Wszystkie żądania innych firm domyślnie zawierały te dane. Staramy się jednak ograniczyć lub wyizolować dane przekazywane osobom trzecim przez różne przeglądarki zgodnie z opisem w dalszej części tego artykułu.

Umieszczanie elementu iframe z innej witryny

Kompletny dokument umieszczony na stronach za pomocą obiektu <iframe> może prosić o dodatkowy dostęp do interfejsów API przeglądarki oprócz trifekcji plików cookie, adresu IP i strony odsyłającej. Dokładne informacje o tym, które interfejsy API są dostępne dla stron <iframe> i jak żądają dostępu, zależą od przeglądarki i aktualnie podlegają zmianom. W sekcji „Zasady dotyczące uprawnień” poniżej znajdziesz bieżące działania mające na celu ograniczenie lub monitorowanie dostępu do interfejsu API w osadzonych dokumentach.

Wykonywanie kodu JavaScript w innej witrynie

Jeśli uwzględnisz element <script>, wczytuje się i uruchamia kod JavaScript z innych witryn w kontekście najwyższego poziomu strony. Oznacza to, że uruchamiany skrypt ma pełny dostęp do wszystkich działań wykonywanych przez własne skrypty. W dalszym ciągu tymi danymi zarządzają uprawnienia przeglądarki, więc żądanie lokalizacji użytkownika (na przykład) nadal wymaga zgody użytkownika. Jednak wszelkie informacje znajdujące się na stronie lub dostępne w postaci zmiennych JavaScriptu mogą zostać odczytane za pomocą takiego skryptu. Obejmuje to nie tylko pliki cookie przekazywane do firmy zewnętrznej w ramach żądania, ale także pliki cookie przeznaczone wyłącznie dla Twojej witryny. Również zewnętrzny skrypt ładowany na Twojej stronie może wykonywać wszystkie te same żądania HTTP co Twój kod, co oznacza, że może on wysyłać żądania fetch() do interfejsów API backendu, aby uzyskać dane.

Uwzględnianie bibliotek innych firm w zależnościach

Jak pisaliśmy wcześniej, kod po stronie serwera prawdopodobnie będzie zawierał zależności od innych firm, których nie da się odróżnić od Twojego własnego kodu. Kod dołączany z repozytorium GitHuba lub biblioteki języka programowania (npm, PyPI, composer itp.) może odczytywać te same dane, co inny kod.

Informacje o firmach zewnętrznych

W związku z tym musisz znać listę dostawców zewnętrznych, a także zasady ochrony prywatności, zbierania danych i wrażeń użytkowników. To zjawisko staje się częścią serii kompromisów, czyli tego, jak przydatna i ważna jest usługa w porównaniu z tym, jak natrętna, niewygodna lub niepokojąca jest ich potrzeba. Treści osób trzecich są wartościowe, bo Ty, jako właściciel witryny, bierzesz na siebie najcięższą pracę i możesz skupić się na swoich podstawowych kompetencjach. Warto więc poświęcać ten kompromis, poświęcając użytkownikom komfort i prywatność w trosce o większą wygodę użytkowników. Nie należy mylić wrażeń użytkowników z pracą deweloperów: „łatwiej jest stworzyć usługę dla naszego zespołu programistów” nie jest dla nich atrakcyjna.

Właśnie tak rozumiemy proces kontroli.

Kontrola firmy zewnętrznej

Zrozumienie działania firmy zewnętrznej polega na kontroli. Możesz to zrobić zarówno w przypadku konkretnej osoby, jak i całej swojej kolekcji, zarówno pod względem technicznym, jak i nietechnicznym.

Przeprowadzanie audytu bez wiedzy technicznej

Pierwszy krok nie ma odpowiedniej wiedzy technicznej: zapoznaj się z polityką prywatności dostawców. Jeśli umieszczasz w pliku materiały pochodzące od innych firm, zapoznaj się z jego polityką prywatności. Będą one długie i pełne tekstu prawnego. Niektóre dokumenty mogą wykorzystywać metody, w przypadku których zastosowaliśmy ostrzeżenia we wcześniejszych modułach, takie jak stwierdzenia zbyt ogólne, oraz bez informacji o tym, jak i kiedy zgromadzone dane zostaną usunięte. Pamiętaj, że z perspektywy użytkownika wszystkie dane gromadzone w Twojej witrynie, w tym przez osoby trzecie, podlegają tej polityce prywatności. Nawet jeśli robisz wszystko prawidłowo, ale jasno informujesz użytkowników o swoich celach i przekraczasz oczekiwania użytkowników w zakresie prywatności i wrażliwości danych, użytkownicy mogą pociągać Cię do odpowiedzialności za wszystko, co robią wybrane przez Ciebie firmy zewnętrzne. Jeśli polityka prywatności zawiera coś, czego nie chcesz wspomnieć w swoich zasadach, ponieważ mogłoby to spowodować zmniejszenie zaufania użytkowników, zastanów się, czy istnieje alternatywny dostawca.

Warto to sprostać w parze z omawianym dalej audytem technicznym, ponieważ przekazuje ono informacje między sobą. Musisz znać zasoby firm zewnętrznych, które wykorzystujesz do celów biznesowych (np. w sieciach reklamowych lub w treściach umieszczonych na stronach), ponieważ będzie to relacja biznesowa. To dobre miejsce na rozpoczęcie audytu nietechnicznego. Audyt techniczny pozwala też zidentyfikować firmy zewnętrzne, zwłaszcza te uwzględnione z powodów technicznych, a nie biznesowych (komponenty zewnętrzne, narzędzia analityczne, biblioteki narzędziowe), które mogą dołączyć do listy firm zewnętrznych. Jako właściciel witryny musisz mieć pewność, że rozumiesz, co robią osoby trzecie, które do niej dodajesz, i że możesz zaprezentować swojemu doradcy prawnemu te zasoby, aby mieć pewność, że spełniasz wszelkie wymagane zobowiązania.

Przeprowadzenie kontroli technicznej

W przypadku audytu technicznego zasoby w witrynie powinny być wykorzystywane jako część witryny. Oznacza to, że nie ładuj zależności w jednej testowej i nie przeprowadzaj kontroli w ten sposób. Sprawdź, jak zależności funkcjonują w rzeczywistej części witryny, wdrażane w publicznym internecie, a nie w trybie testowym lub deweloperskim. postrzeganie swojej witryny jako nowego użytkownika jest bardzo pomocne. Otwórz przeglądarkę w nowym profilu, wylogowując się z niego i nie masz zapisanych umów, a następnie spróbuj odwiedzić swoją witrynę.

zarejestrować nowe konto we własnej witrynie, jeśli podasz informacje o kontach użytkowników; Twój zespół projektantów zarządził proces pozyskiwania nowych użytkowników z perspektywy UX, ale ilustrację tego można potraktować z perspektywy ochrony prywatności. Nie wystarczy kliknąć „Zaakceptuj” na warunkach, ostrzeżenia o plikach cookie lub polityce prywatności. Zdecyduj, czy możesz korzystać z własnej usługi bez ujawniania danych osobowych ani posiadania plików cookie służących do śledzenia, a następnie sprawdź, czy możesz to zrobić i jak trudne jest to zadanie. Możesz też zajrzeć do narzędzi dla programistów w przeglądarkach, aby sprawdzić, które witryny są do nich udostępniane i jakie dane są do nich przekazywane. Narzędzia dla programistów zawierają listę osobnych żądań HTTP (zwykle w sekcji „Sieć”), z której można wyświetlić żądania pogrupowane według typu (HTML, CSS, obrazy, czcionki, JavaScript, żądania zainicjowane przez JavaScript). Możesz też dodać nową kolumnę, w której będzie podana domena każdego zgłoszenia i wskazać liczbę różnych miejsc, z którymi nawiązano kontakt. Może też być widoczne pole wyboru „Żądania osób trzecich”, które będzie wskazywać tylko osoby trzecie. (Pomocne może być również korzystanie z raportów Content-Security-Policy, które pozwalają przeprowadzać ciągły audyt, który można dokładniej poznać).

Przydatnym omówieniem wszystkich żądań podrzędnych, które zgłaszają publicznie dostępne strony, może być też narzędzie „Request Generator” (Generator map) udostępniane przez Simona Hearne'a.

Na tym etapie możesz też uwzględnić firmy zewnętrzne zidentyfikowane jako część audytu nietechnicznego (czyli listę firm, z którymi utrzymujesz relacje finansowe, aby korzystać z ich zasobów). Celem jest dopasowanie listy firm zewnętrznych, z których według Ciebie korzystasz (w dokumentach finansowych i prawnych), do listy, z której faktycznie korzystasz (sprawdzanie, jakie zewnętrzne żądania HTTP wysyła Twoja witryna). Musisz być w stanie określić dla każdej firmy zewnętrznej, które żądania techniczne są wysyłane w przypadku każdej firmy. Jeśli podczas audytu technicznego nie udało Ci się zidentyfikować żądań dotyczących firmy zewnętrznej w związku z relacjami biznesowymi, zastanów się, dlaczego tak jest, i przygotuj te wskazówki na testy: być może dane zasoby zewnętrzne są ładowane tylko w konkretnym kraju lub na określonym typie urządzenia albo dla zalogowanych użytkowników. Spowoduje to powiększenie listy obszarów witryn w celu sprawdzenia i upewnienia się, że widzisz wszystkie wejścia wychodzące. Możliwe też, że zidentyfikuje on zewnętrzne zasoby, za które płacisz, a za które nie używasz, co zawsze pozytywnie wpływa na dział finansowy.

Po zawężeniu listy żądań kierowanych do firm zewnętrznych, które chcesz objąć audytem, kliknięcie konkretnego żądania spowoduje wyświetlenie wszystkich szczegółów, a w szczególności danych przekazanych do tego żądania. Bardzo często zainicjowane przez Twój kod żądanie zewnętrznego źródła reklam jest kontynuowane i w efekcie przesyła kolejne żądania. Informacje te są również „importowane” do Twojej polityki prywatności. To zadanie jest pracochłonne, ale cenne i często można je wstawić do istniejących analiz. Twój zespół programistyczny frontendu powinien już sprawdzać żądania pod kątem wydajności (być może za pomocą istniejących narzędzi, takich jak WebPageTest lub Lighthouse), a wdrożenie w tym procesie kontroli danych i prywatności może to ułatwić.

Mapa żądań web.dev.
Bardzo uproszczona mapa żądania dostępu do web.dev przedstawiająca witryny zewnętrzne, które wysyłają żądania innych stron, itd.

Tak

Otwórz przeglądarkę z czystym nowym profilem użytkownika, tak aby nie być zalogowanym i nie będziesz mieć zapisanej umowy. Następnie otwórz panel Network (Sieć) w narzędziach dla programistów do przeglądarki. Dodaj nową kolumnę, aby wyświetlać domenę każdego żądania, i zaznacz pole wyboru „Żądania innych firm”, aby wyświetlić tylko domeny firm zewnętrznych, jeśli jest dostępne. To:

  • Odwiedź swoją witrynę.
  • Zarejestruj nowe konto, jeśli podasz informacje o kontach użytkowników.
  • Spróbuj usunąć utworzone konto.
  • Wykonaj normalne czynności (lub dwa) w witrynie (co dokładnie będzie zależało od tego, co robisz w witrynie, ale wybierz typowe czynności wykonywane przez większość użytkowników).
  • Wykonanie czynności, o której wiesz, że dotyczą w szczególności zależności od firm zewnętrznych. Może to obejmować udostępnianie treści w mediach społecznościowych, rozpoczynanie procesu płatności lub umieszczanie treści z innej witryny.

Podczas wykonywania każdego z tych zadań utwórz rejestr zasobów żądane z domen, które nie należą do Ciebie, w panelu Network (Sieć) zgodnie z opisem. To niektóre firmy zewnętrzne. Dobrym sposobem jest użycie narzędzi sieciowych przeglądarki do przechwytywania dzienników żądań sieciowych w pliku HAR.

Pliki HAR i przechwytywanie

Plik HAR to standardowy format JSON wszystkich żądań sieciowych wysyłanych przez stronę. Aby uzyskać plik HAR dla określonej strony, otwórz plik:

Chrome

Otwórz w przeglądarce Narzędzia deweloperskie (Menu > Więcej narzędzi > Narzędzia dla deweloperów), przejdź do panelu Network (Sieć), wczytaj (lub odśwież) stronę i w prawym górnym rogu obok menu Bez ograniczania kliknij symbol strzałki w dół.

Panel sieci w Narzędziach deweloperskich w Chrome z wyróżnionym symbolem Pobierz plik HAR.
Firefox

Otwórz narzędzia dla programistów w przeglądarce (Menu > Więcej narzędzi > Narzędzia dla programistów stron internetowych), przejdź do panelu Sieć, wczytaj (lub odśwież) stronę i w prawym górnym rogu obok menu ograniczania wybierz symbol koła zębatego. W menu wybierz Save All As HAR (Zapisz wszystko jako HAR)**.

Panel sieci narzędzi dla programistów w przeglądarce Firefox z wyróżnioną opcją Zapisz wszystko jako.
Safari

Otwórz narzędzia dla programistów w przeglądarce (Menu > Programowanie > Pokaż inspektora sieci). Jeśli nie widzisz menu Programowanie, włącz je, klikając Menu > Safari > Preferencje > Zaawansowane > Pokaż menu Programowanie na pasku menu), otwórz panel Sieć, wczytaj (lub odśwież) stronę i w prawym górnym rogu (po prawej stronie opcji Zachowaj dziennik) wybierz Eksportuj (po prawej stronie opcji Zachowaj dziennik).

Panel sieci w Inspektorze sieci Safari z wyróżnioną opcją eksportu HAR.

Aby uzyskać bardziej szczegółowe informacje, możesz też rejestrować dane przekazywane osobom trzecim (w sekcji Żądanie), chociaż dane te są często zaciemnione i trudne do zinterpretowania.

Sprawdzone metody integracji usług zewnętrznych

Możesz ustalić własne zasady dotyczące tego, z których firm zewnętrznych korzysta Twoja witryna: możesz wybrać, którego dostawcy reklam używasz na podstawie ich praktyk, określić, jak denerwujące lub natrętne jest wyskakujące okienko z prośbą o zgodę na stosowanie plików cookie, czy używać w witrynie przycisków mediów społecznościowych, linków śledzenia w e-mailach lub linków utm_campaign w tweetach, aby śledzić je w Google Analytics. Jednym z aspektów, które należy wziąć pod uwagę podczas tworzenia witryny, jest ochrona prywatności i bezpieczeństwo w usłudze analitycznej. Niektóre usługi analityczne wyraźnie oznaczają ochronę prywatności. Często istnieją też sposoby korzystania ze skryptu innej firmy, który sam w sobie dodaje ochronę prywatności: nie jesteś pierwszą osobą z zespołu, która dba o ochronę prywatności użytkowników i ochronę ich przed gromadzeniem danych przez osoby trzecie. Możliwe, że już istnieją odpowiednie rozwiązania. Obecnie wielu dostawców zewnętrznych jest bardziej wyczulonych na problemy związane ze zbieraniem danych. Często można dodać funkcje lub parametry, które zapewniają bardziej bezpieczny tryb ochrony użytkowników. Oto kilka przykładów.

Podczas dodawania przycisku udostępniania w mediach społecznościowych

Rozważ umieszczenie przycisków HTML bezpośrednio: na stronie https://sharingbuttons.io/ znajdziesz kilka dobrze zaprojektowanych przykładów. Możesz też dodać zwykłe linki HTML. W efekcie tracisz dane o liczbie akcji i możliwość klasyfikowania klientów w statystykach Facebooka. Jest to przykład kompromisu między korzystaniem z usług zewnętrznego dostawcy a otrzymywaniem mniejszej ilości danych analitycznych.

Ogólnie rzecz biorąc, gdy umieszczasz jakiś interaktywny widżet innej firmy, często zamiast tego możesz podać link do tej strony. Oznacza to, że witryna nie jest wyposażona w wbudowany interfejs, ale zmienia decyzję o udostępnieniu danych firmie zewnętrznej na użytkownika, który może decydować o tym, czy chce wejść w interakcję z reklamą.

Możesz na przykład dodać linki do Twittera i Facebooka, aby udostępniać swoją usługę pod adresem mojawitryna.example.com w następujący sposób:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Pamiętaj, że Facebook umożliwia określenie URL-a do udostępnienia, a Twitter – URL i jakiś tekst.

Podczas umieszczania filmu na stronie

Umieszczając filmy z witryn przechowywanych na serwerze wideo, rozejrzyj się za opcjami chroniącymi prywatność w kodzie. Na przykład w przypadku YouTube zastąp youtube.com w adresie URL do umieszczenia na stronie www.youtube-nocookie.com, aby uniknąć umieszczania plików cookie śledzenia na stronach, na których jest wyświetlana. Opcję „Włącz rozszerzony tryb prywatności” możesz też zaznaczyć podczas generowania linku Udostępnij/umieść w YouTube. To przykład zastosowania bardziej restrykcyjnego trybu ochrony użytkownika, który został udostępniony przez inną firmę. (więcej informacji na ten temat znajdziesz na stronie https://support.google.com/youtube/answer/171780, a także o innych opcjach umieszczania dotyczących YouTube).

Inne witryny z filmami mają mniej możliwości w tym zakresie: na przykład TikTok nie pozwala na umieszczanie filmów bez śledzenia w momencie tworzenia tego tekstu. Można hostować filmy samodzielnie (jest to metoda alternatywna), ale wymaga to znacznie nakładu pracy, zwłaszcza w przypadku obsługi wielu urządzeń.

Jak już wspomnieliśmy interaktywne widżety, często można zastąpić umieszczony film linkiem do odpowiedniej strony. Jest to mniej interaktywne, ponieważ film nie jest odtwarzany w tekście, ale pozostawia możliwość wyboru, czy obejrzeć go razem z użytkownikiem. Możesz jej użyć jako przykładu „wzorca wzorca” – nazwy do dynamicznego zastępowania treści interaktywnych czymś, co wymaga działania użytkownika do jej wywołania. Umieszczony na TikToku film można zastąpić zwykłym linkiem do strony z filmem na TikToku. Trzeba jednak wykonać trochę pracy, aby pobrać miniaturę filmu i wyświetlić ją jako link. Nawet jeśli wybrany dostawca filmów nie obsługuje łatwego sposobu umieszczania filmów bez śledzenia, wiele dostawców wideo obsługuje interfejs oEmbed. Jest to interfejs API, który po podaniu linku do filmu lub umieszczonej treści zwraca jego zautomatyzowane szczegóły, w tym miniaturę i tytuł. TikTok obsługuje interfejs oEmbed (szczegóły znajdziesz na stronie https://developers.tiktok.com/doc/embed-videos), co oznacza, że możesz (ręcznie lub automatycznie) przekształcić link do filmu na TikToku https://www.tiktok.com/@scout2015/video/6718335390845095173 w metadane JSON dotyczące tego filmu za pomocą https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, aby pobrać miniaturę do wyświetlenia. WordPress często używa go do żądania informacji oEmbed na przykład dla umieszczonej treści. Dzięki temu można automatycznie wyświetlać „fasadę”, która wygląda interaktywna i gdy użytkownik kliknie interaktywny film, przełącza się na umieszczenie na stronie lub do linku do niego.

Podczas umieszczania skryptów analitycznych

Usługa Analytics została zaprojektowana w taki sposób, aby zbierać informacje o Twoich użytkownikach, aby można je było analizować. Systemy Analytics to zasadniczo usługi, które zbierają i wyświetlają dane o dostępie i użytkownikach. Robią to na serwerze innej firmy, np. Google Analytics, dla ułatwienia implementacji. Istnieją też własne systemy analityczne, np. https://matomo.org/, jednak takie rozwiązanie jest bardziej pracochłonne niż korzystanie z rozwiązania innej firmy. Uruchamianie takiego systemu we własnej infrastrukturze pomaga ograniczyć zbieranie danych, ponieważ nie opuszcza on Twojego ekosystemu. Z kolei to Ty ponosisz odpowiedzialność za zarządzanie tymi danymi, ich usuwanie i ustawianie za nie zasad. Wiele obaw związanych ze śledzeniem w witrynach pojawia się wtedy, gdy odbywa się to potajemnie i w konsekwencji korzystania z usług, które w ogóle nie wymagają gromadzenia danych. Oprogramowanie Analytics zostało zaprojektowane w sposób jasno zaprojektowany do zbierania danych w celu informowania właścicieli witryn o ich użytkownikach.

W przeszłości kiedyś udawało się zbierać wszystkie dostępne dane na każdy temat, na przykład ogromną sieć rybacką, a później analizować je w poszukiwaniu interesujących wzorców. To podejście w dużej mierze wywołało poczucie niepokoju i niepokoju w związku z gromadzeniem danych, które było omówione w pierwszej części tego kursu. Obecnie wiele witryn najpierw ustala, jakie pytania należy zadać, a następnie zbiera konkretne, ograniczone dane, aby na nie odpowiedzieć.

Jeśli Twoja witryna i inne witryny korzystają z jakiejś usługi innej firmy, która działa, gdy umieszczasz w niej ich kod JavaScript oraz umieszczasz pliki cookie w przypadku każdego użytkownika, pamiętaj, że może on wykonywać niepożądane rozpoznawanie w różnych witrynach, czyli śledzić użytkowników w różnych witrynach. Niektórzy mogą, a inni nie, jednak nasze stanowisko w sprawie ochrony prywatności zakłada, że dana usługa innej firmy rzeczywiście przeprowadza śledzenie w witrynach, chyba że masz uzasadnione powody, aby tak sądzić lub wiedzieć, że jest inaczej. Nie jest to sam powód do unikania takich usług, ale warto go wziąć pod uwagę podczas oceniania wad korzystania z nich.

Kiedyś kompromis w dziedzinie analityki polegał wyłącznie na podejmowaniu decyzji o tym, czy chcą korzystać z tego narzędzia, czy też o gromadzeniu wszystkich danych i naruszeniu prywatności w zamian za uzyskiwanie statystyk i planowanie, lub na całkowite zrezygnowanie z danych. Jednak już tak nie jest i często między tymi dwoma skrajnościami można znaleźć złoty środek. Sprawdź u dostawcy analityki dostępne opcje konfiguracji, które pozwalają ograniczyć gromadzenie danych oraz zmniejszyć ilość i czas przechowywania danych. Ponieważ masz już rekordy z kontroli technicznej, możesz ponownie wykonać odpowiednie sekcje tego audytu, aby upewnić się, że zmiana tych konfiguracji faktycznie zmniejsza ilość gromadzonych danych. Jeśli przeprowadzasz takie zmiany w istniejącej witrynie, możesz liczyć na miarodajne informacje, które możesz przedstawić użytkownikom. Na przykład w Google Analytics dostępnych jest wiele opcjonalnych (domyślnie wyłączonych) funkcji ochrony prywatności, z których wiele może pomóc w zapewnieniu zgodności z lokalnymi przepisami o ochronie danych. Podczas konfigurowania Google Analytics warto rozważyć ustawienie okresu przechowywania zebranych danych (Administracja > Informacje o śledzeniu > Przechowywanie danych) poniżej domyślnego 26-miesięcznego okresu oraz włączenie niektórych bardziej technicznych rozwiązań, np. częściowej anonimizacji adresów IP (więcej szczegółów znajdziesz na https://support.google.com/analytics/answer/9019185).

Korzystanie z usług innych firm w sposób zapewniający ochronę prywatności

Do tej pory omówiliśmy sposób ochrony użytkowników przed osobami trzecimi na etapie projektowania aplikacji przy jej planowaniu. Podejmujemy decyzję o niezastosowaniu żadnej firmy zewnętrznej do tego planu, a audyty zastosowań również należą do tej kategorii: chodzi o podejmowanie decyzji dotyczących ochrony prywatności. Decyzje te nie są jednak z natury bardzo szczegółowe. Decyzje dotyczące korzystania z usług określonej firmy zewnętrznej lub rezygnacji z korzystania z usług firmy zewnętrznej nie są zbyt szczegółowe. Znacznie bardziej prawdopodobne jest, że szukasz czegoś pośredniego: potrzebujesz lub planujesz korzystać z konkretnej oferty firmy zewnętrznej przy jednoczesnym zminimalizowaniu tendencji naruszających prywatność (umyślnym lub przypadkowym). Jego zadaniem jest ochrona użytkowników w trakcie tworzenia aplikacji. Chodzi o dodanie zabezpieczeń w celu zmniejszenia nieprzewidzianych szkód. Wszystkie są to nowe nagłówki HTTP, które możesz podać podczas wyświetlania stron. Będą one wskazówką lub poleceniem klientowi użytkownika podjęcia określonych działań w zakresie prywatności lub bezpieczeństwa.

Zasada dotycząca strony odsyłającej

Tak

Ustaw zasadę strict-origin-when-cross-origin lub noreferrer, aby uniemożliwić innym witrynom odbieranie nagłówka strony odsyłającej, gdy do nich odsyłasz użytkowników lub gdy są one ładowane jako zasoby podrzędne na stronie:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Lub po stronie serwera, na przykład w Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

W razie potrzeby ustaw bardziej restrykcyjne zasady dotyczące konkretnych elementów lub żądań.

Dlaczego chroni to prywatność użytkowników

Domyślnie każde żądanie HTTP, które przeglądarka przekazuje, w nagłówku Referer zawiera adres URL strony, która je inicjuje – link, obraz lub skrypt. Może to być związane z ochroną prywatności, ponieważ adresy URL mogą zawierać informacje prywatne, które są dostępne dla innych firm i przekazują im te informacje. Web.dev podaje kilka przykładów adresów URL zawierających prywatne dane. Wiedząc, że użytkownik odwiedził Twoją witrynę z https://social.example.com/user/me@example.com, możesz poznać jego tożsamość, co stanowi pewny wyciek. Jednak nawet adres URL, który nie ujawnia prywatnych informacji, ujawnia, że ten konkretny użytkownik (który możesz znać, jeśli jest zalogowany) pochodzi z innej witryny. Oznacza to, że odwiedził on tę witrynę. Sama w sobie pojawia się informacja o historii przeglądania użytkownika, której być może nie powinniście wiedzieć.

Podanie nagłówka Referrer-Policy (z prawidłową pisownią) umożliwia jego zmianę, tak aby nie były przekazywane niektóre adresy URL stron odsyłających. MDN zawiera pełne informacje, ale większość przeglądarek domyślnie przyjmuje wartość strict-origin-when-cross-origin, co oznacza, że adres URL strony odsyłającej jest teraz przekazywany osobom trzecim jako źródło (https://web.dev, a nie https://web.dev/learn/privacy). Jest to przydatne rozwiązanie w zakresie ochrony prywatności, które nie wymaga żadnych działań. Możesz jednak jeszcze bardziej zawęzić ten problem, używając parametru Referrer-Policy: same-origin, aby uniknąć przekazywania jakichkolwiek informacji o stronie odsyłającej do osób trzecich (lub Referrer-Policy: no-referrer, aby uniknąć przekazania ich do każdego, w tym do Twojego źródła). To dobry przykład równowagi między prywatnością a użytecznością. Nowa wartość domyślna zapewnia dużo większą ochronę prywatności niż do tej pory, ale nadal przekazuje ogólne informacje wybranym przez Ciebie firmom zewnętrznym, np. dostawcy usług analitycznych.

Warto też wyraźnie określić ten nagłówek, ponieważ wtedy dokładnie znasz zasady, nie polegając na wartościach domyślnych przeglądarki. Jeśli nie możesz ustawić nagłówków, możesz ustawić zasadę strony odsyłającej dla całej strony HTML, korzystając z elementu meta w elemencie <head>: <meta name="referrer" content="same-origin">. Jeśli problem dotyczy konkretnych firm zewnętrznych, możesz też ustawić atrybut referrerpolicy dla poszczególnych elementów, takich jak <script>, <a> lub <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy (Zasady bezpieczeństwa treści)

Nagłówek Content-Security-Policy, często nazywany „CSP”, określa miejsce wczytywania zasobów zewnętrznych. Służy on głównie do celów związanych z bezpieczeństwem – zapobiega atakom typu cross-site scripting i wstrzykiwaniu skryptów, ale jeśli jest używany razem z regularnymi kontrolami, może też ograniczać możliwości przekazywania danych przez wybrane firmy zewnętrzne.

Jest to potencjalnie mniej przydatne dla użytkowników. Jeśli jeden z Twoich skryptów zewnętrznych zacznie ładować zależność ze źródła, którego nie ma na liście, żądanie zostanie zablokowane, skrypt zakończy się niepowodzeniem, a aplikacja może z nim zrezygnować (lub ograniczyć przynajmniej jej zastępczą wersję). Jest to przydatne, gdy wdrażane jest CSP ze względów bezpieczeństwa, a jest to jego normalny cel: ochrona przed problemami ze skryptami między witrynami (w tym celu używaj rygorystycznego CSP). Gdy znasz już wszystkie skrypty wbudowane używane na Twojej stronie, możesz sporządzić ich listę, obliczyć wartość skrótu lub dodać dla każdego z nich losową wartość (tzw. jednorazową wartość), a potem dodać listę skrótów do Polityki Content Security Policy. Uniemożliwi to załadowanie skryptów, których nie ma na liście. Ten element musi być wpleciony w proces produkcyjny witryny: skrypty na stronach muszą zawierać liczbę jednorazową lub hasz obliczony w ramach kompilacji. Wszystkie szczegóły znajdziesz w artykule na temat strict-csp.

Na szczęście przeglądarki obsługują powiązany nagłówek: Content-Security-Policy-Report-Only. Jeśli ten nagłówek zostanie podany, żądania, które naruszają podane zasady, nie będą blokowane, ale na podany adres URL zostanie wysłany raport JSON. Może on wyglądać tak: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/. Jeśli przeglądarka wczytuje skrypt z innego źródła niż 3p.example.com, żądanie zostanie zrealizowane, ale raport zostanie wysłany do podanego parametru report-uri. Zasadniczo używa się ich do eksperymentowania z zasadami przed ich wdrożeniem, ale warto wykorzystać je do przeprowadzenia „bieżącego audytu”. Oprócz opisanego wcześniej standardowego audytu możesz też włączyć raportowanie CSP, aby sprawdzić, czy pojawią się nieoczekiwane domeny. Może to oznaczać, że zasoby firmy zewnętrznej wczytują własne zasoby, które musisz wziąć pod uwagę i ocenić. (Może to też oznaczać, że niektóre luki w zabezpieczeniach mogły przekroczyć Twoje granice w zakresie bezpieczeństwa – warto o tym pamiętać).

Content-Security-Policy to skomplikowany i skomplikowany interfejs API. Wiemy, że trwa prace nad nową generacją CSP, która będzie miała te same cele, ale nie będzie zbyt skomplikowana w użyciu.Nie jest to jeszcze rozwiązanie gotowe, ale jeśli chcesz się dowiedzieć, na czym to polega (lub potrzebujesz pomocy w jego projektowaniu), wejdź na stronę https://github.com/WICG/csp-next.

Tak

Dodaj ten nagłówek HTTP do udostępnianych stron: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Zapisz kod JSON, który zostanie opublikowany pod tym adresem URL. Przejrzyj przechowywane dane, aby uzyskać zbiór domen zewnętrznych, o które prosi Twoja witryna, gdy odwiedzają ją inni użytkownicy. Zaktualizuj nagłówek Content-Security-Policy-Report-Only, aby uwzględnić oczekiwane domeny i zobaczyć, kiedy ta lista się zmieni:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Dlaczego

Stanowią one część audytu technicznego, który jest stale monitorowany. Wstępny audyt techniczny przedstawia listę firm zewnętrznych, które udostępniają lub przekazują dane użytkowników Twojej witryny. Nagłówek ten spowoduje, że żądania stron będą informować o tym, z którymi firmami zewnętrznymi kontaktuje się obecnie kontakt. Możesz śledzić zmiany w miarę upływu czasu. W ten sposób poinformujesz nie tylko o zmianach wprowadzonych przez istniejące firmy zewnętrzne, ale także o nowo dodanych firmach zewnętrznych, które nie zostały uwzględnione w audycie technicznym. Ważne jest zaktualizowanie nagłówka, aby zatrzymać raportowanie o oczekiwanych domenach, ale należy też od czasu do czasu powtarzać ręczny audyt techniczny (metoda Content-Security-Policy nie wskazuje, Jakie dane są przekazywane, a jedynie o wysłaniu żądania).

Pamiętaj, że nie trzeba go dodawać do każdej wyświetlanej strony za każdym razem ani do każdej z nich. Możesz zmniejszyć liczbę odpowiedzi strony otrzymywanych w nagłówku, aby uzyskać reprezentatywną próbkę raportów, które nie są przytłaczające.

Zasady dotyczące uprawnień

Nagłówek Permissions-Policy (wprowadzony pod nazwą Feature-Policy) wygląda podobnie do nagłówka Content-Security-Policy, ale ogranicza dostęp do zaawansowanych funkcji przeglądarki. Możesz na przykład ograniczyć korzystanie ze sprzętu urządzenia takiego jak akcelerometr, aparat czy urządzenie USB, a także dostęp do funkcji innych niż sprzętowe, takich jak uprawnienia do pełnego ekranu lub używania synchronicznego elementu XMLHTTPRequest. Ograniczenia te można zastosować do strony najwyższego poziomu (aby uniknąć próby korzystania z tych funkcji przez wczytane skrypty) lub stron w ramkach podrzędnych wczytywanych przez element iframe. To ograniczenie wykorzystania interfejsu API nie dotyczy odcisku palca w przeglądarce, ale uniemożliwia osobom trzecim wykonywanie szkodliwych czynności (takich jak używanie zaawansowanych interfejsów API, otwieranie wyskakujących okienek z uprawnieniami itp.). Model zagrożenia dla prywatności jest definiowany jako „intrusion” (włamanie).

Nagłówek Permissions-Policy jest określony jako lista par (funkcja, dozwolone źródła), więc:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

W tym przykładzie ta strona („self”) i elementy <iframe> ze źródła example.com mogą korzystać z interfejsów API navigator.geolocation z JavaScriptu. Pozwala to tej stronie i wszystkim ramkom podrzędnym używać pełnoekranowego interfejsu API oraz zabrania wszystkim stronom, w tym tej stronie, używania aparatu do odczytu informacji o filmie. Więcej informacji i listę potencjalnych przykładów znajdziesz tutaj.

Lista funkcji obsługiwanych przez nagłówek Permissions-Policy jest bardzo długa i może się zmieniać. Obecnie lista jest dostępna na stronie https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Tak

Przeglądarki, które obsługują Permissions-Policy, domyślnie nie zezwalają na zaawansowane funkcje w ramkach podrzędnych i musisz coś zrobić, aby je włączyć. To podejście jest domyślnie prywatne. Jeśli okaże się, że ramki podrzędne w Twojej witrynie wymagają tych uprawnień, możesz je dodać. Do strony głównej nie są jednak domyślnie stosowane żadne zasady dotyczące uprawnień, więc skrypty (w tym skrypty innych firm) wczytywane przez tę stronę nie są objęte ograniczeniem możliwości korzystania z tych funkcji. Dlatego dobrze jest zastosować domyślnie ograniczenie Permissions-Policy do wszystkich stron, a potem stopniowo dodawać do nich funkcje, których wymagają strony.

Przykłady zaawansowanych funkcji, na które Permissions-Policy wpływa, obejmują wysyłanie próśb o dostęp do lokalizacji użytkownika, dostęp do czujników (w tym akcelerometru, żyroskopu i magnetometru), uprawnienia do trybu pełnoekranowego oraz prośby o dostęp do aparatu i mikrofonu użytkownika. Pełną listę (zmieniających się) funkcji znajdziesz powyżej.

Niestety domyślne zablokowanie wszystkich funkcji, a następnie wybiórcze ich ponowne zezwolenie, wymaga podania wszystkich funkcji w nagłówku, co może wydawać się niesprawne. Na początek warto jednak zacząć od nagłówka Permissions-Policy. Strona permissionspolicy.com/ zawiera wygodny, klikalny generator, który pozwala utworzyć taki nagłówek: jego użycie do utworzenia nagłówka wyłączającego wszystkie funkcje daje następujące wyniki:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Funkcje ochrony prywatności wbudowane w przeglądarki

Oprócz zabezpieczeń związanych z czasem kompilacji i projektowania istnieją też zabezpieczenia prywatności, które mają miejsce w czasie działania: są to funkcje ochrony prywatności zaimplementowane w przeglądarkach w celu ochrony użytkowników. Nie są to funkcje, których możesz używać bezpośrednio jako deweloper witryn. Są to funkcje usługi. Są one jednak funkcje, o których warto wiedzieć, ponieważ decyzje te w przeglądarkach mogą mieć wpływ na Twoje witryny. Oto przykład wpływu tych zabezpieczeń na witrynę na Twoją witrynę: jeśli używasz kodu JavaScript po stronie klienta, który czeka na załadowanie zależności zewnętrznej przed kontynuowaniem konfiguracji strony, a zależność od innych firm w ogóle się nie wczytuje, konfiguracja strony może nigdy nie zostać ukończona, więc użytkownik zobaczy stronę załadowaną do połowy.

Obejmują one funkcję Intelligent Tracking Prevention w przeglądarce Safari (i podstawowy silnik WebKit) oraz Ulepszoną ochronę przed śledzeniem w Firefoksie (i jego silniku Gecko). To wszystko utrudnia innym firmom tworzenie szczegółowych profili Twoich użytkowników.

Podejście przeglądarek do funkcji ochrony prywatności często się zmienia, dlatego ważne jest, aby być na bieżąco. Lista poniżej zawiera prawidłowe informacje. Przeglądarki mogą też stosować inne zabezpieczenia. Te listy nie są wyczerpujące. Aby być na bieżąco ze zmianami, obejrzyj moduł ze sprawdzonymi metodami. Pamiętaj też, aby przetestować nadchodzące wersje przeglądarek pod kątem zmian, które mogą mieć wpływ na Twoje projekty. Pamiętaj, że tryby incognito/prywatne czasami stosują inne ustawienia niż domyślne w przeglądarce (np. w takich trybach pliki cookie innych firm mogą być domyślnie blokowane). Dlatego też testowanie w trybie incognito nie zawsze odzwierciedla typowe działanie większości użytkowników, którzy nie korzystają z przeglądania prywatnego. Pamiętaj też, że w różnych sytuacjach blokowanie plików cookie może oznaczać, że blokowane są też inne rozwiązania do przechowywania danych, takie jak window.localStorage, nie tylko pliki cookie.

Chrome

  • Pliki cookie innych firm powinny być w przyszłości blokowane. Od tej chwili nie są one domyślnie blokowane (ale użytkownik może je włączyć): szczegółowe informacje na ten temat znajdziesz na stronie https://support.google.com/chrome/answer/95647.
  • Funkcje ochrony prywatności w Chrome, a w szczególności funkcje Chrome, które komunikują się z Google i usługami innych firm, są opisane na stronie privacysandbox.com/.

Edge

  • Pliki cookie innych firm nie są domyślnie blokowane (ale użytkownicy mogą je włączyć).
  • Funkcja Zapobieganie śledzenia w Edge blokuje moduły do śledzenia z nieodwiedzonych witryn, a znane szkodliwe urządzenia śledzące są domyślnie zablokowane.

Firefox

Aby uzyskać informacje o tym, co może być blokowane, i rozwiązać problemy z debugowaniem, kliknij ikonę tarczy na pasku adresu lub wejdź na about:protections w Firefoksie (na komputerze).

Safari

  • Pliki cookie innych firm są domyślnie blokowane.
  • W ramach funkcji inteligentnego zapobiegania śledzeniu Safari ogranicza stronę odsyłającą przekazywaną na inne strony, tak aby znajdowała się na stronie najwyższego poziomu, a nie do konkretnej strony (https://something.example.com, zamiast https://something.example.com/this/specific/page).
  • Dane localStorage przeglądarki są usuwane po 7 dniach.

(Omówienie tych funkcji znajdziesz na stronie https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/).

Aby dowiedzieć się, co może być blokowane, i rozwiązać problemy, włącz tryb debugowania „Intelligent Tracking Prevention Debug Mode” w menu programisty Safari (na komputerze). (Więcej informacji znajdziesz na stronie https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/).

Oferty pakietowe API

Dlaczego potrzebujemy nowych interfejsów API?

Nowe funkcje i zasady chroniące prywatność dostępne w przeglądarkach pomagają chronić prywatność użytkowników, ale wiążą się z nimi pewne wyzwania. Wiele technologii internetowych nadaje się do śledzenia w witrynach, mimo że jest zaprojektowane i wykorzystywane do innych celów. Na przykład wiele systemów federacji tożsamości, których używamy na co dzień, bazuje na plikach cookie innych firm. Wiele rozwiązań reklamowych, na których wydawcy polegają dziś w generowaniu przychodów, jest opartych na plikach cookie innych firm. Wiele rozwiązań do wykrywania oszustw bazuje na odciskach cyfrowych. Co się stanie z tymi przypadkami użycia, gdy wycofamy pliki cookie innych firm i odciski cyfrowe?

Rozróżnienie przypadków użycia i rzetelne odróżnianie zastosowań naruszających prywatność od innych jest trudne i podatne na błędy. To dlatego większość popularnych przeglądarek blokuje pliki cookie innych firm i korzystanie z odcisków cyfrowych lub zamierza to robić w celu ochrony prywatności użytkownika.

Potrzebne jest nowe podejście: w miarę wycofywania plików cookie innych firm i ograniczenia użycia odcisków cyfrowych deweloperzy potrzebują specjalnych interfejsów API, które spełniają określone przypadki użycia, ale są zaprojektowane z myślą o ochronie prywatności. Celem jest zaprojektowanie i stworzenie interfejsów API, które nie będą służyć do śledzenia w witrynach. W przeciwieństwie do funkcji przeglądarek opisanych w poprzedniej sekcji te technologie mają za zadanie przekształcić się w interfejsy API działające w różnych przeglądarkach.

Przykłady propozycji interfejsu API

Lista poniżej nie jest wyczerpująca – zawiera tylko część poruszanych tematów.

Przykłady propozycji interfejsu API, które zastąpią technologie oparte na plikach cookie innych firm:

Przykłady propozycji interfejsu API zastępujących technologie oparte na pasywnym śledzeniu:

Przykłady innych propozycji, na których inne interfejsy API mogą w przyszłości korzystać bez plików cookie innych firm:

Poza tym pojawia się kolejny typ propozycji interfejsu API, który ma na celu wprowadzenie obecnie łagodzenia skutków ukrytego śledzenia specyficznych dla danej przeglądarki. Jednym z przykładów jest Budżet ochrony prywatności. W tych różnych przypadkach interfejsy API, które zostały początkowo zaproponowane przez Chrome, działają pod terminem Piaskownicy prywatności.

Global-Privacy-Control to nagłówek, który informuje witrynę, że użytkownik nie chce, aby zgromadzone dane osobowe były udostępniane innym witrynom. Jego intencja jest podobna do tej, która została wycofana.

Stan ofert pakietowych interfejsu API

Większość z tych propozycji interfejsu API nie jest jeszcze wdrożona lub wdraża się tylko w ramach flag albo w ograniczonej liczbie środowisk do eksperymentowania.

Ta publiczna faza inkubacji jest ważna: dostawcy przeglądarek i deweloperzy zbierają dane o tym, czy te interfejsy API są przydatne i czy faktycznie działają, do czego zostały zaprojektowane. Deweloperzy, dostawcy przeglądarek i inne podmioty ekosystemu korzystają z tej fazy do iteracji projektu interfejsu API.

Najlepszym miejscem, aby być na bieżąco z proponowanymi nowymi interfejsami API, jest obecnie lista ofert pakietowych grupy Privacy Group w GitHubie.

Czy chcesz używać tych interfejsów API?

Jeśli Twoja usługa jest bezpośrednio oparta na plikach cookie innych firm lub technikach takich jak odciski cyfrowe, zainteresuj się nowymi interfejsami API, wypróbuj je i podziel się swoimi doświadczeniami w kwestii dyskusji i projektu API. Nie musisz znać wszystkich szczegółów dotyczących nowych interfejsów API w momencie tworzenia tego tekstu, ale warto wiedzieć, co się zmieni.