Kurz-URLs: Fluch oder Segen?

[Stefan Münz]

Hallo,

Egal was bei einer Diskussion wie dieser hier herauskommt: neue Kurz-
URLs als Redirects für eigentlich gemeinte, recht lange und
umständliche URLs vermehren sich gerade explosionsartig. Kleine
Demonstration: es ist in diesem Augenblick 11:20 Uhr, und ich habe mir
bei tr.im gerade folgenden Link generieren lassen:
http://tr.im/kl1u
Er führt zu folgendem Wikipedia-Artikel:
http://de.wikipedia.org/wiki/Kurz-URL-Dienst

Jetzt aber schreibe ich erst mal weiter. Kurz-URLs haben Vor- und
Nachteile. Hier einige der Vorteile:

* In Umgebungen mit beschränkten Zeichenmengen wie Twitter oder SMS
nehmen normale, häufig sehr lange URLs zu viel Platz weg.

* Wenn URLs massenhaft in Datenbanken gespeichert werden, kann die
Menge der zu speichernden Daten drastisch verringert werden.

* Viele Kurz-URL-Anbieter bieten interessante Zusatz-Services, so z.B.
Statistiken darüber, wie oft Links angeklickt wurden. Das kann sehr
aufschlussreich sein, wenn man an fremden Orten Links auf eigene
Inhalte setzt.

Und einige Nachteile:

* Kurz-URLs verschleiern ihr Linkziel. Das ermöglicht z.B. Links zu
unerbetenen Zielen, die ein User niemals anklicken würde, wenn er die
tatsächliche URL sehen würde.

* Kurz-URLs verwandeln das Web bei entsprechendem Ausbreitungsgrad von
einem Linkweb in ein Redirect-Web.

* Millionen von Links werden ins Leere führen, wenn ein viel genutzter
Kurz-URL-Anbieter ausfällt oder gar für immer seine Pforten
schließt.

Eine gute Übersicht, um sich mal näher mit den Kurz-URLs zu
beschäftigen, bietet dieser Artikel (auf englisch):
http://tr.im/kl6Z
oder in lang:
http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204

Kleines Intermezzo: diesen Link habe ich um 12:08 Uhr generiert (weil
ich leider immer wieder unterbrochen werde von meinen Kleinen, dauert
das Schreiben halt ;-).
Und jetzt die Preisfrage an Insider: wie viele Links wurden bei tr.im
zwischen 11:20 Uhr und 12:08 Uhr generiert (also zwischen "kl1u" und
"kl6Z")? tr.im "nummeriert" einfach durch, und Klein- und
Großschreibung werden unterschieden. Intermezzo Ende.

Oben verlinkter Artikel auf searchenginelande.com behandelt
interessante technische Details und vergleicht die bekannten Kurz-URL-
Services dabei. Ein wichtiger Aspekt ist beispielsweise die Art des
verwendeten Redirects. Das HTTP-Protokoll sieht dazu mehrere
Möglichkeiten vor: permanente Redirects (Meldungsnummer 301) und
temporäre Redirects (302). Der Artikel beschreibt den Unterschied sehr
schön: bei einem 301-Redirect stellt sich der URL-Service selbst in
den Hintergrund und deklariert, dass die Lang-URL die "eigentlich
gültige" URL ist. Bei einem 302-Redirect ist es umgekehrt: der URL-
Service deklariert, die einzig zuverlässige URL zu sein, während das
Redirect-Linkziel nur eine vorübergehende Umleitung darstellt. Auch
aus Sicht des Linkziel-Anbieters ist das nicht unerheblich.

Der Artikel behandelt auch viele weitere interessante Aspekte, die
alle wiederzukäuen den Rahmen dieses Postings sprengen würden.
Schließen wir lieber mit einem weiteren Link zu einem
deutschsprachigen Artikel, der vor wenigen Tagen erschienen ist:

http://tr.im/klcv
bzw.
http://netzwertig.com/2009/04/24/ueberbewertet-wie-saehe-das-web-ohne-kurz-urls-aus-genauso/

Es war übrigens 12:45 Uhr, also 37 Minuten später (ja, ich werde
wirklich oft unterbrochen ;-), und zwischen "kl6Z" und "klcv" liegen
wie viele Links?
(TinyURL, der bekannteste und älteste Kurz-URL-Service, generiert
übrigens ein Vielfaches dieser Zahl)

viele Grüße
Stefan Münz

[Swen Wacker]

Hallo,

On 3 Mai, 12:58, Stefan Münz <stefan.mu...@googlemail.com> wrote:

> * In Umgebungen mit beschränkten Zeichenmengen wie Twitter oder SMS
> nehmen normale, häufig sehr lange URLs zu viel Platz weg.

Der Twitter-Platz-Not gehorchend nutze ich die Kurz-Urls auch. Das
empfinde ich aber nicht als Vorteil sondern als Sachzwang, der der 140-
Zeichen-und-kein-Markup-Konvention geschuldet ist. Ich mach das also
"unter Protest" mit :-)))

