Anna’s Archive bleibt sichtbar: Googles Löschungen zeigen kaum Wirkung


Kommentare zu folgendem Beitrag: Anna’s Archive bleibt sichtbar: Googles Löschungen zeigen kaum Wirkung

Google hat 749 Millionen Links zu Anna’s Archive entfernt, 5 % aller DMCA-Löschanträge überhaupt. Doch Anna’s Archive bleibt sichtbar.

PiLiM PiLiM
Eine Flasche Bücher bitte.

Warum sollte AA auch unsichtbar werden? Es werden schließlich auch keine Inhaltsdaten entfernt, sondern lediglich „Pfadangaben“.
Momentan „verwaltet“ AA knapp 1050 TB Daten, die aufgeteilt sind in:

  • direct data
  • scraped data
  • collabed data
  • mirrored data

Obwohl die interne Infrastruktur um einiges komplizierter ist, könnte man AA ähnlich sehen, wie eine riesige Tracker-Announce. Nur das diese Announce zigfach redundant gespiegelt vorliegt. Das diese Link-Löschaktionen nur pure Symptombekämpfungen sind, die längere Zeit zur Durchführung benötigen, als sie wirklich wirksam sind, ist für solche Strukturen doch längst bekannt! Sich hinterher darüber zu echauffieren, dass sie nicht wirksam sind, kann man als die hohe Kunst des Theaterspielens bewerten. Das sich mit diesen Maßnahmen wieder nur wenige Akteure die eigenen Taschen füllen, sollte mittlerweile sogar bei den Auftraggebern angekommen sein…

In einer Suchmaschine unsichtbar machen, das war schon das Ziel der Aktion.

Ja, eben.
PirateBay hostet ja auch nichts selber, nur ist das für die Rechteinhaber (ich will sie mal so nennen) gehupft wie gesprungen.

Nun ja, ist ja auch nachvollziehbar, sie speichern die Datei, die einen Download der urheberrechtlich geschützten Werke ermöglicht. Also die Torrent-Datei oder den Magnet-Link.

Ich glaube, hier wurde etwas mißverstanden! Mit AA als „Tracker-Announce“ meinte ich nicht die Ausspielung der Enduser-Dateien (inkl. deren Verlinkungen), sondern die Verteilung / Spiegelung der internen Infrastruktur (z.B. Metadaten / DBs etc.).
Daraus ergeben sich folgliche Umstände und Fakten über das interne System:

AAs Standardisierung von Veröffentlichungen

Dies wurde auf drei Arten erreicht:

  • Spiegelung bestehender Open-Data-Schattenbibliotheken (wie Sci-Hub und Library Genesis).
  • Unterstützung von Schattenbibliotheken, die offener sein möchten, aber nicht die Zeit oder Ressourcen dazu hatten (wie die Libgen-Comics-Sammlung).
  • Scraping von Bibliotheken, die nicht in großen Mengen teilen möchten (wie Z-Library).

Für (2) und (3) verwaltet AA nun selbst eine beträchtliche Sammlung von Torrents (Hunderte von TBs). Bisher wurden diese Sammlungen als Einzelstücke behandelt, was bedeutet, dass für jede Sammlung eine maßgeschneiderte Infrastruktur und Datenorganisation erforderlich war. Dies führte zu einem erheblichen Mehraufwand bei jeder Veröffentlichung und erschwerte insbesondere inkrementelle Veröffentlichungen.

Deswegen wurde ab Sommer 2023 ein standardisiertes Format eingeführt, der AAC (Annas Archiv Container):

Designziele

Der primäre Anwendungsfall ist die Verteilung von Dateien und zugehörigen Metadaten aus verschiedenen bestehenden Sammlungen. Die wichtigsten Planungen und Umsetzungen dazu sind:

  • Heterogene Dateien und Metadaten, so nah wie möglich am Originalformat.
  • Heterogene Identifikatoren in den Quellbibliotheken oder sogar das Fehlen von Identifikatoren.
  • Separate Veröffentlichungen von Metadaten vs. Dateidaten oder nur Metadaten-Veröffentlichungen (z. B. AAs ISBNdb-Veröffentlichung).
  • Verteilung über Torrents, jedoch mit der Möglichkeit anderer Verteilungsmethoden (z. B. IPFS).
  • Unveränderliche Aufzeichnungen, da das Team davon ausgehen sollte, dass diese Torrents für immer bestehen bleiben.
  • Inkrementelle Veröffentlichungen / anhängbare Veröffentlichungen.
  • Maschinenlesbar und -schreibbar, bequem und schnell, insbesondere für den eigenen Stack (Python, MySQL, ElasticSearch, Transmission, Debian, ext4).
  • Einigermaßen einfache menschliche Inspektion, obwohl dies sekundär zur Maschinenlesbarkeit ist.
  • Einfachheit im Gesamten, genannte Sammlungen mit einer standardmäßig gemieteten Seedbox zu seeden.
  • Binärdaten können / müssen direkt von Webservern wie Nginx bereitgestellt werden können.

