Wersja Chrome 130 wprowadza zmiany w interfejsie Shared Storage API, aby umożliwić korzystanie ze skryptów workletów w wielu domenach za pomocą interfejsów createWorklet() i addModule(). Wprowadziliśmy też w Chrome 132 aktualizacje interfejsu Select URL API z użyciem pamięci współdzielonej, które umożliwiają zapisywanie zapytań.
Worklety między domenami z interfejsem Shared Storage API w Chrome 130
Wprowadziliśmy zmiany w interfejsie Shared Storage API w Chrome 130, aby zapewnić Ci większą elastyczność podczas pracy ze skryptami workletów w różnych domenach.
Co się zmieniło
Usunęliśmy ograniczenie pochodzenia wewnętrznego w przypadku addModule(), dzięki czemu teraz możesz wczytywać skrypty workletów z dowolnego pochodzenia. Skrypty workletów w wielu domenach umożliwiają realizację kluczowych przypadków użycia, takich jak hostowanie skryptów workletów w sieciach CDN. Jeśli skrypt workletu pochodzi z innego pochodzenia niż wywołujący go kontekst przeglądania, do uzyskiwania dostępu do współdzielonego magazynu danych używane jest pochodzenie kontekstu wywołującego.
Aby dopasować zachowanie funkcji addModule() do nowego zachowania i zmniejszyć potencjalne zamieszanie, do wywołania createWorklet() dodano parametr dataOrigin, który umożliwia odczytywanie i zapisywanie danych na innej partycji współdzielonego magazynu niż ta, do której odnosi się wywołujący kontekst przeglądania. Dzięki temu możesz dokładniej kontrolować, do którego współdzielonego magazynu danego źródła ma dostęp poszczególny worklet, nawet gdy używasz skryptów workletów z wielu źródeł.
Jak się zmieniło
Od wersji 125 przeglądarki Chrome skrypt pochodzący od zewnętrznego dostawcy na stronie może tworzyć interfejsy interoperacyjne bez konieczności korzystania z ramek iframe w innych domenach, wywołując createWorklet(url). Wcześniej createWorklet(url) używała adresu URL skryptu (url) jako źródła partycji danych niezależnie od wywołującego kontekstu.
W Chrome 130, aby dostosować się do nowego zachowania addModule(), createWorklet()używa również kontekstu wywołania jako domyślnego źródła partycji danych. Aby nadal używać adresu URL skryptu jako źródła partycji danych, wprowadzamy nową właściwość dataOrigin, która umożliwia jawne określenie źródła partycji danych.
Nowa właściwość dataOrigin akceptuje wartość "script-origin", która ustawia źródło partycji danych jako źródło skryptu, oraz wartość "context-origin", która ustawia źródło partycji danych jako wywołujący kontekst przeglądania. W przyszłej wersji planujemy też udostępnić obsługę niestandardowych źródeł partycji danych, w których skrypt worklet może uzyskać dostęp do danych ze współdzielonego miejsca na dane z dowolnego źródła (po wyrażeniu zgody).
Podczas wczytywania skryptu między domenami z ustawionym źródłem danych "script-origin" żądanie skryptu wysłane z przeglądarki będzie zawierać nagłówek "Sec-Shared-Storage-Data-Origin: <origin>". Aby to umożliwić, skrypt musi też zawierać nagłówek odpowiedzi z zezwoleniem "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1".
How to use
Jeśli używasz już parametru createWorklet() z pochodzącym ze skryptu źródłem partycji danych workleta, możesz ustawić parametr dataOrigin w ten sposób:
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
Ponieważ createWorklet() umożliwia tworzenie partycji danych w wielu domenach oraz tworzenie wielu workletów, zachęcamy do przejścia z użycia addModule() na createWorklet().
Zaktualizowaliśmy dokumentację dla deweloperów, aby uwzględnić te zmiany i dodać dodatkowe wskazówki.
Zapisane zapytania za pomocą interfejsu Select URL API w Chrome 132
Wprowadziliśmy aktualizacje interfejsu Select URL API z użyciem Shared Storage w Chrome 132 z obsługą zapisanych zapytań.
Co się zmienia
Interfejs Select URL API ma obecnie 2 budżety na wczytanie strony, które ograniczają liczbę wywołań interfejsu API podczas wczytywania każdej strony. Wprowadzamy możliwość zapisywania i ponownego używania zapytań na poszczególnych stronach. Gdy używasz zapisanego zapytania, budżety na wczytanie strony są obciążane przy pierwszym uruchomieniu zapisanego zapytania, ale nie przy kolejnych jego uruchomieniach w ramach tego samego wczytania strony.
Jak wdrażać zapisane zapytania
Począwszy od wersji 132 Chrome możesz używać parametru savedQuery w opcjach selectURL() z nazwą zapytania:
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
Używaj tej samej nazwy savedQuery w przypadku każdego wywołania funkcji selectURL(), aby mieć pewność, że za kolejne zapytania będzie naliczana opłata z tego samego budżetu.
Zaktualizowaliśmy dokumentację, aby odzwierciedlić te zmiany i dodać dodatkowe informacje o planowaniu budżetu na selectURL().
Angażowanie użytkowników i przesyłanie opinii
Pamiętaj, że propozycja interfejsu Shared Storage API jest obecnie przedmiotem dyskusji i jest w fazie rozwoju, dlatego może ulec zmianie.
Chętnie poznamy Twoją opinię na temat interfejsu Shared Storage API.
- Proposal (Propozycja): zapoznaj się ze szczegółami oferty.
- Dyskusja: dołącz do trwającej dyskusji, aby zadawać pytania i dzielić się swoimi spostrzeżeniami.
Trzymaj rękę na pulsie
- Lista mailingowa: zasubskrybuj naszą listę mailingową, aby otrzymywać najnowsze informacje i ogłoszenia dotyczące interfejsu Storage API.
Potrzebujesz pomocy?
- Pomoc dla deweloperów: możesz kontaktować się z innymi deweloperami i uzyskiwać odpowiedzi na swoje pytania w repozytorium pomocy dla deweloperów Piaskownicy prywatności.