Partycjonowanie pamięci masowej

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Aby zapobiec niektórym typom śledzenia między witrynami, Chrome partycjonuje większość interfejsów API pamięci i komunikacji w kontekstach zewnętrznych.

Stan wdrożenia

Ta funkcja została włączona dla wszystkich użytkowników Chrome w wersji 115 lub nowszej. Proponowane partycjonowanie pamięci jest dostępne do dalszej dyskusji.

Co to jest partycjonowanie miejsca na dane?

Aby zapobiegać niektórym rodzajom śledzenia między witrynami, Chrome partycjonuje miejsce na dane oraz interfejsy API komunikacji w kontekstach podmiotów zewnętrznych.

Bez partycjonowania pamięci witryna może łączyć dane z różnych witryn, aby śledzić użytkownika w internecie. Pozwala też wbudowanej witrynie wywnioskować określone stany użytkownika w witrynie najwyższego poziomu za pomocą technik kanału bocznego, takich jak ataki oparte na czasie, XS-Leaks i COSI.

Wcześniej miejsce na dane było przypisywane tylko do źródła. Oznacza to, że jeśli iframe z witryny example.com jest osadzony w witrynach a.com i b.com, może ona poznać Twoje nawyki związane z przeglądaniem tych witryn, zapisując i odczytując identyfikator z miejsca na dane. Gdy partycjonowanie pamięci przez podmiot zewnętrzny jest włączone, miejsce na dane example.com znajduje się w 2 różnych partycjach: jedna dla a.com, a druga dla b.com.

Dzielenie na partycje oznacza, że dane przechowywane przez interfejsy API do przechowywania, takie jak pamięć lokalna i IndexedDB za pomocą elementu iframe, nie są już dostępne dla wszystkich kontekstów w tej samej domenie. Zamiast tego dane są dostępne tylko w kontekstach z tą samą domeną i tą samą witryną najwyższego poziomu.

Partycjonowanie pamięci w przypadku połączonych elementów iframe

Gdy element iframe zawiera element iframe, sytuacja staje się bardziej skomplikowana. Jest to szczególnie ważne, gdy ta sama usługa jest używana w kilku miejscach w łańcuchu.

Na przykład komórka A1 zawiera element iframe komórki B, który zawiera element iframe komórki A2. Obie komórki znajdują się w tej samej witrynie. Jeśli podczas dzielenia na partycje weźmiemy pod uwagę tylko konteksty najwyższego i bieżącego poziomu, iframe A2 może zostać uznany za domeny własne, ponieważ znajduje się na tej samej stronie co iframe najwyższego poziomu (A1), mimo że jest to iframe zewnętrzny (B). Jeśli A2 miałby domyślnie dostęp do niepartycjonowanego miejsca na dane, mógłby narazić A1 na zagrożenia związane z bezpieczeństwem, takie jak clickjacking.

Aby rozwiązać ten problem, Chrome zawiera dodatkowy „bit przodka” w ramach klucza partycji pamięci, który jest ustawiany, jeśli jakikolwiek dokument między bieżącym kontekstem a kontekstem najwyższego poziomu jest dokumentem z wielu witryn. W tym przypadku witryna B jest witryną wielowitrynową, więc bit jest ustawiony dla komórki A2, a jego pamięć jest wyodrębniona z komórki A1.

Jeśli w łańcuchu nie ma kontekstu między witrynami, pamięć nie jest partycjonowana. Na przykład witryna A1 zawierająca element iframe dla witryny A2, która zawiera element iframe dla witryny A3, nie zostanie podzielona na witryny A1, A2 ani A3, ponieważ wszystkie znajdują się w tej samej witrynie.

W przypadku witryn, które wymagają niepartycjonowanego dostępu do połączonych ramek iframe, Chrome eksperymentuje z rozszerzeniem interfejsu Storage Access API, aby umożliwić ten przypadek użycia. Ponieważ interfejs Storage Access API wymaga, aby witryna w ramce wyraźnie wywołała interfejs API, zmniejsza to ryzyko kliknięcia.

Zaktualizowane interfejsy API

Interfejsy API objęte podziałem można podzielić na te grupy:

• Interfejsy Storage API
• Interfejsy API do obsługi komunikacji
• Storage Worker API
• Interfejsy API rozszerzeń

Interfejsy Storage API

• System limitów

  System limitów służy do określania ilości miejsca na dysku zarezerwowanego na dane. System limitów zarządza każdą partycją jako oddzielnym zasobnikiem, aby określić, ile miejsca jest dozwolone i kiedy jest ono usuwane.

  Funkcja navigator.storage.estimate() zwraca informacje o partycji. Interfejsy API przeznaczone tylko dla Chrome, takie jak window.webkitStorageInfo i navigator.webkitTemporaryStorage, zostaną wycofane.

  IndexedDB i pamięć podręczna używają nowego systemu limitów z partycjami.

• Web Storage API

  Interfejs Web Storage API udostępnia mechanizmy, za pomocą których przeglądarki mogą przechowywać pary klucz-wartość. Istnieją 2 mechanizmy: pamięć lokalna i pamięć sesji. Obecnie nie są one zarządzane za pomocą limitów, ale nadal są dzielone.

• System plików prywatnych Origin

  Interfejs File System API umożliwia witrynie odczytywanie lub zapisywanie zmian bezpośrednio w plikach i folderach na urządzeniu po przyznaniu przez użytkownika dostępu. System plików prywatnych źródła umożliwia przechowywanie prywatnych treści na dysku, do których użytkownik ma łatwy dostęp i które są podzielone na partycje.

