Diese Meldung bekomme ich seit Neuem mindestens jedes zweite Mal – ne, eigentlich fast jedes Mal, wenn ich die ach so tollen Privacy-Suchmaschinen von Startpage aka Ixquick über Tor nutze, was das Hauptargument in meinen Augen unglaubwürdig macht. Kommt einem als Tor User doch von anderen Suchmaschinen bekannt vor. So und mit ähnlichen Argumenten hat Google Scroogle getötet.
Die vielen Hinweise auf das Nichtspeichern und Verschlüsseln haben natürlich überhaupt nichts mit der zusätzlichen und effektiven Anonymisierung zu tun, um die es bei der zusätzlichen Nutzung von Tor geht. Ich verlasse mich nämlich grundsätzlich nicht auf irgendwelche Privacy-Heilsversprechen und dolle Siegel.
Klar könnte ich jedes Mal mit einem Klick das NEWNYM Signal an den Tor Prozess senden, wenn die bescheuerte Startpage Meldung kommt – um sie danach mit hoher Wahrscheinlichkeit erneut präsentiert zu bekommen, was auch geschieht. Mmh, die bösen und angeblich existenten Scraper und alle Tor Benutzer benutzen also gleichzeitig fast alle Tor Ausgang-Router? Ne, is klar. Aber ich sehe auch nicht ein, das ich das überhaupt wegen oder für Startpage und Ixquick mache. Die "permanent solution" Tor Nutzern bzw. an Privacy-Schutz per Anonymisierung Interessierte vorzuschlagen, ist natürlich galoppierende Debilität.
Anscheinend ist man bei Startpage / Ixquick leider genauso dumm – oder halt berechnend – wie andere große Suchmaschinen, sich nicht automatisiert die IP-Adressen der aktuellen Tor Ausgang-Router besorgen zu können, um sie in einen Whitelist zu integrieren. Das mache ich ja ohne Probleme, um die z. B. für das Whitelisting bei der Verwendung von PeerGuardian for Linux auszuschließen. Damit ist für mich Startpage und Ixquick tot. Aber die waren schon vorher halbtot, weil man die Suchmaschinen ohne exzessiven Javaskripteinsatz nicht sinnvoll nutzen kann. Siehe auch:
Tor Ticket #6151: Startpage is blocking searches
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
In "Vermummungsverbot im Internet": Vom neuen Personalausweis und Pseudonymen singt Detlef Borchers das hohe Lied vom nPA Pseudonym. Schön und gut, vielleicht auch gut gemacht. Der Schlüsselsatz ist imo aber "Anbieter, die die Pseudonym-Funktion unterstützen, werden normalerweise eine Erstregistrierung auf ihren Seiten einpflegen, bei der sich ein Nutzer mit einem frei wählbaren Namen und/oder einer E-Mail-Adresse einträgt."
Nicht "und/oder", denn mehrheitlich wird eine E-Mail Adresse anzugeben sein, denn irgendwohin wird der Anbieter Meldungen zur Bestätigung, später bei Fehlern im System, neuen Funktionen usw. usf. senden müssen und wollen. Also brauchen wir auch eine (zumindest) pseudonyme E-Mail Adresse, denn das Angebot soll ja pseudonym und müsste anonym genutzt werden.
Nun stellen wir uns ganz dumm oder die ideale Welt vor, die sich auch der ansgesprochene CDU-Politiker Axel E. Fischer eträumt. In dieser Welt gibt es keine x-beliebigen E-Mail Anbieter mehr, die ohne vorherige korrekte Identifizierung des neuen Kunden mir nichts, dir nichts E-Mail Adressen und Konten verschenken und die Nutzung ihres Dientes anonymisiert erlauben. In dieser Welt soll das Schule machen, was man De-Mail nennt. Ein Modell für die Welt. Also De-Mail oder De-Mail-artige E-Mail Anbieter, bei denen die Eröffnung und Nutzung von E-Mail Konten ebenfalls an vorherige Identifizierung gebunden ist - am Besten mit so etwas wie dem nPA. Aber die De-Mail hat ja auch ein schönes pseudonymes Feature - die Einrichtung pseudonymer E-Mail Adressen. Die sind aber per De-Mail Gesetz nicht nur als solche zu kennzeichnen, sondern sie müssen zwingend aufdeckbar sein. Und mit so einer pseudonymen E-Mail Adresse meldet man sich dann in dieser idealen Welt mit seinem nPA beim Dienste-Anbieter an, um ein pseudonymes Dienste-Konto zu erhalten.
Was haltet Ihr eigentlich von den Diskussionen um Google Street View und den Widersprüchen, die man dagegen einlegen kann?
Ich bin da z. Zt. zwiespältiger Meinung. Mir gefällt der sommerlöchrige Negativ-Hype und die Konzentration auf Google überhaupt nicht. Ich finde, dass es schon einen Unterschied macht, ob ein Heer von Privatpersonen mit ihren Digicams durch die Straßen zieht und Aufnahmen zu privaten Zwecken (wenn auch mit zusätzlicher Zurschaustellung über die Foto- und Videoportale) ohne Profitabsichten oder Data Fusion Aktionen macht oder ein Konzern wie Google, dessen Produkte nicht nur für eigene Interessen auf den Markt kommen, sondern auch von Sicherheitsbehörden genutzt werden.
Aber andererseits - was ist jetzt genau der Unterschied zu Google Earth und ähnlichen satellitengestützten Diensten, die stillschweigend von allen genutzt und akzeptiert werden - doch eigentlich nur die horizontale statt der vertikalen Perspektive. Und was die Perspektive angeht, trifft ein Interesse an Googles Erderschließung auf ein nahezu völliges Desinteresse an der Erderkundung und -aufklärung durch ein immer größer werdendes Kontingent an Überwachungs-Drohnen und -Satelliten der zivilen und militärischen Sicherheitskräfte. Fühlt man seine Privatsphäre dort besser geschützt und aufgehoben?
Und sofern Personen und PKW-Kennzeichen tatsächlich und nicht reversibel unkenntlich, also nicht identifizierbar gemacht werden, Google keine Aufnahmen von privaten "Räumen" oder in private "Räume" hinein für Street View macht und es kein Echtzeit-System ist, in dem man Personen und Fahrzeuge live verfolgen kann, wäre ein Profiling und Tracking schwierig bis unmöglich.
Dann denke ich wiederum an den Versuch der systematischen und gleichzeitigen Erfassung und Kartierung von WLAN-Hotspots oder dem vermuteten Interesse Googles, Google Earth mittels Nahaufnahmen per Quadrocopter-Drohnen in die "Tiefe des Raumes" aufzurüsten (beides lässt sich auch kombinieren), um mal einen militärischen Begriff zu verwenden.
Das steht eigentlich nur für ein paar von vielen Layern, die sich zukünftig zusätzlich zu den bekannten "Ansichten" über Google Earth, Street View und Maps legen könnten. Denkt man diese Layer mit Geolokalisierungs- und Identifizierungs-Funktionen in bald allen technischen "Beacons", die man am oder irgendwann im Leib bei sich trägt, dem Drang, die komplette Realwelt per Ubiquitous Computing und Augmented Reality mit virtuellen Layern zu überlagen bzw. zu erschließen oder den gleichen Drang zur Datenverarbeitung und -visualisierung in Echtzeit mit Googles Street View zusammen und weiter, dann kommt man irgendwann woanders hin. Zu einer Verschmelzung aller Google Erderfassungssysteme, in der Bilder, Aufnahmen und Daten dynamisch, fast "lebendig" generiert und dargestellt werden, in denen jedes sich darin bewegende oder befindliche Objekt von einem sematischen Web an Zusatzinformationen, Querverweisen und Ursprüngen umgeben ist. Und zu den Objekten könnten dann auch ich mit meinen Arbeits- und Lebensorten zählen.
Vorbeugend und als Signal doch Widerspruch gegen Street View einlegen?
Ich bin gewiss kein Freund des Bürgerportal / De-Mail Konzepts, aber warum u. a. über die Frankfurter Rundschau das Fass "Elektronischer Kuvertwechsel" aufgemacht wird, entzieht sich etwas meinem Verständnis. Besonders, wenn man sich ein paar der Technischen Richtlinien zur De-Mail beim BSI durchliest und sich ein paar Gedanken über Transport und Ende-zu-Ende Verschlüsselung macht.
Was in dem Artikel thematisiert wird, ist die bloße Transportverschlüsselung bei der De-Mail. Also der Vorgang: De-Mail Kunde sendet Mail an seinen Bürgerportal-Diensteanbieter (BPDA) mittels der De-Mail Webapplikation und dem öffentlichen Zertifikat seines BPDA. Der entschlüsselt dann natürlich die nur an ihn verschlüsselte De-Mail, weil man beim BP / De-Mail Konzept den BPDA des Absenders gerne die De-Mails des Absenders auf Malware und Spaminhalte prüfen lassen möchte. Danach verschlüsselt der BPDA des Absenders die De-Mail wieder mit seinem und dem öffentlichen Zertifikat des BPDA des Empfängers, und sendet sie weiter an den BPDA des Empfängers, der natürlich die nur an ihn verschlüsselte De-Mail wieder entschlüsselt, weil der u. a. auch noch einmal auf Malware prüfen soll und der Empfänger nichts mit einer De-Mail anfangen könnte, die weiter mit dem Zertifikat seines BPDA verschlüsselt bliebe.
Etwas anderes findet auch nicht bei der herkömmlichen E-mail bzw. weniger statt, wo ich als Absender die E-Mails per TLS zur Transportverschlüsselung beim Mailserver meines Mail-Provider abliefere - der sie auch entschlüsselt. Von da könnte die Mail auch mit Transportverschlüsselung weiter an den Mailserver des Empfängers gesendet werden, wird sie aber meistens nicht. Der Mail-Provider des jeweiligen Empfängers kann wie bei den BPDAs E-Mails auf Spam und Malware prüfen - erzwungen oder auf Wunsch des Kunden.
Egal ob es nun die herkömmliche E-Mail ist oder die De-Mail sein muss: Wichtig ist - wie immer - die zusätzliche "Ende-zu-Ende" Verschlüsselung. Wollte man das bei der De-Mail mit dem BPDA des Empfängers als anderem "Ende", müsste man halt auf die Malware und Spamprüfungen verzichten, ich hätte das öffentliche Zertifikat des Empfänger BPDAs, mit dem ich direkt verschlüssele und den Ciphertext zusätzlich per Transportverschlüsselung an meinen BPDA sende. Aber eigentlich macht man das per OpenPGP oder Zertifikaten mit dem öffentlichen Schlüssel des Empfängers und danach erfolgt die zusätzliche Transportverschlüsselung.
Bei der De-Mail macht man das halt zukünftig mit seinem tollen RFID-Biometrie ePA und den darin gespeicherten Zertifikaten. Klar, man könnte den Inhalt des Editors auch mit OpenPGP verschlüsseln und signieren. Aber OpenPGP ist ja fies und schwierig.
Bei jedem Verfahren ohne zusätzliche und richtige Ende-zu-Ende Verschlüsselung zwischen Absender - Empfänger können sich unberechtigte Zugriffe auf den Inhalt, "Sicherheitslücken" und "geöffnete Kuverts" ergeben, ob das nun E-Mail oder De-Mail ist. Und deshalb sieht das ja das Bürgerportal / De-Mail Konzept auch vor. Eigentlich wird darüber ständig in den Richtlinien "gepredigt". Zum Beispiel in der TR – BP Postfach- und Versanddienst Funktionalitätspezifikation:
Der Postfachdienst erlaubt dem Nutzer, elektronische Nachrichten sowohl zu versenden als auch zu empfangen. Er sichert vor dem Versand von Nachrichten deren Integrität
und schützt die Nachrichten durch Verschlüsselung vor Einblick unberechtigter Dritter. Umgekehrt entschlüsselt der Dienst die Nachrichten und prüft deren Integrität vor Abruf durch den Empfänger. Nachrichten, die innerhalb der Bürgerportale verschickt oder empfangen werden, werden vom Malware-Dienst auf Viren- und Trojaner geprüft. (Transport, Malware-Prüfung)
Möchte der Sender seine Nachricht bzw. Nachrichteninhalte elektronisch signieren und/oder verschlüsseln, so kann er dies mit einer lokalen Signaturanwendungskomponente (SAK) bzw. mit einer lokalen Verschlüsselungskomponente durchführen. Diese Komponenten können auch in dem lokalen Web- bzw. Nachrichten-Client, mit dem er die Nachrichten editiert, integriert sein. So signierte und/oder verschlüsselte Nachrichten kann der Empfänger mit lokalen Komponenten entschlüsseln und vorhandene Signaturen prüfen. Der Nutzer kann eine Nachricht oder auch Anhänge einer Nachricht mit einer lokalen SAK auf seinem System (qualifiziert) elektronisch signieren3. Weiterhin kann er die Nachricht (Nachrichtentext inkl. der Anhänge der Nachricht) an den oder die Empfänger mit einer lokalen Verschlüsselungskomponente verschlüsseln. Die öffentlichen Verschlüsselungsschlüssel können
aus dem Adressbuch des Nutzers und/oder aus dem Verzeichnisdienst ausgelesen werden.
(Ende-zu-Ende)
Klar, mit "SAK" oder OpenPGP Ende-zu-Ende Verschlüsselung gibt's auch keine Malware- und Spam-Prüfung, weil die BPDAs nicht entschlüsseln können (sollten). Wird aber auch in den BSI TRs erwähnt.
Also ich halte diese Kritik an der De-Mail gelinde gesagt für eine mit Schaum geschlagene Sau, die man jetzt gut durch die Sommerlöcher in Gazetten und Blogs treiben kann.
"Stopp-Schild" nach Machart der türkischen Regierung, als ich gerade nach YouTube via Tor wollte und wohl über einen türkischen Tor Exit Node stolperte, mit Hinweis zur "Internet-Hotline" des türkischen Ministeriums für Telekommunikation, über die man alle Websites petzen soll, die irgendwie nach Zitat "Provocation for committing suicide, Sexual exploitation of children, To ease the usage of drugs, Supplying drugs which are dangerous for health, Obscenity, Prostitution, To provide place and opportunity for online gambling, Crimes mentioned in the Law on Crimes Against Atatürk numbered 5816" ausschauen. U. a. Heise hatte dazu vor kurzem in OSZE kritisiert türkische Internetzensur und der Index on Censorship in Free speech: Turkey versus Google berichtet.
Das letztgenannte Gesetz ist übrigens ein ähnlich unsägliches Zensur-Gesetz zur Unterbindung von Kritik und Meinungsfreiheit, indem man den Schutz des Staatsgründers Atatürk vor Verunglimpfung vorschiebt, wie zum Beispiel die Gesetze gegen "Majestätsbeleididigung" in Thailand. Etwas gibt es ja immer, um Internet & Web "durchzuregulieren".
Ne, wenn ich so etwas sehe, würde ich auch sagen, die Türkei ist noch nocht reif für die Europäische Union, wenn es nicht in allen Mitgliedsstaaten und ausgehend von der EU-Kommission gleichartige Bestrebungen und praktische Durchführungen zur Zensur geben würde. P. S.: ExludeExitNodes {tr} in torrc.
Siehe auch auf der Zensur Unterseite im AnonWiki:
Türkei
Thailand
Schick sieht sie ja aus, die Features stimmen und auf Hardware im "Secure All–Terrain Shock–proof rugged design", um ein paar der Attribute zur Vermarktung der externen LaCie Rugged Safe Festplatte zu nennen, stehe ich eh.
 Externe Festplatte "Rugged Safe" von LaCie. Foto: LaCie.
