
Im Grunde genommen ist es recht einfach eine Internetdomäne von einem Hoster zu einem anderen umzuziehen. Interessanterweise sind dennoch ein paar Stolperfallen vorhanden, die man vermeiden sollte. Dieser Artikel erklärt daher wie ein Domänenumzug funktionert.
Zu beachten ist: Ein Domänenumzug entbindet nicht von den Zahlungsverpflichtungen für eine Domäne. In der Regel werden von den diversen Providern Verträge für die Registrierung und das Hosting von Domänen mit zwei Jahren Laufzeit angeboten. Wird eine Domäne vorzeitig umgezogen sind grundsätzlich die für den Vertragszeitraum festgelegten Zahlungen zu leisten, auch wenn man keine Leistung mehr von seinem alten Provider erfährt. Glücklicherweise bewegen sich diese Kosten in geringer Höhe: Sie liegen ganz grob im Bereich von einem Euro pro Monat pro Domäne. Das ist nicht viel. Doch muß man bedenken, daß oft mehrere verschiedene Domänen für einen Internetauftritt registriert werden, so daß sich durchaus schnell ein Vielfaches des Betrages ergeben wird. Privatleute sind das dann schon wieder Kosten, die sie spüren. Freilich - im Gewerblichen Umfeld spielen diese Kosten keine Rolle.
In der Regel wird ein Umzug wie folgt ablaufen:
Für einen Domänentransfer sollte man sich Zeit nehmen, da man nach jedem Schritt im Transferprozess dem bzw. den Providern etwas Zeit geben muss. Im Grunde kann der Transfer innerhalb einer Woche passieren, doch ist es nicht ausgeschlossen, dass sich die ganze Angelegenheit auch über zwei Wochen und mehr hinziehen kann. Gilt es bei Projekten Termine einzuhalten ist der Transfer frühzeitig anzustoßen um nicht in Bedrängnis zu geraten.
Wichtig ist es den Transfer genau zu verfolgen. Der Transfer muss zwingend innerhalb von 4 Wochen abgeschlossen werden! Sobald die Domäne beim alten Provider gekündigt ist, ist sie gekündigt. Findet kein Transfer im Zeitraum von 4 Wochen statt, wird diese Domäne frei gegeben. Dies bedeutet: Sie kann von jedem beliebig erneut registriert werden! Und damit fangen die Probleme an.
Wir haben heute die Situation, dass findige Geschäftemacher - zum Beispiel in China - systematisch alles an ehemals registrierten .com-Domänen abgraben was möglich ist. Geht der Domänentransfer schief muß man davon ausgehen, daß man seine Domäne plötzlich mit Werbung befüllt bei einem chinesischen Hoster wieder findet. Wenn man ganz viel Glück hat läßt sich der neue Besitzer dazu überreden, diese Domäne wieder zu verkaufen. Und wenn man noch mehr Glück hat beitet einem der neue Besitzer die Domäne sogar extra zum Kauf an. Ist man in diese Falle getappt muß man letztendlich den Preis akzeptieren, den der neue Besitzer dafür einfordert. Im Minimum sind das mehrere hunderte von Euro (bzw. Dollar). Bei wichtigen Domänen dürften die Kosten noch weitaus höher liegen.
Es empfiehlt sich grundsätzlich einen solchen Verkauf über eine Domänen-Auktionsplattform abzuwickeln. Das kostet zwar ca. 50 Euro zusätzlich, doch hat man anderenfalls keinerlei Garantien über die Abwicklung des Verkaufs: Es ist schwer bis gar nicht ermittelbar wer der neue Besitzer ist. Und in China oder einem anderen Land den neuen Besitzer persönlich aufzuspüren dürfte reichlich schwierig sein.
Sobald der neue Provider die Information erhalten hat, welche Domäne transferiert werden soll, kann man beim neuen Provider bereits EMail-Konten anlegen. Man erhält so einen doppelten Satz an EMail-Konten: Einen beim alten Provider und einen beim neuen Provider. Sobald der DNS-Eintrag geändert wird übernimmt ab diesem Zeitpunkt der neue Provider vollständig und man wird dann automatisch vom neuen Provider die EMails holen. Sofern man keinen eigenen Web-Server betreibt ist eine Umkonfiguration im EMail-Client natürlich erforderlich: Die Adresse des POP3/SMTP bzw. IMAP-Servers des neuen Providers muß man statt den Daten des alten Providers eingeben. Schon kann man EMails vom neuen Provider abrufen. Es empfiehlt sich hier einen Testlauf durchzuführen: Das Abrufen ist bereits einige Zeit vor dem Abschluß des Transfers der Domäne möglich. So kann man das Abrufen im Vorfeld testen und erlebt dann keine Überraschung, wenn der DNS-Einträg geändert wurde und damit der Transfer abgeschlossen ist.
Man tut gut daran möglichst schnell den Domänentransfer abzuwickeln. Das ist nicht weiter wild, aber die verschiedenen Schritte müssen genau so wie geschildert durchgeführt werden. Und man sollte dafür einige Zeit einplanen.

