Eigentlich schien es zunächst gar keine Geschichte zu sein: Die Schweizer Tech-Journalistin Adrienne Fichter vom Magazin Republik hat gemeinsam mit Kollegen in einer aufwendigen Recherche fast 60 Transparenz-Anfragen an Schweizer Behörden gestellt. „Wir wollten wissen, welche Bundesbehörden die Software von Palantir nutzen“, sagt Fichter im c’t-Podcast „They Talk Tech“ mit Svea Eckert und Eva Wolfangel.

Das Ergebnis: Null. Der Bund arbeitet bislang nicht mit Palantir zusammen. Doch die Anfragen führten zu etwas Erhellenden: einem internen Evaluationsbericht des Schweizer Armeestabs, der Palantirs Software eingehend bewertet. Der kam unter anderem zum Schluss, dass es Probleme mit den Grundrechten geben könnte und entschied sich dagegen.

Das US-Softwareunternehmen Palantir Technologies ist in Europa allgegenwärtig. In Deutschland, Großbritannien und anderen Ländern kooperiert der Datenanalyseanbieter mit Behörden, Armee und Geheimdiensten. Die Frage, ob diese Zusammenarbeit mit demokratischen Grundrechten vereinbar ist, wird selten so klar beantwortet wie in der Schweiz. Und noch seltener zieht eine solche Antwort rechtliche Konsequenzen für diejenigen nach sich, die darüber berichten.

Die Software liefere faszinierende Ergebnisse, sei in der Visualisierung von Bewegungen von Zielpersonen und der Auswertung unstrukturierter Daten europäischen Alternativen überlegen, so der Bericht. Die Fachleute in der Armee sprachen trotzdem eine klare Empfehlung aus: nicht beschaffen. Neben der Grundrechtsproblematik bemängelten sie die mangelnde Kontrollierbarkeit der Software und die Sorge, dass sensible Daten in US-Rechenzentren abfließen könnten. „Wenn wir das nicht selber testen können, können wir das für unproblematische Datenflüsse benutzen, aber nicht für die sensiblen“, fasst Fichter die Haltung der Armee zusammen.

Die Recherche schlug weit über die Schweiz hinaus Wellen. Der Guardian berichtete unter anderem, und im britischen Unterhaus befragten Abgeordnete die Regierung, warum sie die Zusammenarbeit mit Palantir ausbauen wolle, wenn die Schweizer Armee Bedenken angemeldet habe. Auch in Deutschland habe der Bericht zu Fragen geführt, hat Fichter erfahren. „Es hat Palantir in einer empfindlichen Phase getroffen“, sagt Fichter, „weil sie offenbar Mühe haben, in Europa zu expandieren.“ Das Unternehmen kämpfe darum, in Europa als Erfolgsgeschichte dazustehen, und ein Nein der Schweizer Armee passt nicht in dieses Bild.

Insbesondere, da die Republik auch aufdecken konnte, wie sehr Palantir sich bemüht hat: Über sieben Jahre hinweg habe der Konzern immer wieder Kontakt gesucht zu Schweizer Behörden, „die haben eigentlich permanent versucht, irgendwie bei irgendeinem Bundesamt reinzukommen.“

Gerade weil es keine Enthüllungsgeschichte war, sondern eine Geschichte des Versagens, traf es den Konzern. „Dieses Narrativ des Versagens, das wollten sie bekämpfen.“ Palantirs juristische Reaktion kam Ende Dezember 2025, die Klage läuft noch. Eine Anwaltskanzlei forderte eine Gegendarstellung, weitere Schriftsätze folgten. „Unser Anwalt sagt, das ist American Style“, berichtet Fichter: viele absurde Punkte, die den Journalistinnen Zeit raubten für weitere Recherchen. Selbst Fichters LinkedIn-Posts habe die Kanzlei ausgewertet, um zu belegen, dass die Journalistin nicht objektiv sei.

Die inhaltlichen Forderungen seien kaum ernst zu nehmen, sagt sie: Man dürfe nicht das Wort „Verkaufskampagne“ verwenden, einen Firmensprecher nicht als Mediensprecher bezeichnen, Guardian-Artikel nicht als Quelle zitieren. Das Vorgehen habe „Slap-Charakter“, eine strategische Klage, die einschüchtern und von weiterer Arbeit abhalten soll.

Palantir hat sich mit der Klage keinen Gefallen getan. Schließlich wurde der Fakt, dass die Schweiz die Software wegen der Grundrechte und der Intransparenz ablehnt, erst dadurch international diskutiert.

Svea Eckert und Eva Wolfangel besprechen in der aktuellen Folge außerdem den Social-Engineering-Angriff, über den Bundestagspräsidentin Julia Klöckner und weitere Abgeordnete ihre Signal-Accounts verloren haben: wie Angreifer legitime Verifikationscodes abgreifen, um fremde Geräte an bestehende Konten zu koppeln – und warum Signal selbst dabei nicht gehackt wurde.

„They Talk Tech“ erscheint jeden Mittwoch überall, wo es Podcasts gibt. Svea Eckert und Eva Wolfangel diskutieren ein Tech-Thema oder treffen inspirierende Frauen aus und rund um die Tech-Welt.

