Flag Mails received with TLS or IPv6

Flags in Thunderbird

Flags in Thunderbird

I just wondered how wide spread IPv6 and TLS are when receiving e-mails, so I wanted to quickly see which kind of transport an incoming mail used. I wanted to see it directly when it hits my inbox, so I adding a tag to the mail would be a sensible approach.

Since I’m running a quite common setup with Postfix, Dovecot and the usual stuff connecting into those two daemons, it wasn’t much work to do it.

Dovecot has the ability to filter and sort mails directly on the server using sieve. I have sieve up and running to sort mails from mailinglists into their corresponding folders and do stuff like that.

The best way to find out how an e-mail was received is to look at the “Received” header:

Received: from sender.domain.invalid (sender.domain.invalid [IPv6:2001:db8:cofe::1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by receiver.otherdomain.invalid (Postfix) with ESMTPS id 01D2C3E4A02
 for <nico@otherdomain.invalid>; Sun, 11 Jan 2015 17:24:17 +0100 (CET)

The header spreads across multiple lines and with (usually) tabs infront of the new ones. It tells us that the sending Mailserver was using IPv6 and TLS. Of course, sender.domain.invalid and receiver.otherdomain.invalid are only to demonstrate it. In reality, there should be your domain and the sender’s one.

Automatically detecting IPv6 is not so simple as one might think, the “Received” line must include “IPV6:” in it. But also, you want to make sure that it is only a hit, when the message was received by you via IPv6, not by one of the mailservers it might have passed earlier on its way through the internet.

There is a handy tool called regexr.com, where you can built and test regular expressions. It took me some minutes to make it work, without having long expression The IPv6 one can be seen here. You need to paste the received header from above, to see it work.

(from).+\[IPv6:.*(\s.*)*(by receiver\.otherdomain\.invalid)

First, we filter for “from” and “IPv6:” (the colon just to make sure that we don’t hit in a possibly wrong hostname) in one line, then after some more lines we filter on the receiving mailserver.

Of course, the sieve regex implementation has its own flavour of regular expressions, explained here, so I had to do some modifications to use them with sieve.

The TLS regex was on the same level of complexity. It’s that piece of regex.

(from).+\s+\(using TLS.*(\s.*)*(by receiver\.otherdomain\.invalid)

It also hits on “from” but then searched fot the TLS header. Again, it also matches the receiving servers hostname. Sinve SSLv3 is broken and should not be used, I to only match TLS.

As linked earlier, the sieve regex has some own ways to find whitespaces or newlines, so have a look at the linked document, if you want to build your own expressions.

I did not want to modify the message but wanted to see the flags on a first glance, I did not want to add a pre- of suffix to the subject. I instead decided to use the colour flags Thunderbird can display. I do not use them normally so they are a good fit for that task. They can easily be removed afterwards, when stuff gets boring and everyone uses IPv6 and TLS ;-)

The dovecot wiki lists the lables and the corresponding colours. I chose green for TLS and blue for IPv6. Usually they are used for “Personal” and “ToDo”

To do the filtering, your sieve instructions file must require the modules “imap4flags” and “regex”, otherwise it won’t work. My sieve config is like the following (but much longer with a lot more rules):

require ["imap4flags","regex"];
 # rule:[TLSTest]
 if header :regex "received" "(from).+[[:space:]]+\\(using TLS.+([[:space:]]*.*)*(by receiver\\.otherdomain\\.invalid)"
 {
 addflag ["$label3"];
 }
 # rule:[IPv6Test]
 if header :regex "received" "(from).+\\[IPv6:.*([[:space:]]*.*)*(by receiver\\.otherdomain\\.invalid)"
 {
 addflag ["$label4"];
 }

These regexes work quite well for me. You need to replace the domain “receiver.otherdomain.invalid” with the one your mailserver uses. Until now, I had no false-negatives or false-positives. I’m not sure what happens when TLS is in one Received header, and my hostname in another. I think that sieve checks them one by one but did not challenge that. The one by one checking would make sense because the regex itself is only executed for “received” headers, as you can see in the sieve rules.

Of course, other sieve plugings like fileinto” can move mails to differend locations but I just wanted to observe the Mails coming into my inbox, with the new flag.

Mail with Flags

Mail with Flags

I renamed the two flags (or tags, as they are called in Thunderbird), just to have it a bit less tidy in my inbox.

How far TLS and IPv6 are spread. Right now I see a lot of TLS but nealy no IPv6, only from RaumZeitLabor and folks sorrounding it.

 

Nico

Teilausfall Kabeldeutschland Kabelinternet (IPv4 <-> IPv6) (behoben)

Eben (gegen 12:30 Uhr) ist bei Kabeldeutschland etwas abgestürzt und seitdem das Internet gestört. Dieser Beitrag wird aktualisiert, sobald neue Informationen vorliegen.

Aktuell sind ihre IPv4 Nameserver sowie das DS-Lite Gateway nicht erreichbar bzw funktionieren nicht richtig (lassen sich pingen, mehr aber auch nicht). Da ich nur einen IPv4 Anschluss ohne IPv6 von Kabeldeutschland habe (IPv6 wird bei mir über http://tunnelbroker.net getunnelt) reicht es die Nameserver zu ändern. Meistens ist dies auf dem Router möglich, falls das nicht möglich ist muss man sie auf den Endgeräten (z.B. dem PC) manuell eintragen. Alternative Nameserver sind z.B. von Google 8.8.8.8 und 8.8.4.4, 85.214.20.141 vom FoeBud/digitalcourage oder 213.73.91.35 vom ccc Berlin.

Bei IPv6 Anschlüssel von Kabeldeutschland sieht es aufgrund des eingesetzten DS-Lite Protokolls schlechter aus. In diesem Fall bekommen die Router nur IPv6 Adressen zugewiesen und erreichen IPv4 Adressen über ein vom Netzbetreiber bereitgestelltes Gateway, welches die Anfragen umwandelt. Da dieses aktuell aber auch nicht erreichbar ist, ist es somit nicht direkt möglich IPv4 Adressen aufzurufen. IPv6 funktioniert dagegen problemlos:

[tweet_embed id=367964279221547009]

Hier hilft es, wenn man einen VPN Server hat, welcher über IPv6 erreichbar ist (was selbst in Nerd-Kreisen noch nicht unbedingt die Regel ist) oder aber die Nutzung eines öffentlichen IPv6 zu IPv4 Gateway. Ein mögliches wird von http://sixxs.net betrieben. Die Funktionsweise ist unter http://www.sixxs.net/tools/gateway/ erklärt. Der Zugriff funktioniert durch das Verlängern der URL um “sixxs.org”. Aus http://www.kabeldeutschland.de wird dadurch http://www.kabeldeutschland.de.sixxs.org. Damit ist es auch möglich Webseiten aufzurufen, die normalerweise ausschließlich per IPv4 erreichbar sind. Beachtet aber bitte, dass hier nicht der beste Datenschutz gewährleistet ist, da die Daten über mindestens einen weiteren Server geroutet wird, der von SixXS ;-)

Die Kabeldeutschland Hotline ist aktuell überlastet, es betrifft also wohl nicht nur einzelne Anschlüsse sondern eine größere Region. Laut KDGforum betrifft die Störung mindestens weite Teile vom Saarland und Rheinland-Pfalz. Auf allestörungen.de ist die Anzahl der heutigen Störungsmeldungen stark angestiegen, hier ist auch der Schwerpunkt in Rheinland-Pfalz und dem Saarland.

UPDATE: Seit etwa 14:20 Uhr sind die Dienste wieder hergestellt. Sowohl bei mir als auch bei Nutzern des KDGforums ist der Netzzugriff wieder möglich. Die Störung ist wohl behoben. Das Ganze zeigt aber auch, dass DS-Lite wohl noch nicht ganz so fehlerresistent wie das bisherige IPv4 Routing ist.

Stand: 14:30

Sipkom stellt bisherigen SIP Dienst ein

Wie der Anbieter sipkom (nicht zu verwechseln mit sipgate) am Freitag per Newsletter mitteilte, stellen sie den SIP Dienst mit deutschen Festnetznummern ein

hiermit möchten wir Sie darüber informieren, dass wir den SIP (VOIP) Dienst in der jetzigen Form einstellen müssen §9.8.

Unser Support steht Ihnen ab sofort nicht mehr für die sipkom Plattform (491805.. ,49322.. 883…) zur Verfügung.

Die Einstellung des Dienstes mit dem alten Anbieter war für uns unvermeidbar und ohne Zukunft .

Kunden mit deutschen Festnetzrufnummern wird empfohlen diese zu sipgate zu portieren, um weiterhin erreichbar zu sein. Eine eventuell bei sipkom registrierte 032 Rufnummer kann nicht zu sipgate portiert werden, da sipgate diese nicht unterstützt, wie sipgate auf Nachfrage mitteilte:

Kunden mit einer WLN (Worldwide local number, sipkom bietet Rufnummern aus über 70 Ländern an) können diese weiterführen, bekommen hierfür aber neue SIP Zugangsdaten, Restguthaben wird übernommen. Die Abschaltung betriefft also ausschließlich deutsche Festnetzrufnummern.

Ich hatte sipkom bisher für eine 032-er Nummer genutzt. Diese Rufnummerngasse ist speziell für VoIP gemacht worden und hat eigentlich keine Vorteile gegenüber einer Ortsnetzrufnummer. Auf den ersten Blick fällt auf, dass Anrufe auf 032 selten in Flatrates enthalten, oft (von Mobil) sogar teurer als Festnetznummern sind. Genau hier setzt aber mein Zweck an: Die Nummer ist häufig teuer anzurufen. Scherzanrufe, SPIT und co kommt damit also eher nicht an (oder geht ins Geld). Die perfekte Nummer fürs Whois in Domains oder das Impressum. Ein weiterer Vorteil der separaten Nummer ist, dass ich die Nummer niemandem direkt gebe (sondern hier nur meine normale Telefonnummer) und somit diese Nummer auch schnell wechseln kann. 0180-Servicerufnummern bekommt man mittlerweile ja nicht mehr kostenlos, diese waren früher mein Favorit fürs Whois. Nachdem ich einmal schlechte Erfahrung gemacht habe mit meiner normalen Telefonnummer im Netz würde ich diese ungern so offen angeben, es gibt heutzutage immernoch Menschen die es witzig finden nachts um 4 jemanden aus dem Bett zu klingeln, ohne einen sinnvollen Grund zu haben. Nun werde ich mir also einen neuen Anbieter hierfür suchen, wahrscheinlich werde ich eine Rufnummer bei ventengo registrieren.

Debian Wheezy veröffentlicht

Nach einiger Zeit der Entwicklung ist am Sonntag die siebte Debian Version namens wheezy veröffentlicht worden.

Sie löst damit ihren Vorgänger squeeze nach etwa 2 Jahren ab. Debian wheezy war bisher als testing geführt worden und hatte hier in letzter Zeit schon eine recht hohe Stabilität gezeigt. Doch auch ein paar Bugs waren noch vorhanden, z.B. bei der Berechnung der Load in Verbindung mit KVM liefert der Kernel manchmal interessante Werte. Hier bleibt abzuwarten, wie sich die Anzeige nach dem Update verhält.

Debian wheezy setzt in alter Tradition eher nicht auf die neusten Versionen der Programme, verfolgt damit aber eine Strategie die auf Stabilität abzielt statt neuste Features. Wer unter Debian stable neuste Software will sollte auf die Debian Backports, Dotdeb oder andere Repositories setzen, die das entsprechende Programm anbieten.

Auf allen Servern die ich in den letzten Monaten neu installiert hab (z.B. mein Monitoring, der neue Server des RaumZeitLabors) läuft schon Debian wheezy, ein großes Update steht für mich trotzdem an: der Server auf dem dieses Blog läuft nutzt aktuell squeeze, welches bisher stable war. Im Zuge des Debian Updates werde ich die Daten wahrscheinlich auf einen neuen VPS umziehen, der mehr Leistung hat (4GB RAM statt 2GB, für den gleichen Preis). Meine Erfahrung bei Debian Updates ist zwar gut (besser als bei Ubuntu) aber es ist immer hilfreich, ein Backup zu haben ;-)

Spamabwehr: SPF und Greylisting

Vor ein paar Monaten hab ich testweise SPF und Greylisting auf meinem Mailserver aktiviert. Doch, was ist das?

Fangen wir mit dem einfacheren von beidem an:

Was ist Greylisting?

Beim Greylisting werden einkommende E-Mails erstmals mit einem temporären Fehler abgewiesen. Versucht es der absendende Mailserver nach ein paar Minuten nochmals, wird die E-Mail akzeptiert (ich hatte dafür als Wartefrist mindestens 10 Minuten eingestellt). Dann wird der Mailserver auf eine Art Whitelist gesetzt (bzw. seine IP-Range, je nach Einstellung), auf der er auch bleibt, so lange er nicht 14 Tage am Stück keine E-Mails an meinen Server gesendet hat.

Die “Erfindung” des Greylistings basierte auf der Annahme, dass Spammer es nicht nochmals versuchen, die Mail zuzustellen. Früher war das wohl auch richtig, Heute ist der Anteil an erfolgreich abgewehrten Spamnachrichten aber doch eher klein geworden, weil die meisten Spammer “vollwertige” Mailserver einsetzen, die es auch wieder versuchen..

Es wurden zwar ein paar Spams abgewehrt, im Gegenzug verzögert sich aber auch die E-Mail Zustellung, sofern der Absender in letzter Zeit keine Nachricht an mich gesendet hat. Es nervt einfach auf Dauer, wenn man sich irgendwo Forum anmeldet, die Bestätigungsmail 10 bis 15 Minuten brauch und man in seinen Logddateien sieht, dass sein Greylisting daran schuld ist. Das wiegt die “paar” abgewehrten SPAM Nachrichten nicht auf. Zu allem Übel nutzen Spammer heutzutage auch gerne mal gehackte Mailaccounts. Da bringt Greylisting auch nichts.

 

Die zweite “Nettigkeit” die ich getestet habe war SPF.

Was ist SPF?

Für SPF erstellt man unter seiner Domain einen weiteren DNS Eintrag vom Typ TXT und dem Inhalt, welche IP-Adressen für diese Domain E-Mails absenden dürfen.

Der Eintrag sieht für mich so aus:

v=spf1 ip4:83.169.40.215 -all

spf1 steht für die SPF Version 1, das im Moment gebräuchliche. Danach folgt die IPv4 Adresse von meinem Server, dass dieser E-Mails in meinem Namen (also für Absender innerhalb meine Domain) absenden darf und ein “-all”. Letzteres heißt, dass sonst absolut kein anderer Mailserver E-Mails für die Domain vthadden.de verschicken darf. Ein Empfangender Mailserver prüft nun beim Erhalt von E-Mails, ob für diese Domain ein SPF Eintrag besteht, wertet ihn aus und befolgt ihn hoffentlich.

Statt “-all” gibt es noch “~all” und “?all”. “-” heißt Hardfail, E-Mails ablehnen; “~” steht für Softfail, in dem Fall würde es bedeutet dass die E-Mail wahrscheinlich nicht richtig ist, was damit passiert ist mir aber egal; “?all” steht für “mir egal, wer was verschickt”, also wie wenn kein Eintrag gesetzt wäre.

Wie ihr schon seht: der Empfangende Mailserver muss SPF unterstützen, auswerten und auch befolgen. Machen viele aber nicht.

Google setzt SPF z.B. ein, mit einem “?all” am Ende, also setzen sie es praktisch doch nicht ein. Bei eingehenden E-Mails werten sie den Eintrag aus und ignorieren das Ergebnis. Eigentlich müssten sie E-Mails ablehnen, die als Absender meine Domain haben aber nicht von meinem Server kommen. Tun sie aber nicht, eben nochmals von anderen Servern aus getestet, die E-Mail wird zugestellt.

web.de hat keinen SPF Eintrag, 1und1 nutzt aktuell ~all.

gmx.de hat einen SPF Eintrag, sogar mit -all, sie nutzen SPF also in diesem Sinne schonmal. Eingehende E-Mails von meinem DSL Anschluss werden schonmal direkt abgewiesen (bzw die Verbindung sofort getrennt), eine E-Mail von einem anderen Server aus wird aber angenommen und im SPAM Ordner abgelegt. Das wäre bei einem Softfail (“~all”) akzeptabel, entspricht aber nicht dem bei einem Hardfail definierten verhalten, so ganz scheinen sie sich nicht zu trauen.

Selbst aol.com, die in Sachen Spambekämpfung einen eigenartigen Ruf haben hat ein “?all” im DNS Eintrag. Von breiter Akzeptanz kann man wohl nicht sprechen. Paypal.com hat ein “~all” eingetragen.

Manche Domains haben zwar ein -all eingetragen, aber deutlich mehr Hosts (IP-Adressen) erlaubt als meine Software auswerten konnte, wodurch die E-Mail auch abgewiesen wurde, twitter.com fällt z.b. hierunter, ob das Problem nur bei dem von mir benutzten ‘tumgreyspf’ auftritt oder auch bei anderen Programmen weiß ich nicht.

Wo ist jetzt der Knackpunkt bei SPF?? Bei E-Mail Weiterleitungen. Theoretisch könnte/sollte man dafür den Absender umschreiben (indem man z.b. einen Envelope-From benutzt)

Ich habe z.b. noch eine E-Mail Adresse bei GMX, welche ich mir auf meinen Server weiterleiten lasse. GMX ändert aber den Absender nicht einwandfrei, wodurch z.b. eine weitergeleitete E-Mail von PayPal (ihr erinnert euch “-all”) abgewiesen wurde, weil GMX nicht authorisiert ist E-Mails für PayPal abzusenden.

Afterbuy versendet seine E-Mails z.b. im Namen und mit dem Absender des Shops, der afterbuy nutzt. Hat dieser eine GMX Adresse wird diese E-Mail mit hoher Wahrscheinlichkeit auch abgewiesen, jenachdem wie das “~all” interpretiert wird.

Dies sind jetzt nur 2 Beispiele die ich auf Anhieb (also ohne große Suche) in meinen Logdateien gefunden habe. Weitere würde ich sicher finden.

Eine weitere mögliche Fehlerquelle sind natürlich noch falsche DNS einträgt, die man z.B. nach einem Serverumzug nicht korrigiert oder ergänzt.

Also gilt für SPF (in meinem Falle) das Gleiche wie für Greylisting: Ja, es kann Spam abwehren, im Gegenzug kann es aber auch erwünschte E-Mails blockieren. Die paar False-positives (fälschlicherweise abgewiesene Mails) die ich hatte, waren aber trotzdem ärgerlich, sie kamen zwar durch falsche Konfiguration anderer Mailserver zustande, treffen mich aber trotzdem.

Fazit:

Greylisting hat früher viel gebracht, heute überwiegen aber die Nachteile. SPF ist im Ansatz zwar “schön”, weil man damit einschränken kann, wer in wessen Namen E-Mails veschicken darf, in der Praxis ist es aber entweder schlecht implementiert oder garnicht eingerichtet. Auch hier überwiegen im Moment die Nachteile.

Ich für meinen Teil bleibe weiterhin aus der Kombination von ix-DNS Blacklist und Spamassassin, den ich aus meinem Spamordner regelmäßig anlerne. Diese beiden “Hürden” leisten bei mir seit langer Zeit eine gute Arbeit, verbessern kann man da wohl nicht mehr sehr viel ohne mehr False-positives zu bekommen (diese bewegen sich im Moment irgendwo im Promille Bereich).

Open-to-wipe Samsung Galaxy Series (english version)

German version is: here.

Someone just posted a nice way to wipe a Samsung Galaxy S3 without any call backs. Since the original source I’ve got via twitter is gone, here is a thread about it: http://forum.xda-developers.com/showthread.php?p=31994542 and here the YouTube video, which demonstrated it on a conference: http://www.youtube.com/watch?v=Q2-0B04HPhs

This is proved to work not only on Galaxy S3 but also on Galaxy S2 devices (test by me and others). I think all Samsung Android ROMs will behave like this.

For testing porposes, I will link to tias tweet which links to his demopage. This demo will wipe (at least S2 and S3 devices) witout any user interaction when opened on your phone!!!

https://twitter.com/tsia/status/250566154165301248

This demo will wipe (at least S2 and S3 devices) witout any user interaction, when opened on your phone!!!

The USSD code used (*2767*3855#) will also work when tramsmittes via MMS or coded in an NFC tag, but a web page has a lot more power than a single MMS. As it seems, there is no way to protect yourself against it, than not surfing any websites on your phone.

If you want to test if your phone also has this vulnerability, you can grab tsias source code and modify it for another USSD code which is more harmless, e.g. the one showing your IMEI number: *#06#.

I think you’d better have a backup of your phone. I love TitaniumBackup on Android for that job.

Update: This seems only to factory-reset your phone, not to wipe it completely. Media stored on the sd-card is not deleted, as mentioned on twitter:

Open-to-wipe Samsung Galaxy Serie

English version is: here.

Eben hat jemand eine schöne Möglichkeit gepostet, wie man ein Samsung Galaxy S3 ohne Rückfrage wipen kann. Leider ist die Quelle schon wieder gelöscht, aber es gibt ja noch andere Quellen, wie z.b. dieser Forenthread zu dem Thema: http://forum.xda-developers.com/showthread.php?p=31994542. Hier gibt es noch ein YouTube Video der Demo http://www.youtube.com/watch?v=Q2-0B04HPhs.

Betroffen ist davon nicht nur das Samsung Galaxy S3 sondern mindestens auch das S2 (von mir eben getestet mit Android 4.0.3). Ich vermute mal, dass alle aktuellen Samsung Android ROMs betroffen sind.

Zum Testen verlinke ich mal auf den tweet von Tsia, der das mal als Webseite eingestellt hat: https://twitter.com/tsia/status/250566154165301248

Dort findet sich der Link auf seine Testseite. Ich verlinke absichtlich nicht direkt drauf, weil “bestenfalls” euer Gerät direkt und ohne Rückfrage gelöscht wird. Ein “mimimi, ich dachte da kommt eine Rückfrage” will ich nicht hören ;-)

Das ganze funktioniert natürlich auch als MMS, NFC Tag und so, aber als Webseite mit Frame hat es viel mehr charm. Der dazugehörige USSD Code lautet: *2767*3855# (auch hier: Das Gerät wird ohne Rückfrage gelöscht)

Wer testen will, ob ein Gerät auch anfällig für solche Angriffe ist kann den Quellcode von Tsias Seite mal auf einen harmloseren USSD Code abändern. (z.B. den zur Anzeige der IMEI: *#06#).

Wie immer in der IT gilt auch für Smartphones: Wer kein Backup hat, hat pech gehabt. Für Android kann ich hier TitaniumBackup empfehlen.

Update: Über Twitter hat mich gestern die Nachricht erreicht, dass hier kein kompletter wipe durchgeführt wird sondern “nur” ein factory reset, der zum Beispiel die SD Karte nicht formatiert.

CyanogenMod 10 Nightlies angekündigt

CyanogenMod hat eben angekündigt, heute Nacht die ersten “offiziellen” Nightlies zu compilieren und dann auf http://get.cm zu veröffentlichen.

Ich hab seit einigen Tagen schon eine Vorabversion von CM10 auf meinem Nexus S und bin sehr zufrieden damit. Es läuft ohne Probleme und Android 4.1 mit Google Now ist einfach gut gemacht.

Ich bin gespannt, was sich zwischen dem schon 2 Wochen alten Build und den nun erscheinenden Nighlies alles verändert hat. Morgen weiß ich mehr :-)

Disclaimer: Nighlies können gravierende Bugs enthalten. Zur Installation muss unter Umständen das Handy komplett gelöscht werden. Man sollte sie nur installieren wenn man ein Backup hat und weiß was man tut!

Twitter und seine Clients

Twitter hat heute massive Änderugen an der Twitter API endgültig angekündigt. Nachdem es schon früher Hinweise gab, dass die API stark eingeschränkt werden soll wurde dies nun heute konkret veröffentlicht: https://dev.twitter.com/blog/changes-coming-to-twitter-api

Primäres Ziel der Einschränkungen sind 3rd-party Twitter Apps. Die Apps die Twitter eigentlich erst so populär gemacht haben.

Auf Android nutze ich seit langem Twicca, auf Symbian hatte ich Gravity (an den bisher auch imho nichts annäherungsweise heran gekommen ist auf Android) und noch davor hatte ich irgendwas anderes gehabt. Auf dem iPad nutze ich im moment die originale Twitter App, das was sie soll kann sie dort. Auf Android hingegen stört mich irgendwie alles an ihr. Auf dem PC hatte ich lange Zeit TweetDeck, bis Adobe den Air Support für Linux eingestellt hat. Neben den aufgelisteten Apps gibt es noch viele weitere, man hat eine echt große Auswahl.

Und genau diese App vielfalt will Twitter nun einschränken, wenn möglich wohl sogar komplett abschaffen. Die Realtime bzw Streaming API gabs ja schon nur in sehr wenigen Anwendungen und ich vermute, dass diese Zahl nun nicht mehr zunehmen wird.

Twitter will keine Apps haben, die das Verhalten der original Twitter-App Nachahmen. Ich finde nicht, dass Twicca und Gravity dies tun. Ja, man kann mit fast allen Clients auch tweets absenden. Twicca kann man im Gegensatz zur original App aber mit einer stattlichen Anzahl Plug-Ins erweitern. Man kann fast alles anpassen, was irgendwie geht. Gravity hingegen kann sehr komfortabel mehrere Accounts gleichzeitig verwalten und unterstützt die Realtime API.

Twitter will seine API Ausrichtung nun mehr auf Firmenkunden und andere Dienste ausrichten und “Klone” ihrer App eher aus dem Weg räumen.

Und ja, Twitter ist in ihrem Bereich Marktführer. Nokia war auch mal Marktführer bei Smartphones, wie AOL bei fast allem was im Internet damals passierte. Vor einigen Jahren war da auch noch StudiVZ. Twitter sollte aufpassen, dass sie nicht die vergraulen, die ihnen mit ihren Daten die Einnahmen ermöglichen: die User.

Verdächtigkeit von Facebook-Verweigerern

Aktuell kommt mal wieder ein bekanntes Thema in den Vordergrund: Machen sich Facebook-Verweigerer verdächtig? Viele Onlinemedien aus den verschiedensten Ländern berichten darüber und verweisen auch gerne darauf, dass Personalabteilungen eine Online-Abstinenz auch sehr verdächtig finden.

Fast alle Artikel haben eins Gemeinsam: Sie stellen das Verweigern von Facebook mit einer kompletten Abstinenz aus dem Internet gleich. Für viele von ihnen besteht das Internet entweder ausschließlich aus Facebook, oder sie unterstellen das jedenfalls dem normalen Leser.

Ich bin nicht auf Facebook, aber nicht weil ich kein Bock auf das Internet hätte sondern einfach weil mir die durchführung von ihrem Geschäftsmodell nicht passt. Ich will nicht alle 3 Tage nachschauen müssen ob die privacy Einstellungen noch so sind wie ich sie gerne hätte, oder ob Facebook diese mal wieder “optimiert” hat und dadurch mehr öffentlich ist als ich möchte. Dafür bin ich bei Twitter, Google+, Xing, in verdiedenen Foren und Mailinglisten, nutze Jabber und Skype, blogge ab und zu und verbringe auch sonst sehr viel Zeit mit Systemen im Netz.

Bin ich trotzdem verdächtig, nur weil ich Facebook nicht Nutze? Das Netz kann viel mehr bieten, als nur Facebook.