Werter Leser! Seit einigen Tagen bringt die Idee eines Bloggers die Netzwelt durcheinander. Der Vorschlag lautet: Werft JavaScript weg und integriert Mono um statt JavaScript .Net als Plattform zu verwenden. Abgesehen davon, daß damit nun eine wohl definierte, typisierte, objektorientierte Sprache zur Verfügung stehen würde, stünde damit eine Sprache zur Verfügung, in der man auch große Web-Anwendungen deutlich leichter modularisierter und wiederverwertbar entwickeln kann, als das bisher der Fall ist.
In diesem Zusammenhang muß ich unweigerlich an etwas ganz anderes denken. Dazu müssen wir 15 Jahre in der Zeit zurück gehen. 15 Jahre - das bedeutet, daß damals gerade mal der Intel Pentium erschienen war. Rechner waren damals vielfach noch mit Windows 3.1 ausgestattet. Microsoft hatte gerade einen GUI-Quantensprung geschafft und Windows 95 auf den Markt gebracht. In dieser Zeit - vor 15 Jahren - erblickte die Programmiersprache Java das Licht der Welt. Das Novum: Programme werden in Bytecode übersetzt und nicht in nativen Maschinencode und von einem Interpreter ausgeführt, statt direkt vom Prozessor verarbeitet zu werden. Dem zu Grunde lag das Konzept der "Virtual Machines", also Laufzeitumgebungen, die Programme ausführen. Und warum ist das für uns interessant? Java lief im Web-Browser! Die berühmten Java Applets, die heute keine Rolle mehr spielen.
Vor 15 Jahren waren Browser einfachste Anzeigegeräte für Internetseiten, die man über HTTP holen konnte. CSS wurde zu diesem Zeitpunkt gerade noch erfunden. (Der Standard CSS1 erblickte erst 1996 das Licht der Welt.) Web-Anwendungen beschränkten sich damals primär darauf, ein bischen was interaktives eingebettet in einer Webanwendung darzustellen. (Die Vorform von Flash war gerade eben erst erfunden worden und noch nicht verbreitet.)
Über die Jahre haben sich die Dinge massiv weiterentwickelt. Ein Browser ist heute nicht mehr ein einfaches Anzeigegerät von Inhalten sondern eine Programmierplattform. Vor 15 Jahren entwickelte man Anwendungen, die man ins System installierte. Heute kann man Anwendungen entwickeln, die von einem Browser ausgeführt werden. Die Binaries dazu liegen dabei nicht mehr lokal auf der Platte sondern sind Textdateien, die auf einem Server liegen. Sie werden letztendlich in Form von HTML-Webseiten verbunden mit CSS und eingebettetem JavaScript geladen und vom Browser ausgeführt. Der Browser mutiert damit zu einer Programmausführungsplattform. Diese Programme sind Webanwendungen: Spezielle Fachanwendungen, aber auch einfach nur Online-Shops, Suchmaschinen oder Internetseiten mit Blogs, wie die, auf der Sie sich gerade befinden.
Es gibt offenkundig eine Bewegung weg von installierten Anwendungen hin zu Anwendungen, die über das Netz geladen und ausgeführt werden. Der Nachteil ist klar: Hat man kein Netz, hat man keine Anwendung. Der Vorteil liegt aber ebenfalls auf der Hand: Man spart sich die Mühe der Installation einer Anwendung.
Kehren wir zurück zu der Idee, eine .Net-basierte Laufzeitumgebung (-> Mono) in den Browser zu integrieren und statt JavaScript C# oder eine andere .Net-Sprache zu verwenden. Dies wäre ein Quantensprung: Die Laufzeitumgebung im Browser könnte dann noch deutlich komplexere Web-Anwendungen ermöglichen. Zeichenprogramme und Texteditoren, ja ganze Entwicklungsumgebungen könnten dann als Webanwendungen realisiert und direkt im Browser ausgeführt werden. Die Verlagerung weg vom Betriebssystem hin zu einem Browser als Ausführumgebung wäre dann komplett.
Allerdings haben wir hier ein Problem. Wie wir von JavaScript und CSS her kennen ist es schwierig Standards durchzusetzen. Viele Browser hatten zumindest bisher massive Eigenheiten, allen voran der Internet Explorer. Ich vermute daher, es dürfte schwierig werden über alle Browser hinweg eine einheitliche .Net-Laufzeitumgebung zu etablieren, zumal alle Browser bis auf den IE sicherlich eine Implementierung von Mono nutzen würden und Microsoft stattdessen sicherlich seine eigene Implementierung nutzen wird. Microsoft wird kaum einen fremden Klon eines Produktes des eigenen Hauses in den IE integrieren. Unterschiede sind dann vorprogrammiert und der Kampf der Browser um Marktanteile wird aufs neue entfacht. Es würde daher auf zwei Dinge hinaus laufen: Bestimmte Anwendungen würden nur in bestimmten Browsern laufen. Und da viele Unternehmen auf Grund nicht ganz nachvollziehbarer Entscheidungen ausschließlich auf Internet Explorer setzen wären Probleme und Inkompatibilitäten vorprogrammiert. Ferner würden Techniken wie Java Applets, JavaFX, Flash und Silverlight / Moonlight und andere vollständig obsolet werden.
Es würde wohl darauf hinaus laufen, daß die Technik ausschließlich in eng begrenztem Umfeld eingesetzt werden könnte. Und wenn dann meistens in der Art, daß geprüft wird, ob eine Kompatibilität mit dem jeweiligen Browser existiert und - falls nicht - eine "tut uns Leid, geht bei Ihnen nicht" - Anzeige erscheinen müßte. Wenn Opera (noch) kein .Net integriert hat funktioniert die betreffende Web-Anwendung schlichtweg nicht in allen Opera-Browsern nicht. Jetzt ist Opera aber nur eine Randerscheinung. Viel schlimmer ist das mit dem IE: Dieser Browser besitzt Schätzungen zu Folge einen Marktanteil von etwa 60%. Ein Großteil aller User wäre damit nicht in der Lage, die Webanwendung auszuführen, wenn man diese auf .Net-Basis realisiert hat. Eine Situation, die jeglichen kommerziellen Einsatz dieser Technik ad absurdum führt.
Einer solchen Technik würde es also so ähnlich gehen, wie den Java-Applets. Sie würde nur in wohl definierten Bereichen einer Internetseite verwendet werden und kaum genutzt werden können. Und ich spekuliere weitere, wenn man schon die mächtigen Möglichkeiten der Sprache nutzen kann, würden die Menschen sich vielleicht sogar vom Konglomerat aus (X)HTML/CSS/SVG in der Anzeige abwenden und statt dessen lieber ihre darzustellenden Inhalte programmatisch selbst rendern. Dann käme die Integration von .Net wirklich dem gleich, was wir mit Java-Applets hatten bzw. haben.
Nun, der Gedanke, .Net zu integrieren ist dennoch äußerst interessant. Die Frage ist aber, ob man nicht den umgekehrten Weg gehen sollte: Die Anzeige von Webanwendungen in .Net integrieren und eine Plattform schaffen, die Awendungen verwaltet. Werter Leser, überlegen wir noch mal, warum Browser-Anwendungen so beliebt sind. Denn wenn man bedenkt, daß Web-Anwendungen (zumindest wenn es komplexe Fachanwendungen sind) einen immens höheren Aufwand in der Erstellung verursachen als wenn man sie als Standalone-Anwendungen umsetzt, muß es gute Gründe für Webanwendungen geben:
Diese Ziele lassen sich auch auf anderem Weg technisch erreichen. Man könnte eine (.Net-basierte) Plattform schaffen, in der Anwendungen automatisch als Modul hineingeladen und ausgeführt werden. Updates könnten automatisiert durchgeführt werden. Die Einfachheit der Änderungen wäre gegeben, wenn die Anwendung grundsätzlich im Quelltext vorliegen würde und erst lokal in der Ausführumgebung in Binärcode übersetzt werden würde. Und die Integrierbarkeit ist eigentlich jetzt schon gegeben: Kaum eine Anwendung heute ist nicht komponentenbasiert.
Eigentlich war es Aufgabe des Betriebssystems, eine solche Ausführumgebung zu sein. Und wenn man sich die Paketverwaltung von z.B. Linux ansieht, wie einfach hier z.B. mit Synaptic neue Anwendungen installiert und über die Paketverwaltung auch automatisiert geupdated werden können, unterscheidet sich das - bis auf die Integration mit dem Besuchen von Internetseiten - interessanterweise gar nicht so extrem von obigen Anforderungen.
Es wäre durchaus überlegenswert, das Konzept einer solche Paketverwaltung als Basis zu nutzen und sie plattformübergreifen zu etablieren. Stellen Sie sich vor, Sie haben nicht einen Browser, sondern ein anderes Ding, in dem Sie einen URL eingeben. Dieses andere Ding ist eine Laufzeitumgebung und läft gemäß des URLs automatisch die betreffende Anwendung über das Netz und führt sie lokal aus. Eine Installation ist nicht mehr erforderlich. Updates auch nicht: Darum kümmert sich die Paketverwaltung. Auf Grund des Konzepts der Virtual Machines würde sich die Anwendung sogar auf Teilbereich des Systems beschränken lassen um die Sicherheitsproblematik zu adressieren (die in diesem Blog sogar noch außen vor gelassen wurde). Stellen Sie sich vor: Sie surfen im Internet, klicken auf einen URL und automatisch wird diese Anwendung über das Netz geladen und ausgeführt. Kein lästiges Installieren mehr, kein lästiges updaten mehr. Plattformübergreifend. Und das Beste: Dadurch, daß es .Net Anwendungen sind, könnten sie alle auf einem einfachen Weg eine ganze Menge mehr leisten, als es Web-Anwendungen - wenn überhaupt - nur mit Klimmzügen könnten. Und würde man noch die Anzeige von Internetseiten als Komponente in die .Net-Laufzeitumgebung (plattformübergreifend) integrieren hätte man exzellente Möglichkeiten für eine leichte verschmelzende Nutzung aller Technologien.
Das sind nur Überlegungen. Der Siegeszug der Web-Anwendungen wird in jedem Fall weiter gehen. Die Browser werden immer komplexer und aufwändiger werden. Und die eingesetzten Technologien immer vielfältiger und umfangreicher. Daran besteht kein Zweifel. Eine Integration von .Net in den Browser wäre flächendeckend schwierig, aber grundsätzlich hoch interessant. Fraglich ist, ob man aber nicht lieber die Installation und Verwaltung von Anwendungen im Betriebssystem überarbeiten und aufpolieren sollte, statt alles im Browser nachzubauen. Wir werden sehen wie sich die Dinge entwickeln. Es bleibt jedenfalls spannend!

