Bez Disqusji!

Od dłuższego czasu popularność na różnych blogach zdobywa Disqus[1], czyli niezależny od platformy blogowej system komentowania. Nie dziwi mnie to specjalnie, bo Disqus jest dość wygodny. Zalogować się do systemu można przez „wielką trójkę”, czyli Twittera, Facebooka i Google. Oczywiście można też mieć osobne konto tylko na Disqus. Można w końcu komentować jako gość. Dodatkowo komentarze ułożone są w estetyczny i sensowny sposób, z wątkowaniem. Na deser jest jeszcze głosowanie, udostępnianie komentarzy w mediach społecznościowych, możliwość otrzymywania powiadomień o odpowiedziach mailem czy ustawienia moderacji. Cud, miód i orzeszki po prostu. Szczególnie, jeśli porówna się to z wynalazkami wymyślonymi odnośnie komentarzy przez niektóre serwisy blogowe. Rozwiązanie fajne do tego stopnia, że np. Tumblr w ogóle nie ma komentarzy na blogach i Disqus jest jedyną opcją na komentarze tamże. Przyznam, że i ja się skusiłem na moim tumblrowym blogu na to rozwiązanie.

Do niedawna[2] nie zwracałem na to szczególnej uwagi, ale postanowiłem dodać komentarz na blogu Łukasza Bromirskiego. Komentarz zawierał sporo URLi do polskich około technicznych blogów pracowicie wygrzebanych z mojego czytnika RSS (nie wiem co Łukasz planuje, ale możecie podrzucić blogi, których nie ma na liście, czy Łukaszowi, czy tutaj w komentarzu). Ponieważ od jakiegoś czasu nie ograniczam się do podpisu, tylko loguję, na koniec edycji postanowiłem się zalogować. Nawet się udało, tyle, że cała treść komentarza zniknęła. Uśmiechnąłem się tylko, bo przecież od dawna na takie okazj mam Lazarusa (polecam!). I zonk! Lazarus nie radzi sobie z Disqus. Pewnie dlatego, że Disqus to nie typowy formularz na stronie, a javascript. W każdym razie musiałem przepisywać.

Potem było tylko weselej. Wysyłam komentarz i nie ma. Nie wiadomo, czy błąd po stronie Disqusa i komentarz należy uznać za MIA, nie przeszedł przez wbudowany antyspam (w końcu bardzo dużo linków w treści, szczególnie patrząc na stosunek linki/treść) czy po prostu nie przeszedł przez moderację. W każdym razie napisałem i nie ma. I tak jakoś trzy razy (przyznaję, cierpliwy jestem).

Zacząłem się zastanawiać nad tematem i doszedłem do wniosku, że korzystanie z Disqus powoduje implikacje dotyczące wolności i prywatności. Ameryki w tym momencie nie odkrywam, bo część jest opisana w artykule na Wikipedii w części dotyczącej kontrowersji Disqus. Zatem do ograniczeń wolności i prywatności przez Disqus[3]:

  • Obecność na wielu stronach powoduje możliwość śledzenia użytkowników, nie tylko komentujących, ale po prostu odwiedzających strony. Dodatkowo w przypadku komentujących możliwe jest łatwe śledzenie ich zainteresowań i poglądów. Jeśli chodzi o odwiedzających, można to minimalizować przy pomocy wtyczek do przeglądarek typu NoScript, Adblock czy Ghostery. Śledzącym może być Disqus, ale może też chodzić o śledzenie wszystkich komentarzy jednego użytkownika przez innego.
  • Możliwość cenzurowania komentarzy, zarówno w momencie ich zamieszczania, jak i wstecznie. Czy to po słowach kluczowych, autorze, IP z którego jest zamieszczany komentarz… W sumie, w skrajnym wypadku, możliwa byłaby nawet zmiana treści i mamy gotową sytuację z Rok 1984 – szybko można zmienić treść czyjegoś komentarza, by odzwierciedlał obecnie poprawną linię. Można oczywiście podpisywać komentarze przy pomocy PGP. Przynajmniej dopóki Disqus nie odrzuci ich z automatu. 😉
  • Brak możliwości backupu bloga z komentarzami. Proste rozwiązania do backupu bloga nie zadziałają, a przynajmniej nie w 100%. Nie udało mi się pobrać przy pomocy wget tak, by mój komentarz z linkami był widoczny.
  • Zamknięcie Disqus (albo nawet prosta zmiana typu modny ostatnio paywall) spowoduje, że komentarze na wielu stronach, które IMO w przypadku blogów są istotną częścią strony, bezpowrotnie znikną. Obejściem jest regularne robienie backupu komentarzy przez administratora strony. W XML, Disqus way.

I co w związku z tym? W sumie nic, nie przestałem korzystać z Disqus jako autor bloga (skoro już się pojawił kiedyś), nie zlikwidowałem konta na Disqus. Nawet nie zapowiem, że nic nie skomentuję przy jego pomocy. Ale szanse na użycie przeze mnie tego systemu komentarzy drastycznie spadły. Na pewno (na 99,9%) nie wykorzystam go w kolejnym projekcie. Jak widzę, że wpis jest na blogu z podpiętym Disqus, to generalnie nie komentuję. A ponieważ komentowanie (a przynajmniej jego możliwość) jest dla mnie istotną częścią blogowania, to będzie to uwzględnione przy następnej czystce feedów RSS.