> * Wenn URLs massenhaft in Datenbanken gespeichert werden, kann die
> Menge der zu speichernden Daten drastisch verringert werden.

Ich habe Null praktische Ahnung von Datenbank-Performance; wenn ich
mir aber anschaue, wie unser SAP-Dienstleister die zigmillionen
Vorgänge, die bei uns jährlich anfallen, wieder "gesundschrumpfen"
lässt - will heißen: das System zügig bleiben lässt, dann heißt das
für mich, dass man solche Dinge auch datenbankintern lösen kann, also
keine externe Lösung braucht.

> * Viele Kurz-URL-Anbieter bieten interessante Zusatz-Services, so z.B.
> Statistiken darüber, wie oft Links angeklickt wurden. Das kann sehr
> aufschlussreich sein, wenn man an fremden Orten Links auf eigene
> Inhalte setzt.

Leider sind solche Statistiken auch wieder nur begrenzt
aussagekräftig. Es kann ja durchaus sein, dass jemand anders "Dein"
Kurz-URL für eigene Zwecke benutzt; auch diese Aufrufe würde z.B.
tr.im in "Deiner" Statistik mitzählen. Andersherum schaut z.B. tr.im
beim eindampfen des URL nicht nach, ob es einen URL nicht schon mal
hatte, also auf eine vorhandenen Kurz-URL zurückgreifen kann.

> * Kurz-URLs verschleiern ihr Linkziel. Das ermöglicht z.B. Links zu
> unerbetenen Zielen, die ein User niemals anklicken würde, wenn er die
> tatsächliche URL sehen würde.

Grundsätzlich ist gegen eine "Verschleierung" nicht wirklich viel zu
sagen, <a href="linksherum.html">rechtsherum</a> ist ja auch so eine
Art "Verschleierung". Aber immerhin ist die Verschleierung für den
kompetenten Nutzer _vor_ dem Klick durchschaubar. Bei der Kurz-URL
jedoch nicht. Insoweit erinnert mich das Kurz-URL-Konzept gefühlt ein
wenig an die frames bzw iframe-Poblematik.

> * Kurz-URLs verwandeln das Web bei entsprechendem Ausbreitungsgrad von
> einem Linkweb in ein Redirect-Web.

Ja, fürchterlich. Man stelle sich einfach nur vor, TBL wäre auf die
absolut bescheuerte Idee gekommen, alle gesetzten Links auf eine DB
beim CERN zu lenken. Und dort wäre der Link dann aufgelöst bzw
redirected worden ... Ein völlig unnötiger Zentralismus, der das
System ohne Grund angreifbar und störungsanfällig gemacht hätte. Mal
ganz zu schweigen von den Begehren der Internet-Ausdruckern und
Zensurulas, denen sicherlich virtuell einer abgeht, wenn sie erst auf
die Idee gekommen sind, solche zentralen Dienstleister zu knechten.

> * Millionen von Links werden ins Leere führen, wenn ein viel genutzter
> Kurz-URL-Anbieter ausfällt oder gar für immer seine Pforten
> schließt.

Dieses Argument allein reicht, um die grundsätzliche Abneigung gegen
Kurz-ULR unangreifbar zu machen.

Ich habe das ja schon mal neulich gefragt: Kann man so etwas nicht
Browserintern gestalten. So, wie ich eine Datei zippe und mit einen
anderen Programm jederzeit wieder entzippen kann, so müsste es doch
möglich sein, eine URL lokal zu kürzen, so auf die Reise zu schicken
und beim Empfänger wieder entpacken zu lassen. Sicher, bei eher kurzen
URL wird da nicht viel Einsparung rausspringen. Aber bei längeren
URL...?

Gruß

Swen

P.S. Und: wie oft wurden die tri.m-Adressen schon angeklickt :-)

[Stefan Münz]

Hallo Swen,

> Ich habe Null praktische Ahnung von Datenbank-Performance; wenn ich
> mir aber anschaue, wie unser SAP-Dienstleister die zigmillionen
> Vorgänge, die bei uns jährlich anfallen, wieder "gesundschrumpfen"
> lässt - will heißen: das System zügig bleiben lässt, dann heißt das
> für mich, dass man solche Dinge auch datenbankintern lösen kann, also
> keine externe Lösung braucht.

Das ist allerdings völlig richtig. Facebook hat das besser gelöst mit
seiner Möglichkeit, an einen Pinnwandeintrag einen Link anzuhängen
oder den Pinnwandeintrag von vorneherein als Link zu deklarieren.
Manchmal ist der Automatismus dort zwar auch nicht das Gelbe vom Ei,
und zwar aus dem Grund, weil als Linktext grundsätzlich der Inhalt des
<title>-Elements der Zielseite verwendet wird. Aber isg. finde ich das
Verlinken auf Facebook wesentlich angenehmer als bei Twitter. Auch
wenn ich bei Facebook keine Statistiken darüber habe, wie oft Links
angeklickt werden.

