Browser

Gerade kam ein Update von NoScript für die "Do Not Track" (DNT) Opt-out Header Funktion, die seit 2.0.9 enthalten ist - sprich Browser sendet an jede Website zusätzlichen Tracking Opt-out Header.

Lt. X-Do-Not-Track support in NoScript:

"From now on, a web browser with NoScript installed warns every HTTP server it contacts that its user does not want to be tracked, i.e. that his data must not be collected for profiling and persistent identification purposes. I believe this is a safe assumption about the feelings of most if not all NoScript users."

Richtig.

"As stupid as it may sound (why parties who are interested in tracking you would comply?),"

Eben. Stupid.

"a mean to clearly express your will of not being tracked is going to be useful, especially when backed by law or industry self-regulation, as explained here."

Nicht "besonders", sondern ausschließlich dann, wenn oder sobald die Auswertung und Beachtung von DNT gesetzlich vorgeschrieben ist. Selbstregulierung ist keine Option, sondern nur eine Taktik von Unternehmen und der Politik, einer gesetzlichen Regulierung im Interesse von Internetnutzern, Bürgern und Kunden zu entgehen.

"Therefore it seems in the interest of NoScript users and privacy-concerned netizens in general to participate in this effort."

Nein. Solange die obige Bedingung nicht erfüllt ist, trägt der Header nur zum Browser Fingerprint bei und identifiziert die User, die Anti-Tracking Erweiterungen installiert haben. Der DNT Header wird damit selbst zum Tracking Opt-in Header. Außerdem ist es wenig sinnvoll, wenn Erweiterungen anfangen, schlecht dokumentierte oder von Browseranwendern nicht beachtete bzw. nicht zu ändernde Header Manipulationen durchzuführen.

In diesem Sinne rate ich dazu, noscript.doNotTrack.enabled auf false zu setzen.

Wer Privoxy einsetzt - in die Filterdatei einsetzen:

CLIENT-HEADER-FILTER: kill-optout-header Header filter to remove Do-Not-Track headers.
s@^X-(?:Behavioral-Ad-Opt-Out|Do-Not-Track):.*@@i

In eine Actiondatei (z. B. match-all.action) einsetzen:

+client-header-filter{kill-optout-header} \

bewirkt dann global das:

Re-Filter: filtering 'X-Behavioral-Ad-Opt-Out: 1' (size 26) with 'kill-optout-header' ...
Header: Transforming "X-Behavioral-Ad-Opt-Out: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header
Re-Filter: filtering 'X-Do-Not-Track: 1' (size 17) with 'kill-optout-header' ...
Header: Transforming "X-Do-Not-Track: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header

Der beliebte und bekannte Scroogle Proxy Dienst hat aktuell Probleme mit Google, wie zu lesen ist, wenn man Scroogle aufruft bzw. eine Suchanfrage absetzt: Da Scroogle immer ganz praktisch bei der Nutzung von Tor war, um den lästigen "We're sorry" Meldungen und Captcha Anfragen zu entgehen, muss schnell ein temporärer Ersatz her: Entweder man nimmt Ixquick oder man sucht sich bei Mycroft einen anderen Ersatz und kann dann dort direkt das passende Search Engine Plugin in Firefox installieren.

Mit zwei Anonymouse oder auch dem "Ninja" Plugin klappt das ganz gut. Und da eh alle Suchanfragen bei mir per Privoxy und Tor gefiltert und anonymisiert an den Suchdienst rausgehen... Aber mir wäre lieber, wenn das Scroogle wieder geregelt bekommt Nur wenn man einen Suchdienst erwischt, den Google selbst als "Gefährder" einstuft oder der Suchdienst die IP des Tor Exit Node an Google weiterreicht, kann man wieder schlechte Karten bei Google haben.

Update: Mal wieder viel Geschrei um nix, laut Scroogle scrapes back to life kann wieder gescroogelt werden

Siehe auch:
Heise - EU-Datenschützer fordern echte Anonymisierung von Suchanfragen (27.05.2010)

