<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Firefox on Morfitronik</title>
    <link>https://morfikov.github.io/tags/firefox/</link>
    <description>Recent content in Firefox on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Thu, 22 Jan 2026 14:55:00 +0100</lastBuildDate><atom:link href="https://morfikov.github.io/tags/firefox/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak Video DownloadHelper (VDH) zabija dyski SSD (Firefox/Chrome)</title>
      <link>https://morfikov.github.io/post/jak-video-downloadhelper-vdh-zabija-dyski-ssd-firefox-chrome/</link>
      <pubDate>Thu, 22 Jan 2026 14:55:00 +0100</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-video-downloadhelper-vdh-zabija-dyski-ssd-firefox-chrome/</guid>
      <description>&lt;p&gt;Jakiś już czas temu naskrobałem kawałek artykułu na temat &lt;a href=&#34;https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/&#34;&gt;mechanizmu Trim/discard w kontekście
LUKS/LVM na dysku SSD pod Debian linux&lt;/a&gt;, przy okazji poruszając tam kwestie nieco daleko
idącej &lt;a href=&#34;https://morfikov.github.io/post/trim-discard-przy-luks-lvm-na-dysku-ssd-pod-debian-linux/#odci%C4%85%C5%BCenie-dysku-ssd-przez-wykorzystanie-ramdysk%C3%B3w&#34;&gt;optymalizacji systemu pod kątem przedłużenia żywotności tego typu dyskom opartym o
technologię flash&lt;/a&gt;. Opisane w tym powyższym artykule zabiegi sprawiły, że zapis danych na tym
dysku systemowym waha się w okolicy 3 GiB na dzień (średnia za rok 2024 i 2025). Gdyby ten stan
rzeczy utrzymać, to ten dysk SSD posłużyłby jeszcze przez około 160 lat i taka żywotność nośnika
SSD mnie jak najbardziej zadowala... Przez te dwa ostatnie lata tylko kilka aplikacji chciało
zapisywać ogromne ilości danych na dysku systemowym bez wyraźnej przyczyny, np &lt;a href=&#34;https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058022&#34;&gt;QuiteRSS&lt;/a&gt;, a tak
poza tym, to ten dysk SSD nie wykazywał większych odchyłów od normy w kwestii zapisu danych.
Niestety ten stan rzeczy uległ zmianie kilka dni temu. Szukając przyczyny udało się zawęzić krąg
podejrzanych do przeglądarki Firefox (ewentualnie też Google Chrome i Chromium). Okazało się, że
jeden z jej dodatków, a konkretnie &lt;a href=&#34;https://github.com/aclap-dev/video-downloadhelper&#34;&gt;Video DownloadHelper&lt;/a&gt; (VDH), z jakiegoś powodu zapisuje
ogromne ilości danych w katalogu profilu tej przeglądarki (tj. w &lt;code&gt;~/.mozilla/firefox/&lt;/code&gt; ).
Pobierając dużo materiałów audio/video, np. z YouTube czy CDA, bardzo szybko nam taki dysk SSD
padnie i to bez znaczenia czy docelowy katalog zapisu pobranych danych z internetu mamy ustawiony,
np. na osobnym dysku HDD. Czy istnieje zatem jakiś sposób, który by powstrzymał dodatek Video
DownloadHelper od zniszczenia nam dysku SSD?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak włączyć w Firefox ESNI (Encrypted SNI)</title>
      <link>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</link>
      <pubDate>Mon, 10 Aug 2020 18:15:00 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wlaczyc-w-firefox-esni-encrypted-sni/</guid>
      <description>&lt;p&gt;Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_HTTPS&#34;&gt;DNS over HTTPS&lt;/a&gt;)
