Partycjonowanie pamięci masowej

Aby zwiększyć prywatność użytkowników i zapobiec śledzeniu między witrynami w ramach kanału bocznego, Chrome izoluje większość interfejsów API pamięci i komunikacji w kontekstach zewnętrznych za pomocą partycjonowania miejsca na dane.

Stan wdrożenia

Ta funkcja została włączona dla wszystkich użytkowników Chrome w wersji 115 lub nowszej. Podobne rozwiązania są stosowane lub planowane w innych popularnych przeglądarkach, takich jak Firefox i Safari. Propozycja partycjonowania pamięci na GitHubie jest dostępna 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 na ustalanie konkretnych stanów użytkownika w witrynie najwyższego poziomu za pomocą technik kanału bocznego, takich jak ataki na czas, 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 umieszczony w witrynach a.com i b.com, może ona poznać Twoje nawyki związane z przeglądaniem tych witryn, przechowując i odczytując identyfikator z miejsca do przechowywania. 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.

Ogólnie partycjonowanie oznacza, że dane zapisane przez interfejsy API pamięci masowej, takie jak Local Storage i IndexedDB w ramach ramki iframe, nie są już dostępne dla wszystkich kontekstów, które mają ten sam origin. Teraz są one dostępne tylko w kontekście, który ma takie samo pochodzenie i taką samą witrynę najwyższego poziomu.

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

Złożoność partycjonowania pamięci znacznie wzrasta, gdy iframe są zagnieżdżone, zwłaszcza gdy ten sam element domeny pochodzenia pojawia się wielokrotnie w łańcuchu.

Na przykład komórka A1 zawiera iframe komórki B, która zawiera iframe komórki A2. Obie komórki znajdują się w tej samej witrynie. Jeśli podział uwzględniałby tylko witrynę najwyższego poziomu i źródło bieżącej ramki, element iframe A2 mógłby zostać błędnie uznany za „własny”, ponieważ współdzieli witrynę z elementem najwyższego poziomu (A1), mimo że pomiędzy nimi znajduje się element iframe B w innej witrynie. 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 dodaje do klucza partycji pamięci bit przodka. Ten bit jest ustawiany, jeśli jakikolwiek dokument między bieżącym iframe a witryną najwyższego poziomu pochodzi z innego źródła (z innej witryny). W tym przypadku witryna B jest witryną krzyżową, więc bit jest ustawiony dla A2, a jej magazyn jest wyodrębniony z magazynu A1.

Jeśli łańcuch ramki iframe składa się wyłącznie z kontekstów w tej samej witrynie (np. witryna A1 zawiera A2, która z kolei zawiera A3), bit przodka nie będzie dalej dzielić ich pamięci. W takich przypadkach miejsce na dane pozostaje współdzielone, a kluczem jest wspólne źródło i witryna najwyższego poziomu.

W przypadku witryn, które wymagają dostępu do niepartycjonowanych iframe’ów w łańcuchu, Chrome eksperymentuje z rozszerzeniem interfejsu Storage Access API, aby umożliwić takie zastosowanie. Ponieważ interfejs Storage Access API wymaga, aby witryna w ramce wyraźnie wywołała interfejs API, zmniejsza to ryzyko kliknięcia.

Zmiany interfejsu API spowodowane podziałem

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

• Interfejsy Storage API
• Interfejsy API do obsługi komunikacji
• Service 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.

  Metoda navigator.storage.estimate() zawiera teraz informacje dotyczące partycji pamięci. Interfejsy API przeznaczone tylko dla Chrome, takie jak window.webkitStorageInfo i navigator.webkitTemporaryStorage, zostały wycofane.

  IndexedDB i miejsce na dane w pamięci podręcznej korzystają z systemu limitów partycji.

• 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. Nie są one zarządzane za pomocą limitów, ale nadal są dzielone.

• System plików prywatnych Origin

  Interfejs File System Access API pozwala witrynie odczytywać lub zapisywać zmiany bezpośrednio w plikach i folderach na urządzeniu po tym, jak użytkownik przyzna dostęp. System plików prywatnych źródła umożliwia przechowywanie prywatnych treści bezpośrednio na dysku. Te treści pozostają dostępne dla użytkowników, ale są teraz podzielone na partycje.

• Storage Bucket API

  Interfejs Storage Bucket API jest opracowywany na potrzeby Storage Standard, który konsoliduje różne interfejsy API do przechowywania danych, takie jak IndexedDB i localStorage, za pomocą nowej koncepcji o nazwie zasobniki. 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.