Folgendes Problem: Ich wollte einige hübsche Bildschirmhintergründe habe. Diese sollten möglichst schlicht sein aber trotzdem modern und edel aus sehen. Zu unruhig sollten Bildschirmhintergründe nicht sein, denn dann wirken sie nicht und man sieht sich irgendwann dran satt. Fotos scheiden also schon mal weitgehend grundsätzlich aus.
Die Lösung ist sehr einfach: Generieren. Man nehme also einen Computer, gebrauche eine Programmiersprache seiner Wahl und erzeuge sich Grafiken einfach selbst.
Sofern bereits eine Grundidee vorhanden ist, gelingt ein solcher Lösungsansatz. Und diese Grundidee ist vorhanden: Der Bildschirmhintergrund soll Blau sein, aber nicht gleichmäßig. Er soll ein klein wenig Abwechslung besitzen. Aus dieser Problemstellung folgt unweigerlich, daß man tendenziell die Farbe angeben können muß. Beispielsweise könnte eine Ecke etwas heller wie eine andere sein und dazwischen muß es einen weichen Farbübergang geben. Man muß Farbpunkte auf einer Grafik angeben und dazwischen muß dann interpoliert werden. Und um noch einen Touch Professionalität hinein zu bekommen sollte ein kleines Logo hinein gerendert und dann mit einem Filter über die Grafik drüber gegangen werden.
Es war nicht schwer das in die Tat umzusetzen. Der Vorteil liegt auf der Hand: Sind einmal die Farben ausgewählt, so kann man mit dem gleichen Programm beliebig viele unterschiedliche Auflösungen generieren. Und damit wird gleich noch ein Problem gelöst: Da ich selbst gerne verschiedene Computer mit unterschiedlicher Auflösung benutze war es bisher für mich immer schwierig mit dem Skalieren: Die Seitenverhältnisse sind von Gerät zu Gerät nämlich unterschiedlich. Wird der Bildschirmhintergrund generiert, ist man wesentlich freier in der Gestaltung.
Das Ergebnis dieser Bemühungen ist hier zu finden. Werfen Sie doch mal einen Blick drauf!