Aber was ist das für ein Blödsinn, zwar eine Verschlüsselung per AES-128 (es kann auch a bisserl mehr sein) und Chip anzubieten, zu der LaCie natürlich wie so viele Hersteller auch verspricht, dass sie "unbrechbar" implementiert sei, aber in die Festplatte einen Fingerabdruck-Sensor einzubauen. Macht man das nur deshalb, weil es mittlerweile üblich, möglich und von den Kosten her annehmbar ist, überall biometrische Verfahren und Techniken für die Authentifizierung und Entschlüsselung zu verbauen?
Großartig beworben wird das Produkt mit der Möglichkeit, neben der Eingabe eines Passworts ganz einfach mit dem Scannen und Abgleich eines einzelnen Fingerabdrucks Zugriff auf die zuvor verschlüsselten Daten zu erhalten. Das wird natürlich Sicherheitsbehörden freuen, wenn sie die LaCie Festplatte beschlagnahmen und nur noch einen Finger des Besitzers auf den Sensor halten müssen, anstatt den Versuch zu starten, das Passwort aus dem Besitzer herauszupressen. Und damit es dabei keine Ausfälle gibt, kann sich der Besitzer der Festplatte auch alle zehn Fingerabdrücke einscannen - prima.
Das gilt natürlich auch für Diebe, wenn die Besitzer und Festplatte zugleich "abgreifen" können und für beide Interessenten der verschlüsselten Daten gilt, dass es ja auch noch die Möglichkeit gibt, sich mit nachgebildeten Fingerabdrücken an dem Sensor zu versuchen, von dem es in dem User Manual auf die FAQ "What is the probability that a fingerprint from an unauthorized user can unlock the Rugged Safe?" nur die beschwörende Antwort gibt: "Such an event is nearly impossible due to the biometry technology. Each human has his own biological identity, including unique fingerprints, thus making unauthorized entry all but unthinkable. To provide further assurance, LaCie has selected a sensor known for its precision." Wer's glaubt, wird seelig. Was ich noch verstehen und mir vorstellen könnte, wäre eine 2-Wege Authentifizierung/Entschlüsselung, also Fingerabdruck plus zwingendem Passwort.
 CryptoStick des GPF e. V. In zukünftiger Version mit integriertem Datenspeicher, so dass sich der zweite Stick erübrigen würde.
