Proszę o wsparcie dla Krzysia Bulczaka, największego bohatera jakiego znam.

Alternatywa dla URL

Pierwszy (i kto wie, czy nie jedyny) wpis w tym roku postanowiłem poświęcić chyba jednemu z najważniejszych elementów systemu WWW: adresowi URL (Uniform Resource Locator). jak piszą w dokumentacji standardu z 1994 roku Tim Berners-Lee i współpracownicy, URL to:

compact string representation for a resource available via the Internet

czyli zwięzła reprezentacja tekstowa dla zasobu dostępnego przez Internet. Niekiedy, myśląc o URLach, zamiennie stosuje się pojęcie URI (Uniform Resource Identifier), które posiada ogólniejsze znaczenie:

a compact string of characters for identifying an abstract or physical resource

– jak widać, definicja URL zawiera odwołanie do dystrybucji internetowej, definicja URI już nie. W każdym razie, w kontekście Webu, w URL czy URI chodzi o to samo: posiadanie zbudowanego zgodnie ze standardowym schematem adresu lokalizacyjnego czy identyfikującego jakiś zasób. Znaczenie URLi jest fundamentalne dla hipertekstu – każda z leksji (czy dokumentów w ramach sieci) musi być dostępna pod unikatowym adresem. Berners-Lee, projektując usługę WWW, potrzebował rozwiązania pozwalającego na zbudowanie otwartego systemu połączeń – URL pozwalał na w miarę swobodne adresowanie zasobów, przy czym dodatkowo standard wymuszał podawanie protokołu, czyli metody dotarcia do zasobu (np. przez WWW, FTP czy adresata wiadomości mailto:imie@domena.pl). Wymagany przez standard kształt adresu URL nie jest doskonały, na przykład niedawno Berners-Lee przepraszał za obowiązkowe //:

Mr. Berners-Lee smiled and admitted he might make one change — a small one. He would get rid of the double slash “//” after the “http:” in Web addresses. The double slash, though a programming convention at the time, turned out to not be really necessary, Mr. Berners-Lee explained. Look at all the paper and trees, he said, that could have been saved if people had not had to write or type out those slashes on paper over the years — not to mention the human labor and time spent typing those two keystrokes countless millions of times in browser address boxes. (Today’s browsers, of course, automatically fill in the “//” preamble when a user types a Web address.)

URLe mają poważne wady

W komentarzu NYT jest mowa o tym, że współczesne przeglądarki pozwoliły ominąć tę niedogodność – same uzupełniają adresy o niezbędny przedrostek http czy https. Nie jest to jedyna ingerencja w korzystanie z URLa, jaką możemy dziś obserwować – wydaje mi się, że URL jest dziś w dość dużym kryzysie i w codziennej praktyce korzystania z Webu (czy raczej bycia w nim) coraz częściej obywamy się bez niego. Oto tak wyglądają dziś wyniki wyszukiwania w Google:

Adresy wyszukanych stron Google zamieniło na coś w rodzaju okruszków (a prezentacja witryny wygląda jak reklama). Dlaczego to robi? Skąd ta niechęć do starego i chyba sprawdzonego rozwiązania jakim jest URL?

They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity.

tak wypowiada się na temat aktualnego statusu URLi przedstawiciel zespołu pracującego nad rozwojem przeglądarki Chrome. URLe mają nie być użyteczne – trudno je zrozumieć, łatwo zmanipulować; to też wyzwanie wobec prywatności użytkowników, skoro w adresach da się przesyłać zapytania (query, np. ksiazki?id=100) i można je podejrzeć, choćby w historii przeglądarki.

Content addressing

Nawet gdyby użytkownicy internetu zaczęli masowo zwracać uwagę na to, z jakich adresów URL chcą skorzystać i czy są one bezpieczne, taka postać identyfikacji zasobów online zawsze będzie posiadała pewną założycielską wadę. URL to identyfikacja przez lokalizację, co oznacza, że dwa identyczne pliki (np. obrazek .jpg z kotem ważący 230kB), znajdujące się na dwóch różnych serwerach, będą traktowane jako różne. Problem ten dotyczy też całych witryn i ma związek z personalizacją Webu: dwie osoby wchodzące na facebook.pl zobaczą faktycznie dwa różne serwisy – może zgadzać się będzie interfejs, ale zawartość będzie już różna. Ale w adresie URL nie będzie śladu tej różnicy.

W niektórych pomysłach na reformę Webu, rozwijanych w odpowiedzi na dominację wielkich komercyjnych stref takich Facebooka, Amazona czy Google’a i, proponuje się rozwój koncepcji URLi w takim kierunku, żeby nie polegały one wyłącznie na lokalizacji. Mówimy tu o content addressing, adresowaniu odwołującym się nie do miejsca pliku w jakiejś witrynie, ale do jego zawartości:

content addressing guarantees that the links will always return the same content

bez względu na to, gdzie ta treść będzie umieszczona. W praktyce Content adressing polega na hashowaniu treści pliku (czyli przetworzeniu jego zawartości na zestaw znaków wygenerowanych za pomocą jakiegoś algorytmu szyfrującego, np. SHA-3.

W przykładzie z plikiem graficznym wdrożenie identyfikacji przez zawartość wyglądałoby tak: oto mam jeden plik, który – skopiowany w tej samej jakości, z zachowaniem metadanych itp. – pojawia się w dwóch różnych miejscach i pod różnymi adresami URL. Dla HTTP to dwa różne zasoby, ale dla protokołów pozwalających identyfikować zasoby przez content adressing to jeden, ten sam plik:

plik lokalizacja (przez HTTP) identyfikator (np. przez IPFS)
kot.jpg http://adres.pl?obrazek=kot.jpg c05ebf3546fdc0037ac8e8d592004c7…
koty.jpg https://domena.org/k/koty.jpg c05ebf3546fdc0037ac8e8d592004c7…

Takie rozwiązanie pozwala przy tym na sprawdzanie integralności linkowanych zasobów – kiedy zmienia się hash wiemy, że zmieniła się zawartość pliku. Więcej na ten temat można przeczytać np. tutaj – dla protokołu IPFS zamiennikiem URLi będzie CID (content identifier). Content adressing to też duże wsparcie dla archiwistyki webowej – w protokołach opartych o sieci P2P mamy do czynienia z archiwizacją każdej zmiany w plikach i rozproszonym zabezpieczaniem zasobów.

Jeśli zainteresował Cię ten wpis, podziel się nim w mediach społecznościowych. Zachęcam też do zapisania się do newslettera. Dobrego nowego roku!

Przeczytaj także:

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Akceptowane są wyłącznie komentarze merytoryczne. Każdy komentarz podlega moderacji.

Udostępnij na Twitterze | Udostępnij na Facebooku