Im Normalfall setzt sich ein Grafiker hin, nimmt sein Photoshop oder etwas ähliches und beginnt Grafiken zu malen. Er pinselt und filtert, selektiert und verschiebt wie er gerade lustig ist, bis die Grafik so ist, wie er sie gut findet.
Was aber, wenn nicht nur eine Grafik sondern dutzende zu erzeugen sind? Und die sollen auch noch alle ählich aussehen! Besonders schwierig ist dabei, nach mehreren Monaten weitere Grafiken im gleichen Stil erstellt werden sollen. Was tun? Jeden Handgriff aufschreiben um nach einiger Zeit diese für eine neue Grafik wiederholen zu können? Das ist schwierig und fehleranfällig.
Statt des Pinselns jeder einzelnen Grafik wurde für diesen Internetauftritt, den Sie, lieber Leser, vor sich sehen, andere Wege beschritten. Diese ungewöhnliche und meiner Meinung nach äußerst praktikable Vorgehensweise möchte ich an dieser Stelle kurz vorstellen.
Viele der Grafiken, die Sie, lieber Leser, auf diesen Seiten sehen, wurden aus Einzelteilen generiert. Die zentrale Idee ist sehr einfach: Warum kann man die Handgriffe, die ein Grafiker üblicherweise machen muß, nicht einfach von einem Programm erledigen lassen?
Betrachten Sie doch einmal die folgende Grafik als Beispiel: linst.png - Es handelt sich dabei um eine Grafik, die beim Linux-Installations-Seminar angezeigt wird. Überlegen Sie: Was für Arbeitsschritte müssen getan werden, um diese Grafik zu erzeugen?
Ausgangsbasis ist natürlich eine bereits existierende Fotographie, die auf die richtige Größe gebracht wurde. In die Grafik muß das Band, das sie sehen, hineingerendert werden. Dazu muß in einem ersten Schritt eine entsprechende Grafik (programmatisch) erstellt werden. Und zwar unter Berücksichtigung des Alpha-Kanals wo erforderlich. Das Band soll schließlich in eine Richtung schwächer werden. Die Schrift soll aber kräftig sein und keine Transparenz besitzen. Diese Detailgrafik wurde mit Hilfe eines einfachen Programms erzeugt. (Entsprechende Möglichkeiten gibt es dazu heute in fast jeder Programmiersprache.) Die Detailgrafik wurde dann - in einem letzten Arbeitsschritt - an der richtigen Stelle mit der Fotographie verschmolzen. Fertig ist das Endergebnis!
Natürlich ist es vergleichsweise aufwändig ein entsprechendes Programm dafür zu schreiben. Es dauert in jedem Fall deutlich länger, als eine solche Grafik quasi mit der Hand zu malen. Zumindest bei den ersten Grafiken. Sollen mehr als nur eine Hand voll Grafiken dieser Art erstellt werden und sollen diese auch noch weitgehend identisch aus sehen, kann das Programmieren der Grafikerstellung seine Vorteile ausspielen. Und sollte man auf die Idee kommen, die Schrift später doch noch mal zwei Pixel weiter nach links oder rechts versetzen zu wollen, so kostet das im Grunde keinen Aufwand mehr: Eine winzige Änderung am Programm und alle Grafiken, die man erstellt, werden nach den neuen Wünschen erzeugt. Und wird nach einiger Zeit eine weitere Grafik benötigt, ist es trivial, das Programm zu erweitern.
Es ist bemerkenswert, wenn man sich überlegt, wo man überall das Programmieren sinnvoll einsetzen kann. Das Schreiben von Programmen ist gleichbedeutend mit dem Gebrauch von Klebeband und Kabelbindern: Es ist Werkzeug. Ein Handwerkszeug, das man getrost sehr vielseitig benutzen und einsetzen kann - und sollte. Daher möchte ich diesen Artikel auch mit einem kleinen Appell schließen: Benutzt dieses Handwerkszeug! Dafür ist es schließlich gemacht!