Oder noch besser: Wenn in externen Festplatten ein USB-/SmartCard Reader integriert wäre, mit dem ich meinen OpenPGP CryptoStick der German Privacy Foundation und dessen PIN zur Authentifizierung/Entschlüsselung nutzen könnte. Das wäre doch mal was, liebe Hersteller externer Festplatten  Bis dahin bleibe ich lieber bei TrueCrypt und dm-crypt/LUKS verschlüsselten Partitionen.
Der beliebte und bekannte Scroogle Proxy Dienst hat aktuell Probleme mit Google, wie zu lesen ist, wenn man Scroogle aufruft bzw. eine Suchanfrage absetzt:
We regret to announce that our Google scraper may have to be permanently retired, thanks to a change at Google. It depends on whether Google is willing to restore the simple interface that we've been scraping since Scroogle started five years ago. Actually, we've been using that interface for scraping since Google-Watch.org began in 2002.
This interface (here's a sample from years ago) was remarkably stable all that time. During those eight years there were only about five changes that required some programming adjustments. Also, this interface was available at every Google data center in exactly the same form, which allowed us to use 700 IP addresses for Google.
That interface was at www.google.com/ie but on May 10, 2010 they took it down and inserted a redirect to /toolbar/ie8/sidebar.html. It used to have a search box, and the results it showed were generic during that entire time. It didn't show the snippets unless you moused-over the links it produced (they were there for our program, so that was okay), and it has never had any ads. Our impression was that these results were from Google's basic algorithms, and that extra features and ads were added on top of these generic results. Three years ago Google launched "Universal Search," which meant that they added results from other Google services on their pages. But this simple interface we were using was not affected at all.
usw.
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)
|