Einige Nicht-Ziele:

  • Es ist egal, ob Dateien manuell auf der Festplatte leicht zu navigieren sind oder ohne Vorverarbeitung durchsuchbar sind.
  • Es ist egal, ob sie direkt mit bestehender Bibliothekssoftware kompatibel sind.
  • Obwohl es einfach sein sollte, die Sammlungen mit Torrents zu seeden, erwarten AA nicht, dass die Dateien ohne erhebliches technisches Wissen und Engagement nutzbar sind.

Der Standard

Letztendlich hat man sich auf einen relativ einfachen Standard geeinigt. Er ist ziemlich locker, nicht normativ und ein fortlaufendes Projekt…

  • AAC. AAC (Anna’s Archiv Container) ist ein einzelnes Element, das aus Metadaten und optional Binärdaten besteht, die beide unveränderlich sind. Es hat einen weltweit eindeutigen Bezeichner, genannt AACID.
  • Sammlung. Jedes AAC gehört zu einer Sammlung, die per Definition eine Liste von AACs ist, die semantisch konsistent sind. Das bedeutet, dass wenn Sie eine wesentliche Änderung am Format der Metadaten vornehmen, Sie eine neue Sammlung erstellen müssen.
  • „Datensätze“ und „Dateien“ Sammlungen. Üblicherweise ist es oft praktisch, „Datensätze“ und „Dateien“ als verschiedene Sammlungen zu veröffentlichen, damit sie zu unterschiedlichen Zeitplänen veröffentlicht werden können, z. B. basierend auf Scraping-Raten. Ein „Datensatz“ ist eine Sammlung, die nur Metadaten enthält, wie Buchtitel, Autoren, ISBNs usw., während „Dateien“ die Sammlungen sind, die die eigentlichen Dateien selbst enthalten (pdf, epub).
  • AACID. Das Format von AACID ist folgendes: aacid__{collection}__{ISO 8601 timestamp}__{collection-specific ID}__{shortuuid}. Zum Beispiel ist ein tatsächlicher AACID, den wir veröffentlicht haben, aacid__zlib3_records__20230808T014342Z__22433983__URsJNGy5CjokTsNT6hUmmj.
    • {collection}: der Sammlungsname, der ASCII-Buchstaben, Zahlen und Unterstriche enthalten kann (aber keine doppelten Unterstriche).
    • {ISO 8601 timestamp}: eine kurze Version des ISO 8601, immer in UTC, z. B. 20220723T194746Z. Diese Zahl muss für jede Veröffentlichung monoton ansteigen, obwohl ihre genauen Semantiken je nach Sammlung unterschiedlich sein können. Wir empfehlen, die Zeit des Scrapings oder der ID-Erstellung zu verwenden.
    • {collection-specific ID}: ein sammlungsspezifischer Bezeichner, falls zutreffend, z. B. die Z-Library ID. Kann weggelassen oder gekürzt werden. Muss weggelassen oder gekürzt werden, wenn der AACID sonst 150 Zeichen überschreiten würde.
    • {shortuuid}: eine UUID, aber komprimiert zu ASCII, z. B. mit base57. Wir verwenden derzeit die shortuuid Python-Bibliothek.
  • AACID-Bereich. Da AACIDs monoton ansteigende Zeitstempel enthalten, können wir diese verwenden, um Bereiche innerhalb einer bestimmten Sammlung zu kennzeichnen. Wir verwenden dieses Format: aacid__{collection}__{from_timestamp}--{to_timestamp}, wobei die Zeitstempel inklusive sind. Dies ist konsistent mit der ISO 8601-Notation. Bereiche sind kontinuierlich und können sich überlappen, müssen im Falle einer Überlappung jedoch identische Datensätze wie die zuvor in dieser Sammlung veröffentlichten enthalten (da AACs unveränderlich sind). Fehlende Datensätze sind nicht erlaubt.
  • Metadatendatei. Eine Metadatendatei enthält die Metadaten eines Bereichs von AACs für eine bestimmte Sammlung. Diese haben die folgenden Eigenschaften:
    • Der Dateiname muss ein AACID-Bereich sein, der mit annas_archive_meta__ beginnt und mit .jsonl.zstd endet. Zum Beispiel heißt eine unserer Veröffentlichungen
      annas_archive_meta__aacid__zlib3_records__20230808T014342Z--20230808T023702Z.jsonl.zst.
    • Wie durch die Dateierweiterung angegeben, ist der Dateityp JSON Lines, komprimiert mit Zstandard.
    • Jedes JSON-Objekt muss die folgenden Felder auf der obersten Ebene enthalten: aacid, metadata, data_folder (optional). Keine anderen Felder sind erlaubt.
    • metadata sind beliebige Metadaten, gemäß den Semantiken der Sammlung. Sie müssen innerhalb der Sammlung semantisch konsistent sein.
    • data_folder ist optional und ist der Name des Binärdatenordners, der die entsprechenden Binärdaten enthält. Der Dateiname der entsprechenden Binärdaten innerhalb dieses Ordners ist der AACID des Datensatzes.
    • Das annas_archive_meta__ Präfix kann an den Namen Ihrer Institution angepasst werden, z. B. my_institute_meta__.
  • Binärdatenordner. Ein Ordner mit den Binärdaten eines Bereichs von AACs für eine bestimmte Sammlung. Diese haben die folgenden Eigenschaften:
    • Der Verzeichnisname muss ein AACID-Bereich sein, der mit annas_archive_data__ beginnt und keinen Suffix hat. Zum Beispiel hat eine unserer tatsächlichen Veröffentlichungen ein Verzeichnis namens
      annas_archive_data__aacid__zlib3_files__20230808T055130Z--20230808T055131Z.
    • Das Verzeichnis muss Datendateien für alle AACs innerhalb des angegebenen Bereichs enthalten. Jede Datendatei muss ihren AACID als Dateinamen haben (keine Erweiterungen).
    • Es wird empfohlen, diese Ordner in einer einigermaßen handhabbaren Größe zu halten, z. B. nicht größer als 100GB-1TB pro Ordner, obwohl sich diese Empfehlung im Laufe der Zeit ändern kann.