• Storage Bucket API

  Interfejs Storage Bucket API jest opracowywany na potrzeby Storage Standard, który konsoliduje różne interfejsy API pamięci, takie jak IndexedDB i localStorage, za pomocą nowej koncepcji zwanej zasobnikami. Dane przechowywane w zasobach i powiązane z nimi metadane są dzielone na partycje.

• Nagłówek Clear-Site-Data

  Uwzględnienie nagłówka Clear-Site-Data w odpowiedzi umożliwia serwerowi wysłanie żądania wyczyszczenia danych zapisanych w przeglądarce użytkownika. Pamięć podręczna, pliki cookie i pamięć DOM można wyczyścić. Użycie nagłówka powoduje wyczyszczenie miejsca na dane tylko w ramach jednej partycji.

• Blob URL store

  Blob to obiekt zawierający nieprzetworzone dane do przetworzenia. Można wygenerować URL bloba, aby uzyskać dostęp do zasobu. Magazyny adresów URL blobów nie są dzielone na partycje. Aby umożliwić nawigację w kontekście najwyższego poziomu do dowolnego adresu blob (dyskusja), pamięć blobów URL może być podzielona na partycje według klastra agentów, a nie według witryny najwyższego poziomu. Ta funkcja nie jest jeszcze dostępna do testowania, a mechanizm partycjonowania może w przyszłości ulec zmianie.

Interfejsy API komunikacji

Oprócz interfejsów API pamięci partycjonowane są też interfejsy API komunikacji, które umożliwiają jednej konwersacji komunikowanie się przez granice pochodzenia. Zmiany te dotyczą głównie interfejsów API, które umożliwiają wykrywanie innych kontekstów za pomocą funkcji broadcastingu lub rendezvous w ramach tego samego źródła.

W przypadku tych interfejsów API do komunikacji elementy iframe innych firm nie mogą już komunikować się z kontekstem tej samej domeny:

• Kanał transmisji

  Interfejs Broadcast Channel API umożliwia komunikację między kontekstami przeglądania (oknami, kartami lub elementami iframe) a instancjami roboczymi w tej samej domenie.

  Nie proponujemy zmiany iframe w wielu witrynach postMessage(), w których relacje między kontekstami są wyraźnie zdefiniowane.

• SharedWorker

  Interfejs API SharedWorker udostępnia moduł roboczy, do którego można uzyskać dostęp w różnych kontekstach przeglądania tej samej domeny.

• Blokada internetowa

  Interfejs Web Locks API umożliwia kodowi działającemu w jednej karcie lub instancji roboczej tej samej domeny uzyskanie blokady na zasób udostępniony podczas wykonywania pewnych działań.

Interfejs Service Worker API

Interfejs Service Worker API zapewnia interfejs do wykonywania zadań w tle. Witryny tworzą trwałe rejestracje, które tworzą nowy kontekst pracownika w odpowiedzi na zdarzenia. Ten pracownik może komunikować się z dowolnym kontekstem tego samego pochodzenia. Ponadto interfejs Service Worker API może zmieniać czas wysyłania żądań nawigacyjnych, co może prowadzić do wycieku informacji między witrynami, np. przeszukiwania historii.

Dlatego serwisy worker zarejestrowane w kontekście zewnętrznym są dzielone.

Interfejsy Extension API

Rozszerzenia to programy, które umożliwiają użytkownikom dostosowanie przeglądania do własnych potrzeb.

Strony rozszerzeń (strony z schematem chrome-extension://) mogą być umieszczane w witrynach w internecie. W takich przypadkach będą one nadal miały dostęp do swojej partycji najwyższego poziomu. Strony te mogą też zawierać inne witryny. W takim przypadku te witryny będą miały dostęp do partycji najwyższego poziomu, o ile rozszerzenie ma uprawnienia hosta dla danej witryny.

Więcej informacji znajdziesz w dokumentacji rozszerzeń.

Demonstracja: testowanie partycjonowania miejsca na dane

Witryna demonstracyjna: https://storage-partitioning-demo-site-a.glitch.me/

W tym celu używamy dwóch witryn: A i B.

• Gdy odwiedzasz witrynę A w kontekście najwyższego poziomu, dane są zapisywane za pomocą różnych metod przechowywania.
• Witryna B umieszcza na swojej stronie stronę z witryny A, a umieszczony element próbuje odczytać wcześniej ustawione opcje przechowywania.
• Gdy witryna A jest umieszczona w witrynie B, nie ma dostępu do tych danych, gdy miejsce na dane jest podzielone na partycje, więc odczyty nie działają.
• Prezentacja wykorzystuje powodzenie lub niepowodzenie poszczególnych odczytów, aby pokazać, czy dane są partycjonowane.

Obecnie możesz wyłączyć partycjonowanie pamięci w Chrome, używając --disable-features=ThirdPartyStoragePartitioning opcji wiersza poleceń.

Możesz też przetestować inne przeglądarki w taki sam sposób, aby sprawdzić stan partycjonowania.

Zaangażowanie i przesyłanie opinii

• GitHub przeczytaj pierwotną propozycję, zadawaj pytania i ucz się na dyskusji.
• Pomoc dla deweloperów: zadawaj pytania i ucz się na podstawie dyskusji w repozytorium Piaskownicy prywatności dla deweloperów.
• Zgłoś błąd: jeśli uważasz, że coś nie działa zgodnie z oczekiwaniami, zgłoś błąd w śledzeniu Chromium.