lub DoT (&lt;a href=&#34;https://en.wikipedia.org/wiki/DNS_over_TLS&#34;&gt;DNS over TLS&lt;/a&gt;). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego
kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia),
poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej
jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie
ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że
ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy &lt;code&gt;https://&lt;/code&gt; ) z wykorzystaniem
protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication&#34;&gt;Server Name
Indication&lt;/a&gt;), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu
certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może
szyfrować ruch niezależnie od siebie na linii serwer&amp;lt;-&amp;gt;klient (używać innych kluczy szyfrujących).
Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym
do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam
przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto
podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony
internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (&lt;a href=&#34;https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello&#34;&gt;Encrypted Client
Hello&lt;/a&gt;) oraz ESNI (&lt;a href=&#34;https://tools.ietf.org/html/draft-ietf-tls-esni-07&#34;&gt;Encrypted SNI&lt;/a&gt;), które mają zaadresować problemy związane z prywatnością
przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie.
Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z
CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i
wdrożyć na swoim linux&#39;ie to rozszerzenie ESNI dla przeglądarki Firefox.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Mechanizm trigger&#39;ów dla apt/aptitude w Debianie</title>
      <link>https://morfikov.github.io/post/mechanizm-trigger-dla-apt-aptitude-w-debianie/</link>
      <pubDate>Sun, 14 Apr 2019 00:10:11 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/mechanizm-trigger-dla-apt-aptitude-w-debianie/</guid>
      <description>&lt;p&gt;Czasami pewna niestandardowa konfiguracja naszego linux&#39;a może sprawiać pewne problemy podczas
aktualizacji zainstalowanych w nim pakietów. Dla przykładu, wykorzystując mechanizm AppArmor do
okrojenia profilów Firefox&#39;a, muszę tworzyć osobne twarde dowiązania do binarki tej przeglądarki.
Te dowiązania mają taki problem, że jak usunie się plik, na który wskazywały, np. podczas
aktualizacji paczki, to utworzenie pliku w tym samym miejscu przez menadżer pakietów
&lt;code&gt;apt&lt;/code&gt;/&lt;code&gt;aptitude&lt;/code&gt; nie sprawi, że te dowiązania zaczną ponownie funkcjonować poprawnie (tak jak to
jest w przypadku dowiązań symbolicznych). Z początku usuwałem te stare dowiązania i tworzyłem nowe
ale postanowiłem w końcu &lt;a href=&#34;https://forum.dug.net.pl/viewtopic.php?id=30382&#34;&gt;poszukać rozwiązania&lt;/a&gt;, które by zautomatyzowało cały ten proces i
uczyniło go transparentnym dla użytkownika końcowego. Tak natrafiłem na mechanizm Debianowych
trigger&#39;ów (&lt;a href=&#34;https://manpages.debian.org/unstable/dpkg-dev/deb-triggers.5.en.html&#34;&gt;deb-trigger&lt;/a&gt;), które aktywują się za każdym razem ilekroć pliki w konkretnych
ścieżkach są ruszane w jakiś sposób przez menadżer pakietów. W tym artykule spróbujemy sobie
zaprojektować taki trigger i obadać czy może on nam się w ogóle do czegoś przydać&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Uruchamianie graficznych aplikacji w kontenerach Docker&#39;a</title>
      <link>https://morfikov.github.io/post/uruchamianie-graficznych-aplikacji-w-kontenerach-dockera/</link>
      <pubDate>Sun, 27 Jan 2019 11:32:18 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/uruchamianie-graficznych-aplikacji-w-kontenerach-dockera/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://morfikov.github.io/post/jak-uruchomic-firefoxa-w-osobnej-przestrzeni-nazw-sieciowych/&#34;&gt;Bawiąc się ostatnio na Debianie przestrzeniami nazw sieciowych&lt;/a&gt;,
wpadł mi do głowy pomysł na nieco bardziej zautomatyzowaną formę separacji procesów użytkownika od
pozostałej części systemu. Co by nie mówić, opisany w podlinkowanym artykule sposób uruchomienia
Firefox&#39;a niezbyt mi przypadł do gustu. Nowy sposób separacji zakłada za to wykorzystanie
kontenerów Docker&#39;a, w których to będzie uruchamiany dowolny proces, np. Firefox, a całym
przedsięwzięciem związanym z procesem konteneryzacji będzie zajmował się już Docker. W ten sposób
uruchomienie dowolnej aplikacji, w tym też tych graficznych (GUI), będzie sprowadzać się do wydania
w terminalu tylko jednego polecenia. Zatem do dzieła.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak uruchomić Firefox&#39;a w osobnej przestrzeni nazw sieciowych</title>
      <link>https://morfikov.github.io/post/jak-uruchomic-firefoxa-w-osobnej-przestrzeni-nazw-sieciowych/</link>
      <pubDate>Sun, 20 Jan 2019 21:10:32 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-uruchomic-firefoxa-w-osobnej-przestrzeni-nazw-sieciowych/</guid>
      <description>&lt;p&gt;Domyślnie każdy proces uruchomiony na linux (w tym przypadku Debian) dziedziczy swoją przestrzeń
nazw sieciowych (network namespaces) od procesu nadrzędnego, standardowo od procesu init (tego z
pid 1). W takim przypadku, wszystkie procesy współdzielą tę samą przestrzeń nazw sieciowych, przez
co mają dostęp do tych samych interfejsów sieciowych, tych samych tras routingu, a reguły
firewall&#39;a czy ustawienia serwerów DNS w jednakowym stopniu dotyczą wszystkich procesów i
zmieniając sieciową konfigurację systemu robimy to globalnie dla wszystkich tych procesów
jednocześnie. Czasami tego typu mechanika działania sieci nie jest zbyt pożądana z punktu
widzenia bezpieczeństwa lub też prywatności użytkownika. Przykładem mogą być przeglądarki
internetowe, np. Firefox, Opera czy Google Chrome/Chromium, które mogą zdradzić nasz lokalny adres
IP (w przypadku stosowania NAT). Jako, że też zostawiamy wszędzie nasz namiar w postaci
zewnętrznego adresu IP, to oba te adresy mogą nas bez większego problemu zidentyfikować w
internecie. Można jednak postarać się, by ten adres lokalny, który zwróci przeglądarka
internetowa, różnił się od tego, który przydziela nam nasz operator ISP.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zrobić screenshot całej strony www w Firefox</title>
      <link>https://morfikov.github.io/post/jak-zrobic-screenshot-strony-www-firefox/</link>
      <pubDate>Mon, 22 Aug 2016 08:38:58 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zrobic-screenshot-strony-www-firefox/</guid>
      <description>&lt;p&gt;Każdy z nas potrafi raczej zrobić prostego &amp;quot;skrina&amp;quot; tego co wyświetla się w danej chwili na ekranie
naszego komputera. Nie jest to jakaś zaawansowana wiedza i wystarczy przycisnąć przycisk PrintScreen
na klawiaturze i zrzut ekranu powinien zostać przechwycony przez system i zwykle gdzieś zapisany.
Niemniej jednak, strony www w przeglądarce internetowej bardzo rzadko są nam pokazywane w całej
swojej okazałości. Zwykle mamy po prawej stronie pasek przewijania (scrollbar), za pomocą którego
możemy przewinąć stronę w górę lub w dół. Pojawia się zatem pytanie: jak w takiej sytuacji zrobić
screenshot całej strony www? Można, co prawda, przewinąć stronę kilka razy, zrobić zrzut każdego
kawałka i scalić obraz w jakimś programie graficznym ale raczej za dużo z tym zachodu. Można także
zaprzęgnąć jakiś plugin do przeglądarki, np. Firefox ma na wyposażeniu &lt;a href=&#34;https://addons.mozilla.org/en-us/firefox/addon/screenshot-capture-annotate/&#34;&gt;Awesome
Screenshot&lt;/a&gt;. Istnieje
jednak prostsza alternatywa i do tego natywnie zaimplementowana w Firefox&#39;ie. Mowa o &lt;a href=&#34;https://developer.mozilla.org/en/docs/Tools/GCLI&#34;&gt;wierszu
poleceń Firefox&#39;a&lt;/a&gt;. W tym krótkim wpisie
zobaczymy jak przy pomocy tego narzędzia w bardzo prosty sposób zrobić fotkę całej witryny www.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Baza danych pozwoleń w Firefox&#39;ie (permissions.sqlite)</title>
      <link>https://morfikov.github.io/post/baza-danych-pozwolen-firefox-permissions-sqlite/</link>
      <pubDate>Sun, 17 Jul 2016 21:43:14 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/baza-danych-pozwolen-firefox-permissions-sqlite/</guid>
      <description>&lt;p&gt;Praktycznie każda przeglądarka, w tym też i Firefox, oferuje możliwość nadania określonym domenom
praw dostępu do zasobów systemowych. Chodzi generalnie o wykorzystywanie wtyczek, np. flash, które
są aktywowane na danej stronie internetowej jeśli ta ich potrzebuje. Po części też sprawa dotyczy
korzystania z urządzeń takich jak wbudowane w laptop kamera i mikrofon oraz szeregu dodatkowych
rzeczy, np. ciasteczka, pop-up&#39;y i inne takie. Obecnie Firefox standardowo blokuje dostęp do
pluginów, a gdy zachodzi potrzeba skorzystania z któregoś z nich, to zostaje nam zaprezentowane
okienko, w którym możemy zdecydować co zrobić. Gdy często odwiedzamy daną witrynę, to naturalnie
prosimy naszą przeglądarkę, by ta zapisała ustawienia dla tej strony. Firefox robi to przez dodanie
wyjątku w pliku &lt;code&gt;permissions.sqlite&lt;/code&gt; . W sporej części przypadków będziemy mogli cofnąć pozwolenia w
dość prosty sposób. Niemniej jednak, nie we wszystkich z nich da się to tak łatwo zrobić.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Systemowy klient Tor w TorBrowser</title>
      <link>https://morfikov.github.io/post/systemowy-klient-tor-w-torbrowser/</link>
      <pubDate>Wed, 02 Mar 2016 15:14:33 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/systemowy-klient-tor-w-torbrowser/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://www.torproject.org/projects/torbrowser.html.en&#34;&gt;TorBrowser&lt;/a&gt; to projekt, który ma na celu zabezpieczenie użytkownika przed przeciekiem
informacji. Jest to połączenie klienta sieci Tor oraz przeglądarki Firefox (plus kilka dodatków).
Ten mechanizm jest tak skonfigurowany, by możliwie jak w największym stopniu dbał o naszą prywatność
podczas przeglądania stron internetowych. Kilka lat wstecz, użytkownicy Firefox&#39;a mogli się
zaopatrzyć w addon TorButton. Niemniej jednak, obecnie &lt;a href=&#34;https://www.torproject.org/docs/torbutton/index.html.en&#34;&gt;ten dodatek nie jest już rozwijany&lt;/a&gt;,
przynajmniej nie jako osobny projekt. Cały ten TorButton został zintegrowany z TorBrowser i nie ma
obecnie sposobu na to, by przeznaczyć jeden profil Firefox&#39;a pod bezpieczne przeglądanie internetu.
Jeśli chcemy mieć taką możliwość, to musimy korzystać z TorBrowser. Nie stanowi to oczywiście
problemu, ale jako że ma on w sobie wbudowanego klienta Tor&#39;a, to uruchamia też pewne procesy, które
mogą okazać się zbędne, zwłaszcza, gdy na swoim linux&#39;ie mamy już systemową instancję Tor&#39;a. W takim
przypadku, przydałoby się wyłączyć tego klienta Tor w TorBrowser, a ruch z przeglądarki przekierować
do systemowego Tor&#39;a i przez ten proces postaramy się przebrnąć w tym wpisie.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Aktualizacja Firefox&#39;a i Thunderbird&#39;a w debianie</title>
      <link>https://morfikov.github.io/post/aktualizacja-firefoxa-thunderbirda-w-debianie/</link>
      <pubDate>Tue, 09 Feb 2016 03:04:34 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/aktualizacja-firefoxa-thunderbirda-w-debianie/</guid>
      <description>&lt;p&gt;W 2006 roku, Mozilla przyczepiła się do debiana o to, że ten &lt;a href=&#34;https://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project&#34;&gt;wykorzystuje ich znaki
towarowe&lt;/a&gt;.
Chodziło głównie o to, że debian wprowadzał swoje poprawki, które nie były zatwierdzone przez zespół
Mozilli. W efekcie czego, debian pozmieniał nazwy szeregu produktów Mozilli i tak zamiast normalnego
Firefox&#39;a mamy Iceweasel, podobnie z Thunderbird&#39;em i Icedove. Obecnie nie ma możliwości wgrania
aplikacji Mozilli wykorzystując repozytorium debiana. Trzeba się trochę wysilić i paczki pobierać
ręcznie z serwerów Mozilli. Takie rozwiązanie nie jest zbytnio praktyczne, bo przecie w linux&#39;ie
aplikacji nie aktualizuje się za pomocą ich interfejsów graficznych. Jeśli tak by było, to
musielibyśmy uruchamiać przeglądarkę z uprawnieniami root w trybie graficznym, czego raczej nikt
rozsądny nie próbowałby robić. Można, co prawda, napisać skrypt i całą operację aktualizacji nieco
zautomatyzować. Problem w tym, że zarówno Firefox jak i Thunderbird ważą tak około 50 MiB każdy i
taka aktualizacja polegająca na pobraniu całej aplikacji i zainstalowaniu jej na nowo zjadłaby
trochę transferu. Istnieje jednak rozwiązanie, które zakłada wykorzystanie &lt;a href=&#34;https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file&#34;&gt;plików
MAR&lt;/a&gt;. Ważą one zaledwie
kilka MiB, bo zawierają jedynie aktualizację danej aplikacji. W tym wpisie spróbujemy się przyjrzeć
procesowi aktualizacji z wykorzystaniem tych właśnie plików.&lt;/p&gt;
&lt;p&gt;Zgodnie z &lt;a href=&#34;https://glandium.org/blog/?p=3622&#34;&gt;informacją na tym blogu&lt;/a&gt;, Firefox wraca do debiana i
zastępuje tym samym Iceweasel. Od tego momentu można już instalować pakiet &lt;code&gt;firefox&lt;/code&gt; i cieszyć się
normalnym produktem Mozilli. Niniejszy artykuł w dalszym ciągu znajduje zastosowanie ale nie można
mieszać opisanego niżej sposobu aktualizacji Firefox&#39;a z tym dostarczanym w ramach menadżera
pakietów &lt;code&gt;apt&lt;/code&gt;/&lt;code&gt;aptitude&lt;/code&gt; . Zatem albo instalujemy Firefox&#39;a bezpośrednio z repozytorium debiana,
albo ściągamy pakiet z serwerów Mozilli.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Metadane plików graficznych (EXIF)</title>
      <link>https://morfikov.github.io/post/metadane-plikow-graficznych-exif/</link>
      <pubDate>Thu, 21 Jan 2016 16:58:55 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/metadane-plikow-graficznych-exif/</guid>
      <description>&lt;p&gt;Każdy plik posiada szereg opisujących go atrybutów. Możemy się o tym przekonać wykorzystując
narzędzia &lt;code&gt;ls&lt;/code&gt; lub &lt;code&gt;stat&lt;/code&gt; . W ich przypadku zostaną nam zwrócone takie informacje jak rozmiar
pliku, data modyfikacji czy też prawa dostępu. To właśnie są metadane opisujące pliki w obszarze
systemu plików i są one wymagane, by system operacyjny działał prawidłowo. To jednak nie jedyne
metadane, z którymi spotykamy się na co dzień. Najlepszym przykładem są zdjęcia czy filmy robione
smartfonami czy też aparatami lub kamerami cyfrowymi. Każdy plik stworzony za pomocą tych urządzeń
zawiera w sobie bardzo rozbudowane informacje, które nie zawsze chcielibyśmy udostępniać. W tym
wpisie skupimy się głównie na &lt;a href=&#34;https://pl.wikipedia.org/wiki/Exchangeable_Image_File_Format&#34;&gt;danych
EXIF&lt;/a&gt; zawartych w plikach graficznych,
które postaramy się wydobyć, zmienić i usunąć.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Konfiguracja cache DNS w Firefox&#39;ie</title>
      <link>https://morfikov.github.io/post/konfiguracja-cache-dns-w-firefoxie/</link>
      <pubDate>Fri, 20 Nov 2015 14:01:17 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/konfiguracja-cache-dns-w-firefoxie/</guid>
      <description>&lt;p&gt;We wpisie poświęconym &lt;a href=&#34;https://morfikov.github.io/post/cache-dns-buforowania-zapytan/&#34;&gt;systemowemu cache DNS w
linux&#39;ie&lt;/a&gt; mieliśmy okazję zobaczyć jak
wzrasta wydajność po zaimplementowaniu tego mechanizmu. W skrócie, to ponad drugie tyle zapytań było
rozwiązywanych lokalnie bez potrzeby odwoływania się do zdalnego serwera DNS, co zajmuje sporo czasu
(20-40ms). Przeglądarki internetowe, np. Firefox, mają swoje wynalazki, które potrafią wyeliminować
opóźnienia związane z surfowaniem po stronach www. Do nich zalicza się również cache DNS, z tym, że
w tym przypadku zaimplementowany jest on na poziomie przeglądarki, a nie globalnie w systemie.
Dzięki temu rozwiązaniu, nawet bez &lt;code&gt;dnsmasq&lt;/code&gt; , Firefox jest nam w stanie zaoszczędzić sporo czasu
przy przeglądaniu internetu. Zajrzyjmy zatem Firefox&#39;owi pod maskę i sprawdźmy, które parametry
dotyczące cache DNS wymagają dostosowania.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Więcej niż jeden profil w Firefox&#39;ie</title>
      <link>https://morfikov.github.io/post/wiecej-niz-jeden-profil-w-firefoxie/</link>
      <pubDate>Thu, 29 Oct 2015 16:50:34 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/wiecej-niz-jeden-profil-w-firefoxie/</guid>
      <description>&lt;p&gt;Ogromna większość ludzi korzysta z jednego profilu swojej przeglądarki internetowej. Niesie to ze
sobą spore zagrożenie bezpieczeństwa jak i może godzić w naszą prywatność. Jeśli dzielimy z kimś
komputer, to raczej wszyscy domownicy posiadają osobne konta w systemie, a co z tym się wiąże, inny
profil przeglądarki. I na tym zwykle podział się kończy ale przecie to nie wszystko. Profil, jak
sama nazwa wskazuje, jest w stanie dostosować opcje przeglądarki, np. pod kątem pewnych aktywności.
W tym wpisie postaramy się utworzyć kilka profili w Firefox&#39;ie i sprawdzimy korzystanie z nich
będzie odczuwalne w jakiś sposób dla przeciętnego użytkownika internetu.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Usuwanie wpisów z about:config w Firefox&#39;ie</title>
      <link>https://morfikov.github.io/post/usuwanie-wpisow-z-aboutconfig-w-firefoxie/</link>
      <pubDate>Tue, 27 Oct 2015 20:58:39 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/usuwanie-wpisow-z-aboutconfig-w-firefoxie/</guid>
      <description>&lt;p&gt;Po wpisaniu w pasku adresu Firefox&#39;a &lt;a href=&#34;http://kb.mozillazine.org/About:config&#34;&gt;about:config&lt;/a&gt; ,
zostanie nam zwrócona dość długa lista parametrów konfiguracyjnych, które możemy sobie dostosować
wedle uznania. Większość z nich ma spory wpływ na zachowanie samej przeglądarki ale są też i opcje,
które zostały dodane za sprawą różnych dodatków. Chodzi o to, że za każdym razem gdy instalujemy
nowy addon, to ten zwykle ma opcje konfiguracyjne i to właśnie one są widoczne w &lt;code&gt;about:config&lt;/code&gt; . W
przypadku gdy już nie korzystamy z tego dodatku i wyrzuciliśmy go kompletnie z Firefox&#39;a, wpisy w
konfiguracji dalej widnieją. Przydałoby się zatem nieco przeczyścić naszą przeglądarkę i usunąć te
wszystkie śmieci.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Pliki .torrent i magnet linki w Firefox&#39;ie</title>
      <link>https://morfikov.github.io/post/pliki-torrent-i-magnet-linki-w-firefoxie/</link>
      <pubDate>Tue, 27 Oct 2015 20:02:45 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/pliki-torrent-i-magnet-linki-w-firefoxie/</guid>
      <description>&lt;p&gt;Przeglądarki mają to do siebie, że każda z nich korzysta z własnych ustawień dotyczących &lt;a href=&#34;https://pl.wikipedia.org/wiki/Typ_MIME&#34;&gt;typów MIME
(mime type)&lt;/a&gt;. Do tego dochodzi jeszcze fakt, że często te ustawienia są inne od tych, które mamy
w systemie. Może to nie jest jakiś wielki problem, bo w opcjach Firefox&#39;a możemy bez trudu szereg
rzeczy poprzestawiać. Natomiast jest jeden problem, którego w prosty sposób się obejść nie da i
trzeba się trochę na nim pochylić. Chodzi o dodawanie nowych typów MIME, które nie są pokazane na
liście obsługiwanych typów w Preferences -&amp;gt; Applications. Wiąże się z tym tak skonfigurowanie
przeglądarki, by automatycznie otworzyła ona jakiś program ilekroć dany typ pliku będzie pobierany.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Klawisz Backspace w Firefox&#39;ie</title>
      <link>https://morfikov.github.io/post/klawisz-backspace-w-firefoxie/</link>
      <pubDate>Sat, 11 Jul 2015 10:12:11 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/klawisz-backspace-w-firefoxie/</guid>
      <description>&lt;p&gt;Przez cały czas korzystania z internetu, robiłem to za pomocą przeglądarki Opera. Nawet po tym jak
przeszedłem na linuxa, to wciąż nie mogłem się z nią rozstać i to pomimo faktu, że nie była ona
przecież opensource, przez co nie była także dostępna w repozytoriach debiana. Gdy deweloperzy z
zespołu Opery przestali rozwijać tę przeglądarkę dla linuxa, musiałem poszukać sobie czegoś innego.
Wybór padł na Firefox&#39;a ale każdy kto używał tych dwóch przeglądarek wie, że różniły się one dość
znacznie parę lat temu i jedną z tych bardziej odczuwalnych różnic była inna obsługa klawisza
Backspace .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Logjam, czyli nowa podatność w SSL/TLS</title>
      <link>https://morfikov.github.io/post/logjam-czyli-nowa-podatnosc-w-ssltls/</link>
      <pubDate>Mon, 25 May 2015 08:12:39 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/logjam-czyli-nowa-podatnosc-w-ssltls/</guid>
      <description>&lt;p&gt;Jak donoszą &lt;a href=&#34;https://blog.cryptographyengineering.com/2015/05/22/attack-of-week-logjam/&#34;&gt;ostatnio&lt;/a&gt;
&lt;a href=&#34;https://niebezpiecznik.pl/post/logjam-nowa-podatnosc-w-protokolach-https-ssh-i-ipsec/&#34;&gt;media&lt;/a&gt;, mamy
kolejną dziurę (&lt;em&gt;&lt;strong&gt;logjam&lt;/strong&gt;&lt;/em&gt;) dotyczącą szyfrowania SSL/TLS, a konkretnie rozchodzi się o
powszechnie stosowany na całym świecie protokół
&lt;a href=&#34;https://pl.wikipedia.org/wiki/Protok%C3%B3%C5%82_Diffiego-Hellmana&#34;&gt;Diffiego-Hellmana&lt;/a&gt; . I znów
jest podobny scenariusz, bo ten problem nie powinien mieć miejsca ale z powodu wstecznej
kompatybilności, tj. zapewnienie wsparcia dla wszystkich tych przestarzałych szyfrów tak by te
przedwieczne systemy/maszyny mogły działać, można doprowadzić do osłabienie mechanizmów, które
powinny być wykorzystywane obecnie. OK, może nie tyle osłabić, co wykorzystać te słabsze
odpowiedniki zamiast tych mocniejszych.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
