Podwójne standardy

Przy okazji wchodzącej w wielu zakątkach Internetu weryfikacji wieku i protestów z nią związanych, zauważyłem występowanie podwójnych standardów. Chodzi o to, że w świecie fizycznym raczej nikt nie ma problemu z tym, że wiek jest weryfikowany i istnieją ograniczenia wiekowe, a pewne rzeczy dostępne są tylko dla osób pełnoletnich.

Chodzi o możliwość zakupu alkoholu, wyrobów tytoniowych, ostatnio do towarów dostępnych tylko dla pełnoletnich zostały dodane energetyki. Podobnie jest z głosowaniem – czynne prawo wyborcze przysługuje od ukończenia 18 lat. Bierne – jeszcze później.

Tymczasem podnoszony jest argument, że tak nie można, bo prywatność, bo anonimowość, bo wolność. Zastanawiam się jednak, czy anonimowość – czy też: przyzwolenie na nią – mieliśmy do tej pory. Czy możliwość względnej anonimowości pojawiła się dopiero wraz z pojawieniem się Internetu. Przecież idąc do sklepu czy lokalu wyborczego nie jesteśmy anonimowi. Widać, kto kupuje (nawet niekoniecznie towary dostępne od 18 roku życia). W lokalu wyborczym sprawdzana jest tożsamość (i pośrednio wiek) osoby głosującej.

Co więcej, zakaz utrudniania (nawet nie: uniemożliwiania) identyfikacji osoby występuje – już teraz – także w miejscach, gdzie w przypadku uczestnictwa nie ma wymogu ukończenia określonego wieku. Na przykład ustawa o bezpieczeństwie imprez masowych mówi:

Art. 57a. Kto w miejscu i w czasie trwania masowej imprezy sportowej używa
elementu odzieży lub przedmiotu w celu uniemożliwienia lub istotnego utrudnienia rozpoznania osoby, podlega karze ograniczenia wolności albo grzywny nie niższej niż 2000 zł.

Czyli nie można anonimowo kibicować drużynie sportowej. I jakoś nikt nie robi o to afery, prawda?

Podobnie jest z rejestracją kart SIM. Obowiązek rejestracji mamy od około dekady. Jest to ograniczenie anonimowego dostępu do komunikacji telefonicznej, internetu oraz SMSów. Oraz niejawny wymóg weryfikacji wieku. Osoba poniżej 18 roku życia może zarejestrować kartę SIM, o ile ukończyła 13 lat i posiada dowód osobisty. Ten uprawniający do rejestracji karty SIM można mieć po ukończeniu 13 roku życia ale… za zgodą rodziców.

Realny, odczuwalny wpływ w przypadku kart SIM? Dla przytłaczającej większości obywateli żaden. Anegdotycznie, słyszałem, że po wprowadzeniu obowiązku rejestracji kart SIM, osoba zarządzająca w branży budowlanej przestała dostawać telefony z pogróżkami w weekendy od niekoniecznie trzeźwych expracowników.

Dyskusja nt. weryfikacji wieku online mogłaby być znacznie bardziej konstruktywna, gdybyśmy przestali stosować podwójne standardy…

Instrukcje były niejasne

Czasem na LinkedIn, z którego coraz mniej korzystam, pojawi się ciekawa dyskusja[1]. Zaczęło się od LLMów i stwierdzenia, że AI nie umie dotrzymać tajemnicy, każdy model LLM w końcu ujawni coś, czego nie powinien. Trochę wzięło mnie na filozofowanie i szukanie analogii, efektem jest myśl, którą parę osób uznało za trafną/interesującą, więc, żeby nie zginęła, niech będzie i tu.

Generalnie większość ludzi jest zgodna, że faktycznie tak jest i LLMy „ciekną” sekrety. Trochę zeszło na no ale tu wyraźne instrukcje były, żeby tego nie robił. Czyli klasyczne, że nie LLMy się nie nadają do danego zastosowania, tylko, a może zły prompt, a może zły model, a może tory złe…

Widzę to nieco inaczej, a różnica jest fundamentalna. Podobnie jak w LLMy nie kłamią trzeba przestać traktować LLMy jak maszyny deterministyczn czy myślące. W zamian trzeba cały czas pamiętać, że pod spodem jest to jednak złożony, ale proces stochastyczny.