> Leider sind solche Statistiken auch wieder nur begrenzt
> aussagekräftig. Es kann ja durchaus sein, dass jemand anders "Dein"
> Kurz-URL für eigene Zwecke benutzt; auch diese Aufrufe würde z.B.
> tr.im in "Deiner" Statistik mitzählen.

So weit ich es einschätzen kann, scheint das zumindest bei tr.im aber
nicht der Fall zu sein. Offenbar wird für die Statistik der eigene
Account bei tr.im mit berücksichtigt.

> Ich habe das ja schon mal neulich gefragt: Kann man so etwas nicht
> Browserintern gestalten. So, wie ich eine Datei zippe und mit einen
> anderen Programm jederzeit wieder entzippen kann, so müsste es doch
> möglich sein, eine URL lokal zu kürzen, so auf die Reise zu schicken
> und beim Empfänger wieder entpacken zu lassen. Sicher, bei eher kurzen
> URL wird da nicht viel Einsparung rausspringen. Aber bei längeren
> URL...?

Es gibt zwar Kompressionsverfahren, die effizienter als ZIP sind, aber
eine URL mit vergleichbaren Mitteln zu komprimieren wird in den
meisten Fällen keine wirklich relevanten Kompressionsraten erzielen.
Jedenfalls nicht annhähernd vergleichbar mit den Kurz--URLs.
Hashverfahren wie MD5 sind nicht geeignet, weil sie keinen "Rückweg"
haben.

Sinnvoller wäre vielleicht einezentrale Lösung, aber nicht auf Basis
eines einzelnen Webservices, sondern auf einer Ebene wie etwa dem
Domain Name Service.

viele Grüße
Stefan Münz

[Stefan Münz]

Hallo,

Tim Tepaße hat mir noch einen interessanten Link zum Thema zugesteckt:

http://joshua.schachter.org/2009/04/on-url-shorteners.html

Der Autor geht in dem Artikel ebenfalls auf die Vor- und Nachteile
ein. Auch die hier angesprochene Redirect-Problematik wird
thematisiert, und zwar so:

"The worst problem is that shortening services add another layer of
indirection to an already creaky system. A regular hyperlink
implicates a browser, its DNS resolver, the publisher's DNS server,
and the publisher's website. With a shortening service, you're adding
something that acts like a third DNS resolver, except one that is
assembled out of unvetted PHP and MySQL, without the benevolent
oversight of luminaries like Dan Kaminsky and St. Postel."

Also eine zusätzliche Applikationsschicht, die zur Ausführung eines
Hyperlinks benötigt wird, und die an anbieter-individuelle, meist mit
PHP und MySQL schnell zusammengeschusterte Lösungen gebunden ist, und
die damit weit weg ist von der Weitsichtigkeit, mit der genuine
Internet-Technologien eigentlich entwickelt werden sollten.

Ja, vorbei die Zeiten, da man sich noch die Zeit nahm, eine Internet
Draft einzureichen, diskutieren zu lassen, in der Hoffnung, dass
daraus am Ende vielleicht eine RFC werden möge. Stattdessen zählt der
kurzfristige Erfolg einzelner Anbieter und das Bestreben, dass
möglichst viele Links über den eigenen Service generiert werden. Was
in zehn Jahren mit den 780 Millionen Links, die der Service bis dahin
generiert hat, werden soll, vielleicht weil MySQL eingedampft wird
oder die Betreiber kein Geld mehr für weiteren Infrastrukturausbau
haben, wird nicht bedacht. Bzw. der web-ökologische Flurschaden, der
dadurch entstehen würde, wenn so viele Links plötzlich ins Leere
gehen.

Kurz-URLs sind also durchaus nicht unschädlich für das Herz des Web,
nämlich seine Netzstruktur, die auf Verlinkung basiert. Man kann
natürlich dagegen halten, dass Kurz-URL-Links meistens in Umgebungen
und für Zwecke verwendet werden, die nicht unbedingt maßgeblich sind
für den dauerhafteren Teil der Netzstruktur. Schließlich werden sie
vorwiegend für schnelles Gezwitscher verwendet, das selber wieder auf
zentralen Plattformen wie Twitter abläuft, die wohl auch nicht ewig
existieren werden. Dennoch lohnt es sich finde ich, darüber
nachzudenken, wie man Kurz-URLs im Sinne des Internet, also
"weitsichtig und nicht-proprietär" implementieren könnte. Am
wahrscheinlichsten erscheint mir eine Lösung, die das DNS-System, das
ja eh schon zu den vergleichsweise abenteuerlichen Konstruktionen im
Netz gehört, um eine Funktionalität für Kurz-URLs erweitert. Aber die
entsprechende Internet Draft soll bitte jemand anderes schreiben ...
*g*

viele Grüße
Stefan Münz