• Adres URL bloba

  Adres URL obiektu blob umożliwia dostęp do bloba, czyli obiektu zawierającego dane nieprzetworzone. Bez partycjonowania pamięci adres URL bloba wygenerowany w elemencie iframe strony zewnętrznej w jednej witrynie może być używany w elemencie iframe z tego samego źródła umieszczonym w innej witrynie. Jeśli na przykład elementy iframe example.com są osadzone w a.com i b.com, blob URL wygenerowany w a.com może być przekazywany do b.com i używany przez iframe osadzony w b.com bez żadnych ograniczeń. Począwszy od wersji Chrome 137 (wydana 27 maja 2025 r.) adresy URL blobów są podzielone na wszystkie zastosowania z wyjątkiem nawigacji na najwyższym poziomie. Przykłady sytuacji, które będą teraz blokowane, to m.in. używanie adresów URL blobów w wielu partycjach z fetch() lub jako wartości atrybutu src w różnych elementach HTML. Nawigacja najwyższego poziomu, np. wywołanie window.open() lub kliknięcie linku z target='_blank' do adresów URL Bloba, nie zostanie zablokowana, jeśli jest to nawigacja w różnych partycjach, ale noopener zostanie wymuszona, jeśli witryna adresu URL bloba jest w innej witrynie niż witryna najwyższego poziomu strony, która zainicjowała nawigację. Wymuszenie noopener oznacza, że dokument inicjujący nawigację nie będzie mógł uzyskać uchwytu okna dla otwartego dokumentu bloba URL. W poprzednim przykładzie partycjonowanie uniemożliwi iframe na stronie b.com pobranie zawartości adresu URL bloba, ale nadal będzie ona mogła window.open() go pobrać.

Interfejsy API komunikacji

Oprócz interfejsów API pamięci partycjonowane są też interfejsy API komunikacji, które umożliwiają komunikację jednego kontekstu 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.

Ze względu na partycjonowanie interfejsy API komunikacji uniemożliwiają iframe’om innych firm wymianę danych z kontekstami o tej samej domenie:

• 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 zachowania tagu iframe postMessage() w witrynach na wielu stronach, ponieważ związek między tymi kontekstami jest już wyraźnie określony.

• SharedWorker

  Interfejs API SharedWorker udostępnia instancję roboczą, do której można uzyskać dostęp w kontekstach przeglądania w ramach 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 na czas wykonywania pewnych operacji.

Interfejs Service Worker API

Interfejs Service Worker API umożliwia witrynom wykonywanie zadań w tle. Witryny rejestrują pracowników usługi, którzy tworzą nowe konteksty pracowników, aby odpowiadać na zdarzenia. Do tej pory te procesy mogły komunikować się z dowolnym kontekstem tego samego pochodzenia. Jednak ponieważ mogą one zmieniać czas żądań nawigacyjnych, stanowią zagrożenie wycieku informacji z różnych witryn, na przykład w ramach przeszukiwania historii.

Z tego powodu skrypty service worker zarejestrowane w kontekście usługi innej firmy są teraz dzielone.

Interfejsy Extension API

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

Strony rozszerzeń (strony o schemacie chrome-extension://) można umieszczać w witrynach w internecie. W tym scenariuszu strony rozszerzeń nadal mają dostęp do partycji najwyższego poziomu. Rozszerzenia mogą też osadzać inne witryny. W takim przypadku osadzone witryny będą miały dostęp do partycji najwyższego poziomu, o ile rozszerzenie ma dla nich uprawnienia hosta.

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 filmie użyto 2 witryn: A i B.

• Gdy odwiedzasz witrynę A w kontekście najwyższego poziomu, ustawia ona dane 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 flagi wiersza poleceń. Uwaga: ta opcja wiersza poleceń jest przeznaczona do celów programistycznych i testowania. Może zostać usunięta lub zmieniona w przyszłych wersjach Chrome.

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 uczestnicz w dyskusji.
• Pomoc dla deweloperów: zadawaj pytania i ucz się na temat Piaskownicy prywatności w repozytorium Pomoc dla deweloperów Piaskownicy prywatności.
• Zgłoś błąd: jeśli uważasz, że coś nie działa zgodnie z oczekiwaniami, zgłoś błąd w śledzeniu Chromium.