Przeglądarka webowa w pierwotnym zamierzeniu miała być "czystym klientem" - wyświetlać informacje sprowadzane z odległego serwera i wykonywać wszystko to, co zechce on przekazać jej do wykonania. Wydawcy przeglądarek rozbudowywali je jednak o nowe funkcje, chociaż sam HTML nie rozwijał się prawie wcale w ostatnich latach.

Już dawno przeglądarki zaczęły oferować projektantom stron webowych możliwość umieszczania małych fragmentów danych poza witryną. Lokalne składowanie danych wykorzystywanych przez witryny internetowe możliwe było w małych plikach tekstowych (do 4 096 bajtów), zwanych cookies. Jednak ciasteczka podejrzewano o to, że służą do śledzenia poczynań użytkowników, co spowodowało wprowadzenie opcji ich usuwania. Ponadto cookies są nie tylko przechowywane w komputerze, ale na żądanie mogą być przesyłane zwrotnie do serwera, a przesyłanie zbyt wielu danych w łańcuchach nieprzekraczających 4096 znaków obciąża sieć procedurami akceptacyjnymi i spowalnia reakcje. Dla projektantów są to poważne ograniczenia możliwości ich wykorzystywania.

Zobacz również:

• Google wzmacnia bezpieczeństwo przeglądarki Chrome
• Ta przeglądarka pozwoli pobierać na komputer różne modele językowe LLM

W standardzie HTML5 zespół projektujący postanowił uwzględnić wszystkie te problemy i stworzyć solidne podstawy dla oprogramowania opartego na przeglądarkach, dając programistom JavaScript możliwość przechowywania danych na lokalnym komputerze w praktycznych rozmiarach. Mogą być one dostępne non stop lub jedynie podczas jednej sesji. W najprostszym przypadku może to być pamięć podręczna dla wszystkich wywołań klienta do centralnego komputera, ale też i znacznie więcej. Web Storage tworzy bazę danych, która może zawierać nawet całe aplikacje internetowe, umożliwiając korzystanie z nich w trybie offline - nie ma wtedy potrzeby instalowania oprogramowania.

Pamięć sesyjna

Najprostszy poziom Web Storage to przechowywanie danych dla bieżących sesji - innymi słowy dopóty, dopóki karta lub okno przeglądarki pozostaje otwarte. Jednak nie musi to być sztywne ograniczenie, ponieważ specyfikacja pozostawia przeglądarce otwartą możliwość utrzymywania tych danych. Mechanizm nie jest zbyt rozbudowany. Każdy dokument uzyskuje obiekt sessionStorage z kilkoma głównymi funkcjami: setItem, getItem i clear. Każda pozycje to para klucz/dane, dokładnie jak w tablicy asocjacyjnej. Dane są klonem bieżących wartości. Nowy dokument dostaje nowy obiekt.

Pamięć lokalna

Większe korzyści wiążą się z obiektem localStorage, który wygląda bardzo podobnie jak obiekt sessionStorage, ale zachowuje się całkiem inaczej. Tam gdzie sessionStorage zapomina, localStorage - zapamiętuje. Dane powinny być nadal w obiegu, nawet po zamknięciu okna i wyłączeniu komputera. Ta ciągłość jest jeszcze trwalsza. Dwa okna wizytujące tę samą witrynę powinny współdzielić te same dane. Zmiana w kodzie pracującym w oknie powinna zmienić dane udostępnione w tym drugim. Według specyfikacji, zdarzenie storageChange w jednym oknie powinno być propagowane do wszystkich okien. Jednak łatwość, z jaką dwa okna mogą uzyskiwać dostęp do tych samych danych, może stwarzać problem race conditions, prowadzący do ich uszkadzania. Trwają więc dyskusje, czy obiekt pamięci lokalnej nie powinien być chroniony przed takimi zagrożeniami poprzez zaimplementowanie algorytmu wzajemnego wykluczania (mutex), który może ograniczać uszkadzanie danych. SessionStorage i localStorage są w pewnym zakresie zaimplementowane we wszystkich głównych przeglądarkach (Chrome, Firefox, Internet Explorer, Opera, Safari).

Pamięć indeksowana

Pary klucz/wartość w obiekcie localStorage są zazwyczaj wystarczająco funkcjonalne dla wielu podstawowych projektów, ale nie można ich porównywać z funkcjonalnością relacyjnych baz danych, które przechowują dane w indeksowanych tabelach. Tutaj istnieją już dwie opcje. Pierwsza - to standard Web SQL Database, który po opracowaniu wersji roboczej został zaimplementowany w niektórych przeglądarkach (Opera), zanim projekt zarzucono na rzecz bardziej abstrakcyjnej wersji. Ta nowa opcja to Indexed Database - lista kluczy i wartości, takich jak w obiekcie localStorage. Różnica jest taka, że indeks może przyspieszać wyszukiwanie niezbędnych obiektów. Indeksowana pamięć zawiera także możliwość wykonywania zmian w formie transakcji, eliminując problem race conditions, związany z obiektem localStorage. Wersja robocza standardu Indexed Database nadal jest opracowywana i np. problem blokowania przez dynamiczne transakcje zablokowanego już wcześniej obiektu bazy danych, nadal jest dopracowywany. IndexedDB nie jest jeszcze obsługiwana w żadnej przeglądarce.

Pamięć podręczna dla aplikacji

Udostępnienie stronom WWW możliwości lokalnego przechowywania danych może wpływać zmniejszenie ruchu sieciowego - poprzez buforowanie wywołań AJAX i innych ważnych informacji wyświetlanych użytkownikowi. API AppCaching określa, jak długo przeglądarka może utrzymywać elementy stron WWW przechowywane lokalnie. To pozwala nie tylko na zmniejszenie konieczności przeładowywania stron, ale także umożliwia stronom WWW działanie bez połączenia z internetem. Innymi słowy czyni z nich coś w rodzaju zainstalowanego oprogramowania. AppCaching jest obsługiwane w większości przeglądarek z wyjątkiem Internet Explorer (w tym również IE9 beta).

Wymieniono tylko niektóre mechanizmy Web Storage. Z nowymi możliwościami wiążą się jednak również nowe zagrożenia. Eksperci ds. bezpieczeństwa ostrzegają, że coraz bardziej zaciera się granica między treściami internetowymi a lokalnymi aplikacjami, co otwiera hakerom nowe możliwości ataków, a niezależność platformowa HTML5 sprawia, że narażeni na nie będą użytkownicy wszystkich systemów operacyjnych.