[1] Taki eufemizm, bardziej można by go nazwać monopolistą – Wikipedia podaje badanie wskazujące na 75% udziału na stronach wykorzystujących zewnętrzne (3rd party) systemy komentowania. Aż dziwne, że znaleźli niszę, w końcu Facebook takes it all. Przy czym do tej pory kojarzyłem go raczej na zachodnich blogach, ostatnio patrząc w RSS zwróciłem uwagę i na polskich też się rozpanoszył.

[2] No dobra, nie tak niedawna, bo chodziło o ten wpis (BTW chyba nic nie wynikło, a szkoda) – jak widać prawie pół roku połowiczny szkic tej notki przeleżał…

[3] Będzie czarnowidztwo i paranoizowanie, przynajmniej chwilami. Zostaliście ostrzeżeni.

Dziura w OpenSSL, o jakiej się nie śniło

No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda „tylko” 64kB i „tylko” związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służy… Wyciec mogą klucze (jeśli nie zostaną zmienione, to w przypadku ich przechwycenia będzie można podsłuchać transmisję nawet po aktualizacji biblioteki), loginy i hasła (jeśli użytkownicy nie zmienią haseł, to atakujący będzie mógł się dostać do serwisów nawet po zmianie certyfikatów i aktualizacji biblioteki).

Heartbleed

Źródło: http://heartbleed.com/

Błąd związany z OpenSSL w Debianie sprzed blisko 6 lat to przy tej dziurze pikuś – wtedy wystarczyło zaktualizować pakiet i zmienić klucze. Teraz na dobrą sprawę należałoby zmienić wszystkie certyfikaty SSL (o ile były używane na choć jednej podatnej maszynie) i skłonić wszystkich użytkowników do zmiany haseł. Niekoniecznie technicznych użytkowników, dodajmy.

Ważne jest to o tyle, że niektóre popularne polskie serwisy oferujące darmową (i nie tylko) pocztę były podatne. I to dość długo (nie wiem, czy nadal nie są). Jeśli atakujący uzyska dostęp do poczty, a używamy tej skrzynki do przypominania hasła w innych serwisach to zmiana w nich haseł nie rozwiązuje problemu.

Dodatkowo sprawdzanie podatności systemów było utrudnione. Popularny test sprawdzający podatność na atak z powodu obciążenia zgłaszał… false negatives. Czyli system był podatny, a narzędzie testujące twierdziło, że jest OK. I to w pewnym momencie, wg moich obserwacji, w jakichś 9x% prób… Problemu tego nie miało narzędzie CLI, ale dość szybko przestało ono być dostępne. Zapewne dlatego, że skutkiem ubocznym tego narzędzia był zrzut pamięci i dostęp do wrażliwych danych.

Na koniec mały paradoks. Systemy, w których logowanie było bez szyfrowania nie są podatne na dziurę (za to były i są podatne na podsłuchanie transmisji). Podobnie jak Debian Squeeze, czyli oldstable, któremu wkrótce skończy się support bezpieczeństwa. Użyta w nim wersja OpenSSL jest na tyle stara, że nie jest podatna.

Na razie status jest taki, że jest dostępna poprawka, załatana jest część systemów (wczoraj o ok. 17 było naprawdę sporo dziurawych). Widziałem tylko jedną firmę (polską), która poinformowała o błędzie użytkowników i zaleciła zmianę certyfikatów (ale już ani słowa o hasłach). Osobiście zalecam zwykłym użytkownikom w tej chwili zmianę ważniejszych haseł (zwł. pocztowych!) i obserwację sytuacji. Gdy opadnie kurz, tj. administratorzy załatają systemy i wymienią certyfikaty – ponowna zmiana haseł, tym razem wszystkich (ale naprawdę wszystkich wszystkich).

Błędowi poświęcona jest specjalna strona i tam odsyłam po szczegóły. Tak jeszcze patrzę na to, co napisałem parę lat temu i chyba tekst dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie łapie się na jakieś motto.

UPDATE: Ważna uwaga, o której zapomniałem. Jeśli aktualizujemy OpenSSL w systemie, to trzeba jeszcze zrestartować usługi. W Debianie można skorzystać z polecenia checkrestart (pakiet debian-goodies), ale na przynajmniej jednym systemie pokazywał, że nie ma nic do restartu, choć był apache i zabbix-server. Można zamiast tego użyć:

lsof -n | grep ssl | grep DEL

Dyn.com kończy świadczenie darmowych usług

Dla mnie konto na dyn.com skończyło się wcześniej, dziś ogłosili na blogu, dlaczego zdecydowali się zaprzestać świadczenia darmowych usług w ogóle. Przyznam, że byłem zadowolony w tym wąskim zakresie, w jakim korzystałem, ale dopiero sposobem wyłączenia i rozłożeniem go w czasie mnie ujęli. PRowo jak dla mnie wzorowo: mocno rozłożone w czasie, narastający poziom trudności w utrzymaniu darmowych usług, możliwość łatwego przejścia na wariant płatny, dobra informacja (OK, to w ich interesie). Last but not least: utrzymanie obiecanych wiecznych darmowych kont wczesnym użytkownikom. Naprawdę uważam za ładnie rozegrane.

Pozostało mi życzyć im powodzenia i podziękować, zatem: thank you, dyn.com. 🙂