Man kann die Russen mögen oder nicht - die am wenigsten zensierte Suchmaschine in unserem „Verkehrsraum“, ist Yandex. Für normale Suchen ohne viel Spam die von Brave und danach erst alle anderen.
Sorry, aber Google für halblegale Dinge zu verwenden, ist heute - gelinde gesagt - irrwitzig.

Ich wundere mich schon länger, wann die Russen da mal selber reingrätschen.
Klar, Yandex dient vor allem dazu, dem Wertewesten den Spiegel vorzuhalten. Aber die Seite muss denen doch selber auch ein Dorn im Auge sein?

Russland hat einfach wenig bis kein Interesse an der Zensur der Suchergebnisse. Sofern es wirklich von russischer Seite her illegal sein sollte, verschwindet das auch aus dem Index. Du wirst dort auch keine öffentlichen Seiten von unterster Schublade der Pornografie im Index finden, da selbst das in Russland zum Glück illegal ist. Aber sonst sind sie sehr entspannt, was in den Suchmaschinen verlinkt wird. Da wird eher am eigenen Netz zensiert und verändert, als dass man sich überhaupt die Mühe macht, wichtige Geldbringer des Landes unnötigerweise zu bemühen.

Yandex ist eine Gesellschaft mit begrenzter Haftung, welche eine 100%ige Tochtergesellschaft der niederländischen Yandex N.V. ist. Das Russlandgeschäft von Yandex wurde 2024 an ein Konsortium russischer Investoren verkauft, zu denen das bisherige Management und ein Fonds des Ölkonzerns Lukoil gehören. Das niederländische Unternehmen Yandex NV ist der ursprüngliche Eigentümer, der sich aufgrund von Sanktionen vom russischen Geschäft trennen musste. Die verbleibenden, internationalen Geschäfte sowie die Technologie verbleiben bei der niederländischen Muttergesellschaft.
So denn…bitte wieder: