- cross-posted to:
- technology@beehaw.org
- cross-posted to:
- technology@beehaw.org
cross-posted from: https://szmer.info/post/267058
Recently I had the idea to cryptographically sign my blog posts with gpg. It came to me while I was thinking about various forms of news fakes, whether intentionally misrepresenting news orgs, individuals, or AI generated by the latest round of eldrich horrors we have unleashed.
The idea itself is simple: By signing the posts you can add trust to the source.
You must log in or register to comment.
Pomysł ogólnie mi się podoba, natomiast mam wrażenie, że bez wsparcia ze strony przeglądarki (np. wtyczka, która pozwala podpisać zawartość dowolnego pola tekstowego, i zweryfikować podpisy elementów na stronie) będzie ciężko.
Ale nie chodzi przecież o przeglądarkę. Chodzi o możliwość udowodnienia, że dany kawałek tekstu pochodzi faktycznie od danej osoby. Nie musi się dziać za każdym razem, tylko wtedy, gdy to naprawdę ważne.
Wydaje się krokiem w dobrym kierunku. Jednak z przeglądarek i xHTMLem, wolałbym więcej przyjęcia XML podpisywania.
Wolałbym w ogóle nie używać XMLa do podpisywania czegokolwiek:
https://coder.earth/post/are-xml-signatures-secureTak, wiem. Łatwo się niewłaściwie postąpić XMLsec. Jest zawsze ten sam problem z ustrukturyzowanymi formatami danych i kryptografią, które można do nich selektywnie zastosować (np. S/MIME ma podobne problemy z treścią
multipart). Ale właściwe postąpienie XMLseca jest możliwe. Cytuję:Does this mean it’s impossible to properly validate an XML signature? No, it’s technically possible.
Kiedy ludzie zaczynają używać GnuPGa w ten sposób, a później próbują majsterkować rozwiązania do podpisywania i werifykacji części stron (np. na stronie przeglądowej zawierającej wiele wpisów na blogu), spodziewałbym się podobnych lub gorszych niewłaściwych użyć kryptografii. Dlatego chciałbym zobaczyć kilka sprawdzonych dobrych praktyk wykorzystujących technologie, które poradzą sobie z ustrukturyzowanymi danymi.
Ja chyba jednak wolałbym podpisywanie Markdowna na przykład, jeśli to jest źródło, z którego się generuje dany wpis. Albo traktowanie HTMLa jako tekstu do celów podpisu.
Przecież jakąś konkretną reprezentację tekstową wysyła się do przeglądarki. A sygnatura nie musi być częścią tych danych, może być w oddzielnym pliku.
Świetny pomysł. Ale Markdown może mieć podobny problem:
Niektóre implementacje mają dyrektywę
@do dołączania i renderowania innych plików Markdowna. Pojawiłyby się one na renderowanej stronie, nie będąc podpisane. Może to być (np. w przypadku komentarzy na blogu innych osób zapisywanych w osobnych plikach) lub może nie być zamierzone i stwarza sytuację podobną do XMLsec i S/MIME, gdzie podpisanie czegoś niekoniecznie oznacza, że użytkownik rozumie, co zostało podpisane.Nawet standardowy Markdown obsługuje w tym obrazy, których treść również nie byłaby podpisana.
Oczywiście można ograniczyć jakie funkcje Markdown powinny być używane, aby zminimalizować niespodzianki związane z podpisami. Ale wtedy nie widzę żadnej technicznej różnicy we wstępnie zdefiniowaniu struktury dokumentu XMLsec.
Podpisywanie renderowanego wyjścia nie ma tego problemu, ale nie powiedziałbym, że jest automatycznie lepsze. Oznacza to, że wszystkie rodzaje wyprowadzonych wyjść renderujących również powinny być podpisane, co z kolei zwiększa prawdopodobieństwo błędu ludzkiego po stronie osoby podpisującej.
Najważniejsze jest to, że zawsze istnieje kompromis między formatem dokumentu, który jest wyrazisty, a użytkownik może łatwo zorientować się, co zostało podpisane.