golem.de und zdnet.de berichtete von "sicheren" USB-Sticks, auf die man trotz Verschlüsselung Zugriff erhalten könne. Wenn ich die Berichte richtig interpretiere, betrifft das Problem USB-Sticks von Sandisk und Kingston, die als "besonders sicher" gelten sollen. Das Problem liegt dabei offenbar darin, daß die Authentifizierung per Software geschieht, also ein Stück Software nach Benutzername und Passwort fragt und dann dem USB-Stick signalisiert, daß er die Daten freigeben darf. Diese Signalisierung geschähe gemäß Bericht dadurch, daß ein konstanter (!) Wert an den USB-Stick gesendet wird. Dieses Sicherheitsproblem haben anscheinend Mitarbeiter der Firma Syss gefunden. Ihnen ist es offenbar gelungen, diesen konstanten Wert mit eigener Software an die USB-Sticks zu senden. Damit umgeht man offenbar die Passwortprüfung und kann so jeden beliebigen USB-Stick "entschlüsseln": Man muß ihm lediglich signalisieren, das Passwort wäre erfolgreich eingegeben worden.
Golem spricht in diesem Zusammenhang von einem "Fehler". Bleiben wir ganz kurz bei diesem Begriff. Was ist ein "Fehler"? Werter Leser dieses Blogs, lassen Sie uns kurz über diesen Begriff sinnieren.
Ich habe mir die Freiheit genommen und anläßlich des geschilderten Sicherheitsproblems in der Wikipedia unter "Fehler" nachzuschlagen. Der Wikipedia-Beitrag ist sehr lesenswert: Ich hätte nicht gedacht, daß man so viel über Fehler schreiben kann. Es heißt dort: "Ein Fehler ist eine Abweichung von einem optimalen oder normierten Zustand oder Verfahren in einem bezüglich seiner Funktionen determinierten System." Weiter führt Wikipedia aus, es gibt erwartete Fehler und unerwartete Fehler. Nach weiteren Ausführungen findet man dort auch Informationen speziell zu Software-Fehlern, sowie über Einteilungen wie Denk-, Planungs- und Handlungsfehler.
Liebe Mitarbeiter der benannten namhaften Firmen. Man muß kein Sicherheitsexperte sein, um zu wissen, daß es keinerlei Sicherheit bedeutet, wenn das Senden eines konstanten Wertes an einen USB-Stick ausreicht, um diesen zu entsperren und die Daten zugänglich zu machen. Es handelt sich somit nicht um einen Fehler im klassischen Sinn - denn diese sind unerwartete Fehler - sondern um einen erwarteten Fehler. Ich wage sogar die Vermutung aufzustellen, daß es sich um einen Denk- und Planungsfehler handelt. Wenn ich das richtig interpretiere basiert dieser darauf, daß man etwas möglichst günstig am Markt anbieten wollte, weil man eine Marktlücke sah. Substanz spielte dabei eine untergeordnete Rollle: Hauptsache man hatte etwas, das man schön verpackt in die Regale stellen wollte. Auch wenn auf diesen Verpackungen dann "Sicherheit" drauf stand: Mit Sicherheit hat das Ganze aber nichts zu tun. Wenn die Sachverhalte, so wie von Golem und ZDnet dargestellt stimmen, mutet es geradezu rührend naiv an, wenn man auf das Prinzip "Hoffnung" setzt: Nämlich darauf hofft, daß niemand außer der eigenen Crypto-Software den konstanten Datenblock an den USB-Stick schickt.
Es ist nicht erforderlich, ein Experte in diesen Dingen zu sein, um zu verstehen, daß Sicherheit nicht durch einfaches Verbergen - oder gar durch ein Gesetz - erzeugt werden kann. Ein USB-Stick kann dann - und nur dann - als sicher eingestuft werden, wenn eine Überprüfung eines Geheimnisses (z.B. eines Passworts) innerhalb des USB-Sticks geschieht. Sofern die Authentifizierung in Software geschieht, also dem USB-Stick vorgelagert ist, kann nie eine Sicherheit garantiert werden. Software ist nämlich immer veränderbar. Und zig-Millionen von Leuten auf dieser Welt können eine neue Software schreiben, die dem USB-Stick eine einfache Freigabe signalisiert. Die Software müßte sich also in irgend einer Weise dem USB-Stick signalisieren, daß sie die "richtige" Software ist. Das ist kompilziert, möglicherweise sogar gar nicht möglich. Nein, der einzige Weg, einen sicheren USB-Stick zu schaffen, besteht darin, daß eine Passwortüberprüfung innerhalb des USB-Sticks geschieht.
Jeder weiß: Wir leben in einer Welt voller Kompromisse. Wir alle bewegen uns im Spannungsfeld bestehend aus geschäftlichem Interesse (welches uns ernährt) und Qualität. Natürlich ist das geschäftliche Interesse von hoher Bedeutung: In diesem Fall ging es darum, "sichere" USB-Sticks zu verkaufen. Dieses geschäftliche Interesse ernährt alle Mitarbeiter von Firmen, die Vertriebler, Marketing-Experten und auch die Techniker und Softwareentwickler. Man darf aber nicht vergessen, daß Substanz von wesentlicher Bedeutung ist. Stimmt nämlich die Qualität nicht, weil das Produkt nicht hält, was es verspricht, so sind die Kunden enttäuscht. Dann erfüllt das Produkt auch keine geschäftlichen Interessen mehr. Der Schuß kann sogar nach hinten los gehen: Man verliert seinen Ruf als Qualitätsschaffender und damit seine Kunden. Es ist also kurzsichtig gedacht, bei Qualität Abstriche zu machen. Wenn man das macht, muß man sehr genau wissen, was man tut. Das erfordert ein gewisses technisches Verständnis über das Produkt, hier die USB-Sticks. Mit diesem technischen Verständnis lassen sich erst die notwendigen Abwägungen sinnvoll vornehmen. Mir scheint, in diesem Fall wurden die Abwägungen nicht mit ausreichend technischem Verständnis durchgeführt. Und damit darf man das so entstandene Problem durchaus, so denke ich, als "erwartete Fehler" bzw. "Denkfehler" einstufen. Nun, Schwamm drüber: Das nächste Mal wirds besser!