Die Electronic Frontier Foundation (EFF) bietet mit Panopticlick ein nettes Spielchen (oder Experiment) mit ernstem Hintergrund für alle Internetuser an, die sich für die Anonymisierung ihrer Browser- bzw. WWW-Nutzung interessieren oder anders gesagt, wie ihr Webbrowser konfiguriert ist und deshalb welche Informationen ausspuckt, die er mit einer Teilmenge der Browser anderer Nutzer in einer gegebenen Gesamtmenge gemeinsam hat oder auch nicht. Noch einfacher: "Zeig mir, welchen Browser und wie Du ihn nutzt und ich sage Dir, wer Du bist und wo Du bist". Die meisten Internetnutzer dürfte es nicht interessieren

Den ernsten Hintergrund bildet die Identifizierung und Wiedererkennung von Webbrowsernutzern - das Optimum wäre: stets ein und desselben Nutzers, Verfolgung der Nutzung oder des Konsums von Webseiteninhalten über Webseiten und Websites hinweg und seine Geolokalisierung, an der sich Nutznießer und Auftraggeber der Werbeindustrie, manche Internet-Zugangsprovider, Dienste- und Inhalteanbieter oder auch Geheimdienste versuchen.

Ähnlich wie beim Anontest vom JonDonym Anonymisierungsdienst oder bei browserspy.dk wertet Panopticlick den charakteristischen User-Agent und HTTP_ACCEPT Header aus und sofern Javascript aktiviert ist (was bereits ein Kriterium an sich ist), installierte Browser Plugins, Zeitzone, Bildschirmauflösung, Farbtiefe, Systemschriften, ob Cookies und "Supercookies" per Flash LSOs und DOM-Storage möglich sind. Bei EFFs Panopticlick werden die Daten aber nicht nur für jeden einzelnen User ausgewertet, angezeigt und wieder verworfen, sondern anonymisiert in einer Datenbank gespeichert und mit den Datensätzen aller anderen User abgeglichen, um zur besagten Aussage zu kommen, wie einzigartig und identifizierbar man in der Gesamtmenge ist. Also die gleiche Aussage, an der auch die angesprochenen Kreise interessiert sind. Je mehr und länger User mit ihren verschiedenen Betribessystemen, Browsern und Konfigurationen mitmachen, desto aussagekräftiger wird der Scorewert, den man nach dem Panoption Test erhält und desto aussagekräftiger die Antwort, die man sich von dem Panopticlick Experiment seitens der EFF erhofft: Wie gut lassen sich mit "Web-Tracking" Methoden digitale Fingerabdrücke für Browsernutzer erstellen und wie effektiv sind sie?

Einschränkend muss man sagen, dass man eigentlich umso besser in der Menge aller Browsernutzer verschwinden müsste, je mehr man den eigenen Browser genauso nutzt wie die Mehrheit oder zumindest der Durchschnitt aller Internetnutzer - wie ich annehme: mit veralteten Versionen, mit allen nur denkbaren Plugins und Erweiterungen vollgeknallt bis zum Anschlag, Javascript und Flash schön aufgedreht, Cookies immer dabei und natürlich ohne Anonymisierung

Kleiner Tipp zur neuesten Firefox-Version am Rande: Die finden ja nicht nur diese überflüssigen Minimalthemes names "Personas" ganz toll, sondern auch die Geo-Lokalisierung per Google Lokalisierungsdienste, die man aber laut Anleitung einfach und generell deaktivieren kann. Wird aber auch nur eine Teilmenge der Teilmenge abschalten, wie ich die feature-geilen Internetuser kenne.

Siehe auch:
EFF - Web Browsers Leave 'Fingerprints' Behind as You Surf the Net (17.05.2010)

Ich möchte Euch noch eine Erweiterung für Mozilla Browser vorstellen, mit der man eine weitere "Sicherheitsschicht" um die Browser legen kann.

Sie betrifft alle Anfragen und Verbindungen, die der Browser von einer Webpage einer Website, die aktuell aufgerufen wurde, zu einer anderen Website startet, um von der anderen Website Bilder, Skripte, eingebetten Frames usw. nachzuladen, die dann als Objekte der aktuell aufgerufenen Webpage angezeigt werden oder um Funktionen einer aktuellen oder fremden Webanwendung auszuführen und zu verändern, wobei beide Websites unterschiedliche Server betreffen können. Wurde die aufgerufene oder die andere Webpage/Website manipuliert oder dem Nutzer eine URL zu- und untergeschoben (z. B. über die beliebten Spam- und Phishing Mails), die manipulierte Websites aufrufen, kann das u. a. für die Cross-Site Request Forgery Angriffe (XSRF/CSRF & Co.) ausgenutzt werden.