Dlatego instrukcje, które dajemy LLMom nie są przepisem na ciasto, który zostanie odtworzony przez człowieka. Nie są algorytmem/programem, który zostanie wykonany precyzyjnie w określony, zawsze taki sam sposób, jak ma to miejsce w tradycyjnych programach. Czyli nie są dla „odbiorcy”, czyli modelu LLM ścisłą instrukcją, choć wydaje nam się, że są.

Czym zatem są? Wydaje mi się, że najbliższą analogią, którą znamy z życia są… przykazania religijne. Wg twórcy są precyzyjne, nie ma problemu z ich przestrzeganiem i powinny być przestrzegane. W praktyce jest z tym różnie. Mogą być różnie zrozumiane, zinterpretowane, czy wreszcie po prostu zignorowane. Nawet jeśli większość wyznawców ich przestrzega, to znajdą się przypadki, gdy nie są przestrzegane. Analogicznie zachowują się LLMy. Co któreś uruchomienie, w odpowiednich okolicznościach, znajdzie się taka instancja LLMa, która „złamie”[2] otrzymane instrukcje. I według mnie należy to po prostu przyjąć jako cechę rozwiązań opartych o LLMy.

[1] Bo ważne jest, z kim się rozmawia, nie gdzie.
[2] Cudzysłów, bo złamanie oznaczałoby konieczność zrozumienia, co nie zachodzi.

gocryptfs

Dawno, dawno temu przestałem używać EncFS. Przestałem z kilku powodów. Po pierwsze, pojawiło się ostrzeżenie o tym, że nie jest to rozwiązanie do końca bezpieczne. Niby nic i w moich zastosowaniach nie przeszkadzało[1], ale jakaś tam zadra w pamięci i niechęć zostały. Po drugie, zwykłe dyski zacząłem szyfrować „normalnie” przy pomocy LUKS. A backupy itp. przy pomocy GPG. Dziś odkryłem godnego następcę: gocryptfs.

Mimo zmian w używanym szyfrowaniu, po EncFS została jedna dziura: dyski zdalne typu Dropbox czy Google drive. Miło by było móc z nich korzystać „normalnie”, ale tak, żeby dane na tych dyskach były zaszyfrowane. LUKS tu nie pomoże, bo działa dla dysków lokalnych. Szyfrowanie przez GPG dla pojedynczych plików jest niewygodne, a pakowanie w jakieś archiwa jest dobre do backupów, nie do normalnego korzystania. EncFS jako overlay dostępny poprzez FUSE ze swoim szyfrowaniem per katalog był idealny. Nie trzeba z góry określać rozmiaru szyfrowanych danych, dostęp online do pojedynczych plików, z zachowaniem ich struktury.

Okazuje się, że jest godny następca dla EncFS i nazywa się gocryptfs. Nie wiem czemu nie znalazłem go wcześniej. Może odrzuciłem, bo był świeży i w golang? Może przeważył brak realnej potrzeby?

W każdym razie: jest i wygląda bardzo dobrze. Przeczytałem opis projektu i zasadę działania. Posiada sensowne założenia, był audytowany, brak przypadłości EncFS. Do tego jest bardzo szybki. Instalacja w Debianie z pakietu – żadnych kompilacji. Do tego świetna dokumentacja, proste użycie i… dopracowanie. Oczywiście open source. Działa na Linuksie, macOS, istnieją nieoficjalne porty dla Windows i Androida.

Żeby przybliżyć o czym mowa. Weźmy takie utworzenie szyfrowanego katalogu. Jedno proste polecenie, podajemy hasło, powtarzamy je i… dostajemy master key, wraz z przeznaczeniem i jak się z nim obchodzić. Aż pokażę[2], bo na stronie tego nie ma:

$ gocryptfs -init cipher/
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

d28966ae-f39ff48a-695993f9-a5e354eb-
3d31e7a1-29c834c5-31b2cb3b-b38b6cec

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipher MOUNTPOINT

Prawda, że piękne? Bardzo możliwe, że przyda się i wkrótce wrócę do tematu zdalnych dysków.

[1] Moje zastosowania: nie będą mi dyski sieciowe w stylu Dropbox grzebać po plikach, nawet jeśli nic tajnego tam nie ma.
[2] Jakby ktoś zaczynał panikować, że „ojej, master key podał” to spieszę donieść, że to z testowego katalogu utworzonego na potrzeby tego wpisu, żadnych danych tam nie ma i nie będzie.