()

Vollständige technologische oder digitale Souveränität lässt sich nach Einschätzung von Gartner derzeit kaum außerhalb der USA und Chinas erreichen. Ursachen dafür sind die Dominanz der großen Hyperscaler sowie anhaltende Abhängigkeiten bei Infrastruktur, Plattformdiensten und Lieferketten. Darauf wies Gartner-VP-Analyst Douglas Toombs auf der Konferenz „IT Infrastructure, Operations & Cloud Strategies“ in Sydney hin.

Geopolitische Spannungen, regulatorische Unsicherheiten und die starke Marktstellung US-amerikanischer Cloudanbieter haben die Debatte um digitale Souveränität zuletzt weiter angeheizt. Vor allem in Europa suchen Unternehmen und Behörden nach Wegen, ihre Abhängigkeit von US-Hyperscalern zu verringern und Datenhoheit sowie regulatorische Kontrolle abzusichern.

Mehr als nur der Speicherort der Daten

„Derzeit gibt es keine geeigneten nicht-US-amerikanischen Alternativen zu den großen Hyperscalern – außer in China, wo der Schutz geistigen Eigentums Bedenken aufwirft“, erklärte Toombs laut den von Gartner veröffentlichten Konferenz-Highlights. Echte technologische Souveränität sei daher außerhalb dieser beiden Länder zurzeit nicht möglich.

Gartner meint damit nicht nur, wo Daten physisch liegen. Technologische Souveränität umfasse auch die Kontrolle über Cloud-Infrastruktur, Management-Software, Sicherheitsmechanismen, Supportprozesse und die zugrunde liegenden Lieferketten. Selbst lokal betriebene Varianten globaler Cloudplattformen blieben meist technisch und organisatorisch an ihre Anbieter gebunden.

Gleichzeitig beobachtet Gartner eine wachsende Nachfrage nach Kontrolle, Portabilität und digitaler Autonomie. Unternehmen müssten sich gegen Risiken wie regulatorische Änderungen, Sanktionen, Sicherheitsvorfälle oder Ausfälle einzelner Anbieter wappnen. In Europa prägen seit Jahren vor allem mögliche Zugriffe US-amerikanischer Behörden auf Daten europäischer Kunden die Diskussion, etwa über den Cloud-Act oder FISA-Regelungen.

Exit-Strategien als blinder Fleck

Besonders kritisch sieht Gartner die fehlenden Exit-Strategien vieler Cloudkunden. Organisationen müssten klar festlegen, unter welchen Bedingungen sie einen Anbieter verlassen. Wer das versäume, schaffe Folgeprobleme und bringe seine Teams in eine kaum lösbare Lage, warnte Toombs. Nötig seien konkrete Auslöser, feste Budgets und realistische Zeitpläne.

Ein Cloud-Exit beschränkt sich dabei nicht auf den Export von Daten. Vor allem cloudnative Anwendungen, proprietäre Plattformdienste und eng integrierte PaaS-Angebote erschweren einen Wechsel erheblich. Migrationen komplexer Unternehmensanwendungen ziehen sich laut Gartner häufig über mehrere Jahre.

Als Strategien nennt Gartner Sovereign-Cloud-, Hybrid- und Multicloud-Ansätze. Hinzu kommen Konzepte wie „Shelter in Place“, bei dem Unternehmen trotz bekannter Risiken bewusst bei ihrem bisherigen Anbieter bleiben, oder „Hide in Plain Sight“, bei dem sie sensible Daten und Workloads stärker segmentieren oder verschlüsseln.

US-Hyperscaler und europäische Antworten

Die großen US-Anbieter versuchen derweil aktiv, ihre Kunden mit eigenen, als souverän beworbenen Angeboten für Europa zu halten. AWS baut etwa an einer „European Sovereign Cloud“ mit eigenständigen EU-Strukturen und zusätzlichen Compliance-Zusagen. Parallel treiben europäische Anbieter und Behörden eigene Initiativen voran, darunter Projekte von Schwarz Digits sowie Kooperationen mit dem BSI für souveräne Cloud- und Sicherheitslösungen sowie ein gemeinsames Notsystem europäischer Anbieter für den Fall einer Cloudabschaltung.

(fo)

Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind.

Nachdem der erste Teil gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktionen dieser Shared Library aufruft, geht es jetzt um komplexere Szenarien. Er zeigt, wie man aus Java Funktionen mit veränderbaren Parametern aufrufen und Arrays sowie Strukturen übergeben kann.

Funktionen mit veränderbarem Parameter

Die bisherigen Beispiele haben die Aufrufe der nativen Funktionen einfach gehalten. Die Java-Anwendung hat lediglich Parameter durchgereicht und den Rückgabewert übernommen.

Anders sieht es bei den nächsten Beispielen aus. Als erstes folgt die einfache C-Funktion getVersion2, die wie die Funktion getVersion aus Teil 1 die Version der Library ermittelt. Die neue Funktion gibt die Versionsnummer aber nicht als Wert zurück, sondern verändert dazu einen Parameter. Das funktioniert in C, indem eine Anwendung für einen Parameter nicht den Wert selbst, sondern dessen Adresse übergibt (Call by Reference). Dieses Konstrukt sieht in C folgendermaßen aus:

