Time and again, Android has been getting the heat for leaving its users in the lurch in the face of security problems, while fixing such problems only in the most recent version. But in my opinion, not only Google, but also the manufacturers, are to blaim for this situation: They are the ones who aim to lock down the devices with their Frankenstein'ed versions of Android because they think it's their selling point, or at least their way to more revenue.

The following suggestions relies purely on speculation, because I am not privy to any contracts, product design or marketing discussions on behalf of any party. But from all I know, the following approach could be used to alleviate the problem from the user's perspective:

Google should imho

1. fix such bugs in as many versions of Android as required to achieve 75% market coverage, and
2. adjust their contracts in a way so that manufacturers who desire early-access and support from Google, as opposed to simply warping AOSP, are required to offer these updates for all handsets that were originally shipped or are currently running with any of the fixed versions of Android, within two weeks time, lest they lose some kind of access to the program, and the right to use the Android logo. Compliance should be determined frequently enough to not water down these requirements.

This would have the following nice side effects:

• Google gets rid of the blame for not supporting their users (see point 1).
• The manufacturers can still avoid the huge and profit-eating work of supplying the users with new versions of Android, but are being pressed to at least not leave their users alone (see point 2).

By going this route, the manufacturers are not required to give up a part of their business relationship to Google, which would be hard to argue despite them doing it all the time towards the carriers (let's think about that battle later), while making sure that the users are safe, sort of (and relegate the general security debate about Android to a different debate, too), without making it impossible to market new devices with new versions of Android.

The current situation, which I'd liken to driving a car with broken brakes, would imho warrant compulsory recall actions on behalf the manufacturers, which they would otherwise be legally obligued to perform - at least as far as my understanding of German consumer protection laws goes. It would be somewhat interesting to see such a case being heard before a German court, and I'm far from confident that the Android brand will not be hurt while the problem festers.

I have the nagging feeling that I cannot be the first to have had these ideas, but wanted to state them nonetheless.

Recently, I have upgraded to Firefox 30 in order to profit from the security fixes. I was delighted with its much improved speed as well, but thoroughly aggravated with a number of very nasty bugs. Contrary to my previous experience, Firefox insisted on playing Flash videos instantly, of course despite me having had click-to-play etc. already enabled.

Anyway, to fix it, go to this, go to about:config and change the setting of

plugin.state.flash from the default value of '2' to '1'.

Save, and you're mostly set.

Unfortunately, I have found a number of situations where the browser insists on playing a video regardless, which I have not yet been able to configure away, although I have all obvious things configured to not auto-play.

Recently, I had the problem of moving my GitLab installation from one URL to another. I guess the problem will hit many people every once in a while. On StackOverflow, someone posted half of the answer.

Make a backup and stop GitLab first! Then:

Quote:

1. In your application.rb file:

   config.relative_url_root = "/gitlab"
   

2. In your gitlab.yml file:

   relative_url_root: /gitlab
   

3. In your unicorn.rb:

   ENV["RAILS_RELATIVE_URL_ROOT"] = "/gitlab"
   

You also need to re-configure your web server appripriately.

Now... that does part of the job, but after doing it, I could not properly reach nor use my GitLab site. The two remaining issues are (a) adjusting the URLs in the database, and (b) updating the assets cache. Here are the remaining bits, assuming that you are on MySQL (adapt for other database engines, accordingly):

mysql> update events set data = replace(data, "http://1.1.1.1/", "http://1.1.1.1/gitlab/");

Next, as the appropriate user, do this:

$ rake gitlab:satellites:create RAILS_ENV=production
$ rake assets:clean RAILS_ENV=production
$ rake assets:precompile RAILS_ENV=production

Then restart GitLab.

If you omit the recompiling of the assets, that will yield you broken icons, or, if you simply deleted them, a lot of 502s, until Rails was able to compile them.

At this point, you have access to your projects using the web, but SSH access does not yet work. You will see "Access denied" message. To fix that, you have to update your gitlab-shell configuration. Then put this in your config.yml:

gitlab_url: "http://1.1.1.1/gitlab"

This URL must reflect the new URL you have chosen. After that, re-install gitlab-shell.

Thanks to <rikurrr> for the idea of directly looking into the database.

Zum Thema Schengen gibt es offensichtlich einige Unklarheiten, was dies technisch und politisch bedeutet. Daher möchte ich auf einige Punkte, die mir bisher nicht klar genug herausgearbeitet zu sein scheinen, eingehen:

Versuch der Monopolbildung bzw. -erhaltung seitens der Deutschen Telekom

Die Behauptung ist, daß dieses Schengenrouting die in vielen Bereichen noch monopolartige Position der Telekom zementieren würde. Ich teile diese Ansicht. Der Mechanismus dazu sieht für mich wie folgt aus:

1. Kleiner Wettbewerber X möchte (muß) Daten ins Telekomnetz schicken, weil er die Geschäftskunden und die Telekom die Verbraucher, die die Webseiten seiner Kunden ansehen wollen, hat.
2. Da die Daten nicht mehr "irgendwo" entlangeroutet werden dürfen, muß der Übergang also neuerdings im Schengenraum liegen.
3. Im Schengenraum hat die Telekom allerdings kartellartige Möglichkeiten, den kostenfreien Datentransport zu unterbinden, und dadurch X dazu zu zwingen, einen solchen Übergang zum Telekomnetz dort zu Freudenhauspreisen zu kaufen. Die Telekom dient hier nur als prominentes Beispiel für die Verweigerungsfront der wenigen Netzanbieter.

Bisher konnte der seine Daten dann notfalls über die USA, Rußland, Japan oder sonstwohin schicken, bis sie irgendwann im Telekom-Netz ankamen, weil die Telekom dort mit anderen ISPs verbunden ist. Diese Möglichkeit soll jetzt per Gesetz unterbunden werden.

Ein Schengen-Netz ermöglicht eine stark vereinfachte Überwachung und Zensur

Die Datenströme würden in einem Schengen-Netz auf deutlich weniger unterschiedlichen Bahnen als bisher fließen und nicht "heimlich" den Schengenraum verlassen dürfen, und wären daher leichter vollständig erfaß- und zusammenführbar. Außerdem bedingt die Konstruktion, daß die Routingentscheidung nun entlang geographischer Grenzen getroffen werden soll, daß man (a) herausfindet, ob die Daten den Schengenraum verlassen dürfen, was (b) eine massive zusätzliche Netzüberwachung und die Etablierung entsprechender Kontrollmöglichkeiten zur Folge hat. Meiner Einschätzung nach läßt sich die bisher geforderte Kontrolle nicht ohne den flächendeckenden Einsatz von DPI realisieren, eine Technik, die in der Vergangenheit bei anderen Anwendern wie eben dem Iran, aber auch Rußland oder China, immer auf das Heftigste kritisiert wurde.

Die teilweise angesprochene Möglichkeit, Datenverkehr mit Zoll zu beaufschlagen, ergibt sich quasi als Nebeneffekt.

Zusammenfassung und Bewertung

Ein solches "Schengen-Routing" hätte zwangsläufig technische Änderungen am Internet zur Folge, die ähnliche Kontrollmechanismen wie etwa im Iran etablieren würden. Diese wecken nach aller bisherigen Erfahrung auch entsprechende Begehrlichkeiten und laden zu Mißbrauch geradezu ein. Unter wirtschaftlichen Aspekten ist aus meiner Sicht offenkundig, daß die genannten kleineren Anbieter dann keine Chance mehr haben, einer Telekom-Zwangsabgabe in erheblicher Höhe - die Preise beginnen hier bei einigen Tausend Euro pro Monat - zu entgehen, was für viele das Aus bedeuten würde. Das Aus würde schon vorher dadurch kommen, daß die besagten Geschäftskunden von vorneherein einen Bogen um die genannten kleinen Anbieter machen würden, weil sie befürchten müßten, daß sie ihre Zielgruppe nicht mehr erreichen.

Wer Wettbewerb will, sollte sich für einen funktionierenden Markt stark machen, und wer stattdessen ein Monopol will, soll das bitteschön ebenfalls klar sagen.

Die Politik sollte es sich sehr gut überlegen, ob sie wirklich dahingehend Gesetze erlassen will, wenn wenigstens einer der Punkte Wettbewerb, Datenschutz oder Vertragsfreiheit mehr als eine reine Worthülse sein soll.

Für generelle weitergehende Informationen zu derartigen Themen empfehle ich ein Besuch beim CCC.

Maybe this has been documented somewhere, but at least, I cannot find it on Google's own support pages. So here goes:

Google Groups have become a major mailing list hub. Unfortunately, Google tries to coerce people into using their web interface, which is something I object to for a number of reasons (it's ok to have it as a fall-back, but not as a primary interface). Now, Google Groups can be subscribed to using standard email, and here is how. As an example, I'll use the GitLab mailing list.

1. Figure out the list address:

   1. The group is at (https://groups.google.com/forum/#!topic/gitlabhq/). In that group, select a random posting, then use the button on the right of the "Sign in to reply" button to open a drop-down menu. Select "Show original".

   2. Locate the "To: " line (maybe another line - see below). For this group, it should read

      To: gitlabhq@googlegroups.com

2. Subscribe to this group:

   1. Use your email program to send an email to this address:

      gitlabhq+subscribe@googlegroups.com

   2. You will get a confirmation email with a token in the subject line. Reply to it.

   3. You "should" get a welcome message, and be done.

I write "should", as sometimes, Google simply drops the email, and there is no way to figure out, why. Therefore, I tend to use email addresses which I already used in conjunction with Google - they work best.

HTH, and hopefully, Google will get their act together, one day.

Immer wieder schicken mir Leute Paßwörter und andere sensible Daten per Email zu, ohne diese Emails zu verschlüsseln - was problemlos möglich wäre, meine PGP-Schlüssel sind öffentlich verfügbar. Das mag manchmal unvermeidlich sein, wenn etwa Systeme automatisch derartige Emails verschicken, ohne auf Verschlüsselung ausgelegt zu sein, aber wenn Menschen über alternative Kommunikationswege verfügen, wäre es schon wünschenswert, wenn sie diese auch zu benutzen - oder eben ihre Emails mit PGP verschlüsseln.

Insbesondere Berufsgeheimnisträgern kann nur dringend empfohlen werden, derartige Maßnahmen zu ergreifen.

Zum Abschluß möchte ich noch kurz auf die amtliche Position zum Thema hinweisen:

BSI-Hinweis zu Paßwörtern

Today, I was once more aggravated when viewing something on github.com, as the avatar icons for the individual users were not being displayed. It turns out that github has reworked their system to display such avatar icons to go to gravatar.com, a popular service for such purposes. The following short essay applies not only to github, which is merely taken as an example, but to other web services as well, and gives ideas about how to produce an alternative design without these problems.

This is, in itself, a bad move, since it turns gravatar into a massive tracking database, much like the ones at doubleclick.net or other advertising agencies, only with an emphasis on techie websites. That this move, and supporting this kind of tracking, was intentional, is also underlined by the fact that the actual icons are not delivered by gravatar, but by github, by redirecting to the following URL:

https://identicons.github.com

So in effect, github does deliver all their icons below, but only makes a "detour" to gravatar to give them the ability to collect tracking data.

Apart from the profile-building property of this arrangement, this idea does also look quite dubious from a usability perspective:

• It involves one more service, thus reducing the availability of the overall service.
• It results in at least two more web requests, even HTTPS, per icon, introducing a noticable delay from the user's perspective, plus additional data transfer.
• By the same token, it involves both more CPU load on the server side, as well as on the user side.

Using Firebug, I determined that the added delay for my notification page roughly varies between 1s for the fastest, and 2.5s for the last few requests, in overall page loading time. I dimly remember that conventional wisdom demands response times well under 1 second for a page to have acceptable performance. Firebug also showed that the individual icon requests were usually being processed in 1 second or under.

Now the questions are: Why would you introduce such delays into your website, especially if it involves added cost for everyone, without user-visible benefits? What are the hidden benefits of such a measure?

Im vorhergehenden Beitrag habe ich ein paar ergänzende Anmerkungen zu einem Spiegel-Artikeln mit einer Einführung in das Thema Email-Verschlüsselung gemacht. Heute möchte ich näher auf Feinheiten eingehen, die die Benutzung von Verschlüsselung für alle Beteiligten "schöner", weil komfortabler, machen. Dazu ist es allerdings erforderlich, die Experten-Einstellungen zu aktivieren. Dies erreichen Sie, indem Sie das Untermenue "OpenPGP->Eigenschaften" öffnen und auf den entsprechenden Knopf unten links drücken. Die folgenden beiden Bilder illustrieren dies:

Zuerst muß man "Preferences" ("Eigenschaften"?) auswählen, woraufhin dieser Dialog erscheint:

Links unten sieht man einen Knopf, mit dem die oben eingekreisten Reiter an- und ausgeschaltet werden können. Dementsprechend sind auch in den nachfolgend erwähnten Menues manche Punkte sichtbar, oder eben nicht. Für unsere Zwecke müssen die erweiterten Einstellungen aktiviert sein.

Nach diesen Vorbereitungen möchte ich anhand einiger Bilder die praktische Benutzung zeigen, um danach ein wenig Theorie ausbreiten.

1. Einfachster Fall: Auswahl beim Senden einer Nachricht

Wenn man vor dem Senden einer Nachricht in dem Fenster, wo man die Nachricht verfaßt, auf das OpenPGP-Menü drückt, erscheint ein kleines Popup-Menü, in dem ich zwei Punkte markiert habe:

Bei Punkt 1 kann man für diese Nachricht auswählen, ob sie im PGP/MIME-Format gesendet werden soll, oder ob sie unstrukturiert sein soll. Der Punkt 2 dient dazu, eine etwaige Regel, die dem entgegensteht, außer Kraft zu setzen. Dabei handelt es sich um eine Vorsichtsmaßnahme im Hinblick auf die Fähigkeiten des Empfängers.

Das müßte man bei jeder Nachricht tun, daher stellen wir das jetzt dauerhaft richtig ein:

2. Verwendung von Regeln:

Wenn man im Hauptfenster von Thunderbird auf den OpenPGP-Knopf drückt, klappt ein Menue mit verschiedenen Einstellmöglichkeiten auf, wo man dann Regeln festlegen kann:

Wenn man den ausgewählten Eintrag anklickt, erscheint folgendes Untermenue (ich habe dort schon einmal auf "Add" geklickt, um eine Regel hinzuzufügen - der entsprechende Dialog liegt vorne links auf dem Fenster mit den Regeln:

Wichtig ist das Fenster vorne links:

Oben kann man Adressen oder Adreßmuster eingeben. Falls man zum Beispiel weiß, daß die Firma XY, mit der man dauernd kommuniziert, Thunderbird oder Mutt einsetzt, dann kann man dort oben als Adresse @XY.com angeben und so die Einstellungen für alle Mitarbeiter dieser Firma auf einmal vornehmen. Man muß dementsperchend natürlich "Adresse endet mit" statt "genaue Übereinstimmung" auswählen.

Danach wählt man beispielsweise aus, welche(n) Schlüssel man verwenden möchte. Wenn der Empfänger beispielsweise einen unternehmensweiten Schlüssel nutzt, der etwa "kontakt@firma.de" heißt, man aber die Nachricht an "buchhaltung@firma.de" schicken will, dann findet GnuPG den Schlüssel nicht, weil es nach "kontakt@firma.de" sucht. In diesem Fenster kann man angeben, daß der richtige Schlüssel der mit der Kennung "kontakt@firma.de" wäre (man muß eine Schlüssel-ID eintragen - bei mir wäre das etwa 0x8A0A48874687AF4F).

Zu guter Letzt kann man einstellen, wie man es mit der Verschlüsselung halten will. Ich habe einmal alle drei Optionen ausgewählt, ohne, daß dies einen praktischen Sinn ergäbe.

Frage 1 bedeutet, ob man seine Nachrichten an diese(n) Empfänger digital signieren will. Digital signierte Nachrichten sind nicht fälschbar - der Empfänger kann genau feststellen, ob die Nachricht manipuliert wurde, und außerdem, wann sie signiert wurde. Im Zusammenhang mit NTP, dem Zeitdienst im Internet, kann man damit schon sehr gut nachweisen, was man wann geschrieben hat.

Bei der Frage 2 geht es darum, ob man die Nachricht verschlüsseln will. Verschlüsselung ist der Mechanismus, der es fremden Leuten sehr schwer (unmöglich?) macht, Ihre Nachricht zu lesen.

Bei der letzten Frage geht es darum, ob PGP/MIME eingesetzt werden soll. Hier kann man für entsprechend ausgestattete Empfänger gerne "Immer" ("Always") auswählen und so sowohl sich als auch dem Empfänger das Leben leichter machen.

Nun zur Theorie:

1. PGP/MIME

Mit OpenPGP verschlüsselte Emails können in zwei Formen auftreten: Einmal können sie wie eine normale Email aussehen, außer, daß der Inhalt für Personen, die nicht im Besitz des richtigen privaten Schlüssels sind, quasi unlesbar sind. Hier ist ein Beispiel aus einer Email, die ich irgendwann erhalten habe:

-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

hQEOA+A4iEELHotAEAP/S3AzliIhaqaTOg75ZGLB12zsdA11RFmpzi11JCS1QUZ
...
Hier stehen viele derartige Zeilen, dann geht die
Email ihrem Ende entgegen:
...
1zMRtSr8Dz7Wekauweykawkjey2i12lzsdeW9M4o3BlOb4zvc7yts1XIN
/2QW9zhc21juBY7QE/Q=
=YsfR
-----END PGP MESSAGE-----

Die Nachricht besteht aus dem Bereich zwischen den Zeilen mit "BEGIN PGP MESSAGE" und "END PGP MESSAGE". Bis hierhin dürfte das nicht überraschen. Als Typ der Email sehen wir:

Content-Type: text/plain; charset=ISO-8859-1

(Sie können derartige Zeilen sehen, wenn Sie sich zu Ihrer Email "alle Kopfzeilen" - die Bezeichnung variiert von Email-Programm zu Email-Programm - anzeigen lassen.)

Das bedeutet, daß der Inhalt der Email nur aus einem Textblock besteht. Doch schon vor vielen Jahren kamen Leute auf die Idee, daß man ja auch beispielsweise Dateien per Email versenden könnte, und haben dazu das MIME-Format ersonnen, das es Ihnen ermöglicht, etwa Bilder oder Kalkulationen per Email zu verschicken. Das geht natürlich auch verschlüsselt, vorausgesetzt, Ihr Kommunikationspartner verwendet ein taugliches Programm (mehr dazu weiter unten). Naheliegenderweise nennt man das Format für verschlüsselte strukturierte Emails denn auch PGP/MIME. Damit hat man dann alle Möglichkeiten normaler Emails, ohne auf Verschlüsselung verzichten zu müssen. Und so sieht dann eine Email im PGP/MIME-Format aus:

Zuerst die "Typenbezeichnung" aus dem Kopf der Email:

Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
    boundary="23yaksdalwse21X3"

Der Inhalt besteht nun aus einem verschlüsselten Block, der die strukturierte Nachricht enthält:

--23yaksdalwse21X3
Content-Type: application/pgp-encrypted
Content-Disposition: attachment

Version: 1

--23yaksdalwse21X3
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="msg.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.12 (GNU/Linux)

hQEOAyl2394e873pe482xajsdasdbKbRoee2CjZh9ajsdzxASDEKLWHelakjewhb
P3VSDAASLKIDUl.xdlka28w[2016PZf/0m1*1lasdh9a8yasdakjehl2e4387UzJ
...
23v23409ew0r8fsdkjfcs/ldkfhlksjyer5li435rlwksehflrikuqRS
=owxY
-----END PGP MESSAGE-----

--23yaksdalwse21X3--

Da derartige MIME-Blöcke beliebig tief geschachtelt sein können, kann man alles in den verschlüsselten Container hineinpacken, was einem beliebt, und so etwa die wertvollen Kalkulationsdaten vor dem ein oder anderen neugierigen Auge verbergen - da es ja auch gar nicht weiß, daß diese in der Email enthalten sind, wenn man sowieso grundsätzlich alles verschlüsselt und so das Rauschen erhöht.

2. Empfänger mit Outlook etc,

Es gibt eine Reihe von Emailprogrammen, allen voran Outlook, Outlook-Express und Lotus Notes, die partout kein PGP/MIME verstehen wollen. Das hat ausschließlich firmenpolitische, aber keine technischen Gründe - viele Email-Programe können seit mehr als 10 Jahren mit PGP/MIME umgehen, das Problem müßte also eigentlich nicht existieren.

Was kann man tun, wenn man mit solchen Leuten zusammenarbeiten muß:

• Erstellen Sie ggfs. eine Regel (siehe oben), daß Sie diesen Leuten keine Emails in "flacher" Form zusenden. Um die sichere Übertragung von Dateien müssen Sie sich dann von Hand kümmern - etwa, indem Sie die Dateien von Hand auf der einen Seite ver- und auf der anderen Seite entschlüsseln. Das ist umständlich und fehlerbehaftet, aber besser als nichts.

• Wirken Sie auf diese Leute ein, sich einmal mit dem alternativen oder zusätzlichen Einsatz von PGP/MIME-tauglichen Programmen, oder wenigstens auf die Entwicklung entsprechender Plugins, soweit möglich, hinwirken.

Der Spiegel hat einen Artikel dazu veröffentlicht, wie einfach man Verschlüsselung bei Emails verwenden kann, und worauf man achten sollte. Zitat: "[ ... ] Es erfordert aber ein wenig Aufwand, seine E-Mails zu verschlüsseln. Doch danach mailt es sich chiffriert fast so einfach wie sonst. Die Schritt-für-Schritt-Anleitung."

Dazu habe ich einige Anmerkungen:

Benutzer von Debian oder (wahrscheinlich) Ubuntu können einfach folgendermaßen vorgehen:

$ sudo apt-get install enigmail

Falls enigmail nicht zum Lieferumfang gehören sollte (Ubuntu?), wäre dies die Alternative:

$ sudo apt-get install icedove

Danach installiert man per Add-On-Manager enigmail, wie in der Anleitung beschrieben, und falls noch erforderlich.

Die in dem Artikel gezeigten Folien 10 und 11 betreffen nur den Fall, wenn man zum ersten Mal einen Schlüssel für einen Kommunikationspartner benötigt. Außerdem kann man enigmail so konfigurieren, daß es automatisch nach den Schlüsseln sucht. Vor allem, wenn man seinen eigenen Schlüssel auf einen Keyserver hochgeladen hat, finden andere Leute den Schlüssel ebenfalls "automatisch", und man braucht den Schlüssel nicht direkt per Email zu versenden. Der Nachteil ist natürlich, daß der Schlüssel damit einfacher der Kommunikationsanalyse zugänglich wird, aber bei dem derzeitigen Stand der Überwachung dürfte es meiner Einschätzung nach ein Irrtum sein, zu glauben, daß dies sonst nicht der Fall wäre - erst recht nicht für Leute, die nicht nur per verschlüsselter Email, sondern auch noch etwa per sozialem Netzwerk, miteinander kommunizieren.

Auf der Folie 9 sieht man die Option "PGP/MIME verwenden". Falls irgend möglich, sollte man dies einschalten, etwa in den Standardeinstellungen. Damit kann man dann auch Emails mit Anhängen sauber verschlüsseln. In den Einstellungen kann man das auswählen, und dann kann man das Format auch noch im Adreßbuch pro Eintrag auswählen, so daß ein Korrespondent, dessen Emailprogramm kein PGP/MIME kann (vor allem Outlook und Notes tun sich hier seit mehr als 10 Jahren negativ hervor), wenigstens einfache verschlüsselte Emails empfangen kann.

Man sollte allerdings in seiner Signatur einen Eintrag haben, der auf die Existenz und die Eigenschaften des Schlüssels hinweist, und möglichst oft zu einer "Key-Signing-Party" gehen, um das "Web-of-Trust" mit aufzubauen, das man braucht, um sich tatsächlich von der Identität des Kommunikationspartners zu überzeugen.

Hier ist der Originalartikel beim Spiegel:

Schutz gegen Internet-Spione: So verschlüsseln Sie Ihre E-Mails

Neben dem allgemeinen Unbehagen gegen die Überwachung gibt es natürlich auch handfeste Gründe, sich dem möglichst zu entziehen. Die ZEIT beispielsweise schreibt von einem wirtschaftlichen Schaden in Höhe von 4,2 Milliarden Euro jährlich, der durch Spionage entsteht. Da kann ja jeder einmal in sich gehen, um seinen eigenen Anteil an diesem Betrag zu ermitteln. Der Artikel beschönigt die Sachlage zwar aus meiner Sicht noch. denn daß Wirtschaftsspionage zum offiziellen Auftrag der NSA gehört, weiß eigentlich seit Jahren wirklich jeder, der sich für das Thema interessiert, aber immerhin wird das Thema an sich aufgegriffen.

Hier ist der Link zu dem genannten ZEIT-Artikel:

Vorsprung durch Spionage