Die Politik, Banken und Wirtschaftsinstitute überschlagen sich wöchentlich mit Negativmeldungen. Fast könnte man meinen, ein Wettbewerb wäre ausgebrochen. Nichts desto trotz lassen sich mindestens die Deutschen davon nicht beirren: Es wird weiter gearbeitet wie bisher, Wirtschaftskrise hin oder her. Ganz so als gäbe es sie nicht. Was sollte man auch tun? Wenn eine Rezession kommt, wird man nichts daran ändern, wenn man deprimiert die Hände in den Schoß legt. Im Gegenteil: Wir alle haben bereits die Ärmel hochgekrempelt und werden das auch weiter tun. Denn wie jede Schwierigkeit ist auch eine Wirtschaftskrise als Chance zu verstehen. Wie lautet doch ein beliebter Spruch der Führungsetage? "Es gibt keine Probleme, nur Lösungen!" Auch wenn dieser Spruch etwas anmaßend und überzogen ist, soll dies der Leitgedanke für diesen Artikel über die Krise sein. Dieser Artikel trägt Informationen zusammen, die dem Leser möglicherweise neue Wege und Impulse geben kann, die Krise als Chance und damit als etwas positives wahr zu nehmen.
...weiterlesen
Fast jeder Geschäftsmann assoziiert mit "Raubkopien" etwas bedrohliches. Es ist allseits bekannt, daß die Musik- und Filmindustrie sich als Vorreiter beim Kampf gegen Raubkopien versteht, noch vor der Software-Branche, weil sie Umsatzeinbußen befürchten. Es geht dabei nicht mal um gewerbliche Raubkopien, sondern um die private Nutzung. Um Stimmung zu machen wird da gerne viel unzusammenhängendes in einen Topf geworfen um abenteuerliche Zusammenhänge zu suggerieren (siehe z.B. hier: news.slashdot.org). Obwohl es erst heute Usus ist, alles zum "matter of national security" zu erheben, wurden sogar schon früher abenteuerliche Rufe laut, das Anfertigen von privaten Raubkopien mit Terrorismus gleich zu setzen. Die Nerven liegen offenbar blank.
Das Thema ist nach wie vor hoch relevant. Dieser Artikel soll ein paar interessante Aspekte hervorheben.
...weiterlesen
Sie haben Fragen oder Anregungen? Treten Sie mit mir in Kontakt! Senden Sie mir eine Nachricht oder nutzen Sie den Rückrufservice! Ich freue mich auf Ihre Nachricht!