EXPORT void   getVersion2(int* version);

Folgender Java-Code ruft die Funktion auf:

int version;
getVersion2(&version);

Das & kennzeichnet in C, dass die Funktion die Adresse der Variablen nutzt. Java erlaubt das Vorgehen nicht, sodass ein Rückgabewert unerlässlich ist. Folgende Java-Methode verwendet die C-Funktion mit Referenz:

public int getVersion2() throws Throwable
{
  MethodHandle method = getMethodHandle("getVersion2",   
     FunctionDescriptor.of(
				ValueLayout.JAVA_INT, 
				ValueLayout.ADDRESS
				));
  try (Arena arena = Arena.ofConfined())
  {
    MemorySegment versionSeg =   
      arena.allocate(ValueLayout.JAVA_INT.byteSize());
    method.invoke(versionSeg);
    int version = versionSeg.get(ValueLayout.JAVA_INT, 0);
    return version;
  }
}

Zuerst ruft der Code wie im ersten Teil der Serie wieder die Methode getMethodHandle() auf. Der Aufruf definiert den FunctionDescriptor für die Funktion getVersion2().

Die Angabe ValueLayout.ADDRESS für den Parameter zeigt an, dass die C-Funktion eine Adresse erwartet.

Jetzt kommt der spannendere Teil: Um eine Adresse übergeben zu können, muss die Java-Anwendung mittels der FFM-API einen Speicherbereich von vier Byte (für den Datentyp int) reservieren. Das geschieht mit einer Arena, die er erste Teil bereits erläutert hat. Das Erzeugen der Arena mit dem try-with-ressources-Statement stellt sicher, dass die Arena nach dem try-Block automatisch geschlossen und der darin verwaltete Speicher automatisch freigegeben wird. Es gibt verschiedene Typen von Arenas – die im Beispiel über ofConfined erzeugte sorgt dafür, dass die Anwendung nur auf Speicher des aktuellen Thread zugreifen kann. Eine mit ofConfined() erzeugte Arena – beziehungsweise der damit allozierte Speicher – ist daher nicht threadsicher.

Als nächstes gilt es, den erforderlichen Speicherbereich für den Parameter version zu allokieren. Dafür besitzt die Arena die Methode allocate(). Die Größe des benötigten Speichers kann man durch die Funktion byteSize() für die Variable ermitteln. Hier sei nochmals darauf hingewiesen, dass der Wert die Größe des Java-Datentyps darstellt und nicht zwingend etwas über den C-Datentyp aussagt. Da die C-Funktion einen int-Parameter entgegennimmt, sind wir auf der sicheren Seite, da int in C stets vier Byte umfasst. Bei einem long-Wert in C hängt die Größe dagegen von der Plattform ab.

Der Speicherbereich wird durch ein MemorySegment dargestellt, das beim Aufruf der Methode invoke an die C-Funktion weitergereicht werden muss.

Anschließend kann die Anwendung das Ergebnis auslesen. Dazu ruft sie auf dem MemorySegment die Funktion get auf und übergibt ihr das Layout des Speichers (in diesem Fall ein JAVA_INT) und den Offset zum Lesen aus dem MemorySegment. Für das Beispiel ist der Offset null. Durch die Angabe JAVA_INT gibt die Funktion einen int-Wert zurück, den die Anwendung weiterverarbeiten kann.

Funktionen mit einem Array-Parameter

Die nächste Aufgabe baut auf dem Vorgehen auf, verarbeitet aber nicht nur einen Wert, sondern ermittelt den Durchschnitt aus einer Liste von int-Werten. Dazu muss sie der nativen Funktion ein Array von int-Werten übergeben:

public double calcAverage(int [] values) throws Throwable
{
  MethodHandle calcAverage =  
     getMethodHandle("calcAverage"),
	    FunctionDescriptor.of(
	    ValueLayout.JAVA_DOUBLE,     // return value 
	    ValueLayout.ADDRESS,         // data values 
	    ValueLayout.JAVA_INT));      // number of elements

  try(Arena arena = Arena.ofConfined())  
  {
    long totalSize = ValueLayout.JAVA_INT.byteSize() * values.length;
    MemorySegment valueSegment = arena.allocate(totalSize);
    for (int i = 0; i < values.length; i++) 
    {
      valueSegment.setAtIndex(ValueLayout.JAVA_INT, i, values[i]); 
    }
    double result = (double) calcAverage.invoke(valueSegment, 
                                                values.length);
    return result;
  }
}

Zunächst berechnet der Code die gesamte Speichergröße des Arrays (totalSize) und reserviert den benötigten Speicher mit allocate(). Anschließend belegt der Code den Speicher mit der Methode setAtIndex für das jeweilige MemorySegment. Der Aufruf erfolgt für jedes Element des Arrays.

Schließlich ruft der Code die Methode invoke für den MethodHandle auf und übergibt ihr als Parameter das Array und dessen Länge. Schließlich gibt sie das Ergebnis der C-Funktion zurück.