Bei verschiedenen Angriffen spielen deshalb immer Anfragen eine große Rolle, die vom Nutzer unbemerkt im Hintergrund abgewickelt werden, wenn er sich eine Webpage "anschaut" und dortige Webanwendungen nutzt. Klar, könnte man auch ständig alle Anfragen selbst beobachten, überwachen und nachprüfen, aber das wäre beim alltäglichen Surfen kaum zu praktizieren. Hier setzt die RequestPolicy Erweiterung an, die ähnlich wie bei NoScript, RefControl und anderen Erweiterungen alle Anfragen gegen White- und Blacklist prüft. Nur das im Fokus der RequestPolicy Erweiterung die oben geschilderten Anfragen zu Domains fremder Websites stehen, während zum Beispiel mit NoScript das Verbeiten und Zulassen von Javascript, Plugins, iFrames usw. im Mittelpunkt steht, wobei auch NoScript mittlerweile verschiedene Schutzfunktionen gegen Cross-Site Anfragen und Scripting integriert hat, weshalb der Autor der RequestPolicy seine Erweiterung auch als Ergänzung zu NoScript sieht.

Zu RequestPolicy ein Beispiel von der Installation bis zur Anwendung anhand des letzten Beitrags im Weblog: Den größtmöglichen Sicherheitslevel für die Funktionen, die RequestPolicy bietet, der aber auch mit maximalem Einrichtungsaufwand einhergeht, erreicht man also, wenn keine vorkonfigurierte Whitelist und die höchste "Strictness" Überprüfung aktiviert, aber nur die "Quelle-zu-Ziel" Whitelist verwendet wird.

Die RequestPolicy Erweiterung kann über die Homepage der Erweiterung oder, da sie noch im Experimentalstadium ist, nach Login über die Firefox Add-ons Seite installiert werden. Wie man auf der Seite zu aktuellen und geplanten Features von PolicyRequest nachlesen kann, hat der Autor mit PolicyRequest viel vor. Wie gesagt ist sie noch experimentell. Andererseits besteht die Möglichkeit, dass Erweiterungen wie NoScript und AdBlock Funktionen von PolicyRequest übernehmen. Zu erwähnen ist auch, dass es neben PolicyRequest auf Firefox Add-ons eine Reihe anderer Erweiterungen gibt, die sich ebenfalls CSRF und XSS annehmen. Zu begrüßen wäre es, wenn in zukünftigen Mozilla Browsern die Funktionen einer Reihe von Sicherheits-Erweiterungen fest integriert würden, die sich als nützlich und absichernd erwiesen haben, denn die Liste der Erweiterungen, mit denen man seinen Browser zusätzlich absichern muss, wird immer länger.

Da es sich anbietet, hier mal wieder das beliebte Spiel "Zeigst Du mir Deine Erweiterungen, zeig ich Dir meine". Aktuell installierte Erweiterungen, dir direkt oder indirekt der Sicherheit, dem Datenschutz und Anonymisierung dienen:

• Adblock Plus
• BetterPrivacy
• Cache Status
• Cert Viewer Plus
• Controle de Scripts
• CookieSafe
• CustomizeGoogle
• Flashblock
• FoxyProxy
• Layerblock
• NoScript
• RefControl
• RequestPolicy
• SafeCache
• SafeHistory
• Secure Login
• SSL Blacklist
• SSL Blacklist Local Database
• User Agent Switcher

Via:
ha.ckers Blog - RequestPolicy Firefox Extension

Bisher nutzte ich unter Windows für Downloads mit Firefox immer die FlashGot Erweiterung (vom Programmierer stammt auch NoScript) mit dem Free Download Manager, der Feedreader brachte auch noch seinen eigenen Download-Manager für Podcasts, Movies usw. mit. Mal direkt oder über Tor, I2P und JonDonym für anonymisierte Downloads. Die beiden Download-Manager hatten die meiste Zeit nichts zu tun und so etwas gefällt mir nicht. Auch wenn ich mir bei den niedrigen Speicherpreisen jetzt den Arbeitsspeicher aufgerüstet habe, um demnächst etwas mit Virtualisierung herumzuspielen.

Da ich Wget in der Konsole ebenso gerne für Downloads nutze und es zu dessen Einbindung in FlashGot auf der Features Seite ein Beispiel gab (was mir nicht ausreichte), habe ich mir mit ein paar Batchdateien, der Wget Portierung des GnuWin32 Projekts und ein paar weiteren Sachen einen minimalen Wget "Download-Manager" gebastelt, der dann im FlashGot Kontextmenü von Firefox so aussieht: Die "NoProxy" Menüeinträge rufen, wie der Name schon sagt, Wget für den Download ohne Proxy und Weiterleitung an Tor, I2P oder JonDonym auf, bei den "Proxy" Menüeinträgen werden Downloads über den Privoxy Proxy und ggf. einen Anondienst abgewickelt, für FTP Downloads statt Privoxy über JonDonym, da Privoxy kein FTP unterstützt.

"NoSSLcheck" ist für SSL/TLS verschlüsselte Downloads von Servern da, die nur selbst signierte Zertifikate anbieten und deshalb nicht gegen die CA-Zertifikate geprüft werden können bzw. bei CA-Zertifikaten, die man noch nicht einer Datei mit einem Paket aller CA-Zertifikate hinzugefügt hatte, aber wo man trotzdem etwas herunterladen möchte. Bei Menüeinträgen ohne "NoSSLcheck" werden immer Server-Zertifikate gegen die CA-Zertifikate geprüft und deshalb ein Download abgebrochen, wenn etwas nicht mit den Host- und Zertifikatangaben stimmt. Was aufgrund von Angriffsmöglichkeiten und Schlampereien bei den CAs auch nicht unbedingt eine Garantie bietet, wie man immer wieder erfahren muss.

Natürlich kann man die Liste beliebig für weitere Zwecke und Funktionen von Wget erweitern.

Für die Datei mit dem Paket aller CA-Zertifikate habe ich mich der Zertifikatespeicher der Browser und OpenSSL bedient. Man kann natürlich auch selbst alle CA Sites absurfen und sich die Zertifikate selbst besorgen und "behandeln". Weitere Methoden werden in der readme Datei genannt.

Falls es jemanden interessiert oder für diejenigen, für die das Ganze nützlich sein könnte, habe ich die Batchdateien und eine eingerichtete wgetrc Datei in ein Archiv gepackt. In der readme Datei steht auch alles Weitere ausführlich erklärt. Verbesserungsvorschläge und Tipps sind wie immer willkommen.

Vermutlich kommen ein paar Leser angerannt, die mir sagen wollen, das sei alles zu kompliziert und Download-Manager XY viel besser, schöner, bunter und mächtiger. Aber genau die wollte ich eben nicht. Was die Wget Geschichte nicht kann – wie zum Beispiel der Free Download Manger, ist die automatische Konvertierung von Filmchen, die man bei YouTube herunterlädt. Aber dafür gibt es dann auch wieder einfache Tools.

Siehe auch:
WackGet

Erster Test mit der SSL Blacklist Erweiterung für Firefox, die neben den schwachen Schlüsseln des OpenSSL Bugs jetzt auch die mit MD5 signierten Zertifikate als Warnung auswerfen soll: Angesurft habe ich bis jetzt daneben nur mein Kreditinstitut, die Arge, die Fireox Add-ons Site und meinen Provider. Zur Ergänzung auch ganz nett ist die Cert Viewer Plus Erweiterung, die aber nichts mit den obigen Schwachstellen zu tun hat. Die Informationen in der Zertifikatsansicht: Hintergründe:
25C3 - MD5 considered harmful today - Creating a rogue CA Certificate (BitTorrent)
Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger - MD5 considered harmful today - Creating a rogue CA certificate
Heise - 25C3: Erfolgreicher Angriff auf das SSL-Zertifikatsystem

Siehe auch:
Fefe - Ich habe gerade mal einen Bug gegen Firefox gefiled (ja, auch "nett" )
eWeek - SSL Certificate Vendor Sells Mozilla.com Cert to Some Guy