Auf dieser Seite
- Ist Google Antigravity sicher?
- Was blockt die Sandbox von Antigravity tatsächlich?
- Warum wird die Sandbox unter Windows nicht unterstützt?
- Wie funktionieren die Berechtigungen von Antigravity wirklich?
- Was erlaubt „allow all commands" tatsächlich?
- Sind Antigravity-Skills sicher?
- Und die MCP-Server und Hooks?
- Sorgt eine GEMINI.md dafür, dass der Agent Ihre Regeln befolgt?
- Trainiert Google mit dem Code, den Sie in Antigravity schreiben?
- Der Zehn-Minuten-Durchgang, der Reihe nach
- Was wir verkaufen, klar gesagt
- Häufige Fragen
- Ist Google Antigravity sicher?
- Darf man Antigravity auf Unternehmenscode einsetzen?
- Hat Antigravity einen Sandbox-Modus?
- Warum wird Sandboxing unter Windows nicht unterstützt?
- Wie umgeht man die Berechtigungen in Antigravity, und sollte man das?
- Kann Antigravity Terminalbefehle ohne Rückfrage ausführen?
- Kann man einen Antigravity-Skill von GitHub gefahrlos installieren?
- Kann ein MCP-Server in Antigravity Werkzeuge ohne Freigabe ausführen?
- Wie erzwingt man eine Regel in Antigravity?
- Garantiert eine GEMINI.md, dass der Agent meine Regeln befolgt?

Die Voreinstellungen von Antigravity sind besser als die der meisten agentischen IDEs, nur schützen sie die Maschine und nicht das Produkt. Auf macOS und Linux laufen die Shell-Befehle des Agenten in einer ab Werk aktiven Sandbox, die weder ~/.ssh noch .env sieht und keine Domain erreicht, die Sie nicht freigegeben haben. Unter Windows ist es zum 16. September 2026 noch nicht so weit, und Google sagt es selbst: das neue Berechtigungssystem sei derzeit auf macOS und Linux verfügbar, Windows werde in einer künftigen Version auf das vereinheitlichte System umgestellt. Bleibt das, was für jede Plattform gilt, und daran sollte sich Ihre Lektüre ausrichten: die Sandbox hält zurück, was der Agent ausführt, sie sagt nichts über das, was er schreibt, und geschrieben wird genau das, was am Ende bei Ihren Nutzern ankommt.
Ist Google Antigravity sicher?
Sicher gegen den Ausfall, den sich alle vorstellen, und unbestimmt gegen den, der tatsächlich Geld kostet: unter dem Wort stecken drei verschiedene Fragen, und Antigravity beantwortet sie sehr unterschiedlich.
Kann es Ihren Rechner zerlegen oder mit Ihren Schlüsseln verschwinden? Auf macOS und Linux weitgehend nicht, per Konstruktion, ohne dass Sie etwas einstellen müssten. Kann es etwas ausführen, das Sie nicht vorgesehen hatten? Nur wenn Sie selbst die Regeln aufweiten, und genau danach wird gesucht. Kann es eine Schwachstelle in Ihr Produkt schreiben, sie committen und die Tests grün sehen? Ja. Und darauf zielt im Produkt nichts ab.
Beginnen wir bei der Beschreibung des Herstellers: antigravity.google spricht von einer agentischen Entwicklungsplattform, deren Agenten Shell-Befehle direkt ausführen. Die Risikofläche benennt also der Anbieter selbst, und alles Weitere in der Dokumentation ist ein redlicher Versuch, sie einzuzäunen.
Was blockt die Sandbox von Antigravity tatsächlich?
Vier Grenzen, und gehalten werden sie vom Betriebssystem, nicht vom guten Willen des Modells.
Linux: Kernel-Namespaces
Die Dokumentation wird konkret: Kernel-Namespaces „isolieren das Dateisystem, verbergen die Prozesse des Hosts und kappen das Netzwerk". Es ist dieselbe Primitive, auf der Container aufsetzen. Ein Befehl, der dem Urteil des Agenten entwischt, landet deshalb trotzdem in einer Box, die der Kernel gezogen hat.
macOS: Seatbelt-Profile
Unter macOS „schränken Seatbelt-Profile (SBPL) den Dateisystemzugriff und Socket-Verbindungen ein". Seatbelt ist Apples eigene Sandbox-Sprache, dieselbe, die Programme aus dem App Store einsperrt, und Codex stützt sich auf denselben Mechanismus.
Zugangsdaten sind unsichtbar, nicht nur verboten
„Sensible Dateien wie ~/.ssh und .env sind blockiert, alles, was nicht ausdrücklich eingehängt ist, ist in der Sandbox unsichtbar." Der Unterschied trägt: ein abgelehnter Lesezugriff lässt sich anders erneut versuchen. Ein Pfad, der nie eingehängt wurde, existiert dagegen nicht, also gibt es nichts zu versuchen.
Netzwerk nur auf Freigabeliste
In der Sandbox ist „der Netzwerkzugriff auf die von Ihnen freigegebenen Domains begrenzt". Weil fast jeder Exfiltrationsweg das Netz braucht, um hinauszukommen, ist das die Voreinstellung, die im ganzen Produkt am meisten trägt.
Das Standard-Preset fügt die vier Dinge zusammen. Terminalbefehle laufen in der isolierten Terminal Sandbox, mit Zugriff nur auf den Workspace und die temporären Verzeichnisse und ohne Netzwerk, und „Befehle können in der Sandbox ohne manuelle Freigabe laufen".
Lesen Sie den letzten Satz als den Handel, der er ist. Das Freigabefenster, jenes, das jede Entwicklerin beim vierzigsten Mal blind wegklickt, verschwindet, weil es für die Klasse von Befehlen überflüssig wird, die nur ein Wegwerfverzeichnis beschädigen kann. Der Handel bleibt besser als ein Agent, der nach allem fragt und Ihnen beibringt, ja zu sagen.
Warum wird die Sandbox unter Windows nicht unterstützt?
Weil die Windows-Version noch auf dem älteren Berechtigungssystem läuft. Die Sandbox-Seite schreibt es unmissverständlich: das aktualisierte Berechtigungssystem sei „derzeit auf macOS und Linux verfügbar, wo die Sandbox standardmäßig aktiviert ist". Sandbox- und Berechtigungsseite tragen denselben Hinweis, Windows werde „in einer künftigen Version auf das vereinheitlichte Berechtigungssystem umgestellt".
Für ein Team ist das keine Fußnote. Die beiden Plattformen zeigen unterschiedliche Schalter unter unterschiedlichen Namen: eine auf einem Mac geschriebene Richtlinie überträgt sich nicht auf ein Windows-Notebook, auch nicht sorgfältig abgeschrieben.
Man kann diese Tabelle so lesen, als wäre Windows strenger, und das stimmt zur Hälfte: für jeden nicht deklarierten Befehl nachzufragen ist eine echte Kontrolle. Die falsche Hälfte kommt, wenn die Antwort ja lautet. Auf macOS läuft eine zu schnell erteilte Freigabe in einer Box ohne Netz und ohne Sicht auf ~/.ssh. Unter Windows läuft sie heute auf Ihrer Maschine.
Wie funktionieren die Berechtigungen von Antigravity wirklich?
Drei Verben und eine Vergleichslogik. Regeln sind Deny, Ask oder Allow, „widersprüchliche Regeln werden strikt in der Reihenfolge Deny > Ask > Allow ausgewertet", und so überlebt ein Deny vom letzten Quartal das Allow, das Sie heute in Eile hinzufügen.
Üblicherweise brechen Whitelists an der Vergleichslogik. Diese ist besser als der Durchschnitt: eine Regel command(git) vergleicht standardmäßig wörtlich, über ein exaktes Wort- oder Token-Präfix, regex: übernimmt, wenn ein Muster nötig ist, und command(*), wenn man beschlossen hat, nicht weiterzulesen. Und dann folgt die Passage, die die meisten Texte über dieses Produkt verkehrt herum wiedergeben.
Den klassischen Umgehungsweg benennt die Dokumentation selbst: bestimmte Shell-Konstrukte könnten „die Ausführung beliebiger Befehle hinter einem ansonsten harmlosen Präfix verstecken", genannt werden Befehls- und Prozesssubstitution, $(...), Backticks, <(...). Ihre Antwort ist, enger zu werden statt weiter: erkennt Antigravity eines davon oder kann den Befehl nicht sauber parsen, „deaktiviert es den Präfixvergleich für die gesamte Befehlszeile: der Befehl läuft nur dann ohne Rückfrage, wenn eine Regel die vollständige Zeile Zeichen für Zeichen trifft".
Was erlaubt „allow all commands" tatsächlich?
Alles, was eine Shell ausdrücken kann: innerhalb der Sandbox auf macOS und Linux, auf Ihrem Host unter Windows. Das ist die ehrliche Antwort auf die meistgesuchte Frage zu diesem Produkt, und der Abstand zwischen diesen beiden Hälften ist das einzig Interessante an ihr.
Das gehört offen gesagt, weil wir selbst ein Produkt dieser Kategorie verkaufen: auch unsere eigene Befehlsprüfung vergleicht wörtlichen Text. Jede Whitelist, die auf Zeichenkettenvergleich beruht, unsere eingeschlossen, sagt etwas über die Zeichen eines Befehls und nichts über seine Wirkung. In unserer kontrollierten Studie haben diese Prüfungen über dreißig Tickets hinweg dreizehn Fehlalarme erzeugt; wir haben die Zahl veröffentlicht, statt sie wegzurunden. Zeichenkettenvergleich bleibt das richtige Werkzeug für eine grobe Grenze, und das falsche für eine Entscheidung, an der das Unternehmen hängt.
Daher die Rangfolge. Die Sandbox ist eine Kontrolle, weil der Kernel sie durchsetzt; die Regelliste ist bloß ein Komfort, der darüber entscheidet, wie oft Sie unterbrochen werden. Das Erste abzuschalten, damit das Zweite Ruhe gibt, heißt eine Kontrolle gegen einen Komfort tauschen.
Sind Antigravity-Skills sicher?
Niemand hat es gesagt, und das ist der Befund. „Antigravity skills" ist das Erste, was Googles Autovervollständigung nach dem Produktnamen anbietet, auf Deutsch ebenso wie auf Französisch, Spanisch, Italienisch und Portugiesisch, meist gefolgt von „antigravity skills github". Die Leute laden sie bereits herunter. Und die Skills-Dokumentation verliert kein Wort darüber, wie man einen fremden Skill prüft, bewertet oder ihm vertraut.
So sieht ein Skill laut derselben Seite aus: ein Ordner, unter <workspace-root>/.agents/skills/<skill-folder>/ für einen Workspace oder unter ~/.gemini/config/skills/<skill-folder>/ für alle, der eine SKILL.md verlangt und Unterordner scripts/, examples/ und resources/ mitbringen kann. Sie müssen dem Agenten „nicht ausdrücklich sagen, dass er einen Skill verwenden soll". Er „entscheidet anhand des Kontexts".
Fassen Sie diese drei Fakten zusammen, und Sie haben eine Supply Chain: ein Ordner, über einen Pull Request hereingekommen, mit Anweisungen und gegebenenfalls ausführbaren Skripten, den der Agent liest und anwendet, ohne dass jemand ihn darum bittet.
Die Sandbox hilft hier weniger, als man annimmt, und der Grund gehört präzise gesagt. Sie hält die Befehle zurück, die ein Skill ausführt; sie hält nicht die Anweisungen zurück, die ein Skill gibt. Eine SKILL.md, die den Agenten leise in Richtung einer freizügigen CORS-Richtlinie, einer vergessenen Eigentümerprüfung oder einer Logzeile mit dem Token schiebt, ergibt ein sauberes Diff, eine grüne Testsuite und einen Lauf, der ebenso erfolgreich wie vollständig isoliert war. Diesen Mechanismus haben wir zweimal beschrieben, bei Instruction File Injection über AGENTS.md und CLAUDE.md und bei Tool Poisoning über MCP, demselben Angriff, ausgeliefert über eine Werkzeugbeschreibung.
Und die MCP-Server und Hooks?
Beide werden im selben Verzeichnis .agents konfiguriert, und beide kommen mit einer vernünftigen Voreinstellung.
MCP-Server werden in ~/.gemini/config/mcp_config.json oder .agents/mcp_config.json deklariert, und „standardmäßig laufen nicht konfigurierte MCP-Werkzeuge im Ask-Modus und erfordern vor der Ausführung Ihre Freigabe". Das ist die richtige Voreinstellung. Der Vorbehalt ist derselbe wie bei Skills: die Freigabe betrifft den Aufruf, die Vergiftung sitzt in der Beschreibung, und die hat das Modell längst gelesen, wenn Sie überhaupt gefragt werden.
Für ein Sicherheitsteam sind Hooks die interessantere Hälfte. Sie liegen in einer hooks.json unter ~/.gemini/config/ oder .agents/ und „erlauben es, eigene Skripte oder Shell-Befehle an bestimmten Punkten der Ausführungsschleife von Antigravity laufen zu lassen": PreToolUse, PostToolUse, PreInvocation, PostInvocation und Stop. Ein PreToolUse-Hook kann "decision": "ask" zurückgeben, was „den Nutzer fragt, aber Always-Allow-Einstellungen respektiert", oder "force_ask", was „immer den Nutzer fragt und zwischengespeicherte Berechtigungen ignoriert".
Dieser zweite Wert ist das Einzige im Produkt, das ein müder Klick von vor drei Wochen nicht stillschweigend vorab genehmigen kann. Die eine Regel, die Sie wirklich nicht verlieren dürfen, gehört deshalb hinter force_ask und nirgendwo sonst.
Sorgt eine GEMINI.md dafür, dass der Agent Ihre Regeln befolgt?
Nicht so, wie es die bloße Existenz der Datei nahelegt. Globale Regeln liegen in ~/.gemini/GEMINI.md, Workspace-Regeln im Ordner .agents/rules, und „Regeldateien sind auf jeweils 12.000 Zeichen begrenzt". Was in dieser Dokumentation an keiner Stelle auftaucht, ist die Behauptung, der Agent werde sich daran halten, und diese Zurückhaltung ist verdient.
Wir haben die entsprechende Datei bei einem anderen Agenten gemessen und das Ergebnis veröffentlicht. Neunzig autonome Läufe, dreißig Entwicklertickets, eine Codebasis, ein Modell, und eine einzige manipulierte Variable: der Kanal, über den der Agent die 49 Geschäfts- und Compliance-Regeln der Plattform erfahren konnte. Ein realistisch von Hand geschriebener Regelabschnitt setzte genau 7 von 55 Regeldetails exakt um. Ganz ohne Regeldatei: ebenfalls 7 von 55, dasselbe Ergebnis. Methode und Fehlschläge stehen in Hält sich Claude Code an die CLAUDE.md, und der Mechanismus hat nichts Anthropic-Spezifisches, denn ein Dokument, das einmal zu Sitzungsbeginn gelesen wird, ist zum Zeitpunkt der Änderung dreißigtausend Token entfernt.
GEMINI.md ist Dokumentation. Eine Deny-Regel und ein force_ask-Hook sind Kontrollen. Legen Sie nicht in der ersten ab, was Sie in den zweiten gebraucht hätten.
Trainiert Google mit dem Code, den Sie in Antigravity schreiben?
Was erhoben wird, benennt die Einstellungsseite: Antigravity erfasse Interaktionen, „um Antigravity und die Modelle, die Antigravity zugrunde liegen, zu evaluieren, zu entwickeln und zu verbessern". Die FAQ ergänzt, man könne „der Datenerhebung jederzeit im Bereich Settings widersprechen", und verweist für alles Weitere auf die Nutzungsbedingungen.
Die Enterprise-Haltung unterscheidet sich deutlich, und man kennt sie besser, bevor eine Sicherheitsprüfung danach fragt. Google schreibt, „Prompts, Antworten, Code und Telemetrie von Enterprise-Kunden werden niemals außerhalb Ihrer privaten Umgebungen gespeichert". Und ebenso, „Ihre Kundentelemetrie und Ihre Modellinteraktionen werden direkt in dem Google-Cloud-Projekt protokolliert, das zu der von Ihnen gewählten Lizenz gehört", mit den Regionen global, us und eu und verfügbaren VPC Service Controls.
Erhebung standardmäßig im regulären Produkt, mit Schalter in Settings
wohin Telemetrie und Modellinteraktionen mit Enterprise-Lizenz gehen
Aufbewahrungsdauer, in sämtlichen von uns gelesenen Dokuseiten
Wir leiten keine Aufbewahrungsdauer aus einer Dokumentation ab, die keine nennt, und ein Lieferantenfragebogen sollte sich daran ebenso wenig versuchen. Wenn die Antwort für Ihre Prüfer zählt, steht sie in den Nutzungsbedingungen und in Ihrem Google-Vertrag, nicht in einem Artikel.
Der Zehn-Minuten-Durchgang, der Reihe nach
- Prüfen Sie Ihr Preset, nicht Ihre Absichten. Auf macOS und Linux vergewissern Sie sich, dass Default aktiv ist und nicht Turbo. Unter Windows setzen Sie die Outside of Folder File Access Policy auf Always Ask und schalten Sandbox Mode dort ein, wo das eigene Preset es anbietet.
- Suchen Sie nach
.agents/, bevor Sie einem Repository vertrauen. Vier Pfade darin sind ausführbare Richtlinie, die über einen Pull Request hereinkommt:rules,skills,mcp_config.jsonundhooks.json. Sie verdienen einen Reviewer, genau wie ein CI-Workflow. - Schreiben Sie nie
command(*). Schreiben Sie die fünf Befehle auf, die Ihr Projekt tatsächlich ausführt. Der Vergleich ist präzise genug, dass sich diese zehn Minuten lohnen. - Holen Sie die eine Regel, die Sie nicht verlieren dürfen, aus der Prosa heraus. Ein
PreToolUse-Hook mitforce_askignoriert zwischengespeicherte Berechtigungen. Eine Zeile in der GEMINI.md nicht. - Entscheiden Sie die Telemetriefrage ein einziges Mal, in Settings, und halten Sie schriftlich fest, was Sie entschieden haben und warum. Jemand wird danach fragen.
- Lesen Sie das Diff, denn nichts von alldem liest das Diff.
Was wir verkaufen, klar gesagt
Punkt sechs ist unser Produkt. Die anderen fünf stehen in diesem Text, weil sie kostenlos sind und vorher kommen.
VibeDefend installiert sich in der Umgebung des Agenten, nicht in Ihrem Repository. Es hängt sich an die oben beschriebene Hook-Fläche, stellt dem Modell unmittelbar vor dem Schreibvorgang die für die bearbeitete Datei relevanten Regeln vor Augen und prüft anschließend, was dabei herauskommt. Was es nicht tut, ist erzwingen: die deterministische Hälfte ist die Sperre auf der Aktion, während die Regel im Kontext ein Argument bleibt. In unserer eigenen Studie hat ein Agent eine Regel übergangen, die ihm dreizehnmal zugestellt worden war. Wir benennen lieber, welche der beiden eine Kontrolle ist, als beide dafür ausgeben zu lassen, und das vollständige Modell steht in Sicherheit von KI-Coding-Agenten.
Häufige Fragen
Ist Google Antigravity sicher?
Sicher gegen Schäden auf Maschinenebene unter macOS und Linux; überall unbestimmt gegen Fehler auf Codeebene. Shell-Befehle laufen auf diesen beiden Plattformen in einer standardmäßig aktiven Systemsandbox, mit blockiertem ~/.ssh und .env und auf freigegebene Domains begrenztem Netzwerkzugriff. Nur prüft nichts an dieser Grenze den Code, den der Agent schreibt: ein vollständig isolierter Lauf kann eine kaputte Zugriffsprüfung committen.
Darf man Antigravity auf Unternehmenscode einsetzen?
Unter macOS oder Linux mit dem Default-Preset ist die technische Haltung vertretbar, besser sogar als bei mehreren Wettbewerbern. Im regulierten Umfeld entscheiden zwei Fragen. Laufen Ihre Geräte unter Windows, wo die Sandbox noch fehlt? Und haben Sie die Enterprise-Lizenz, bei der Google erklärt, Prompts, Antworten, Code und Telemetrie würden „niemals außerhalb Ihrer privaten Umgebungen gespeichert" und landeten in Ihrem eigenen Google-Cloud-Projekt?
Hat Antigravity einen Sandbox-Modus?
Ja, und unter macOS und Linux standardmäßig aktiv. Linux nutzt Kernel-Namespaces, die „das Dateisystem isolieren, die Prozesse des Hosts verbergen und das Netzwerk kappen", macOS Seatbelt-Profile, die „den Dateisystemzugriff und Socket-Verbindungen einschränken". Mit dem Default-Preset laufen Befehle in dieser Sandbox mit Zugriff nur auf Workspace und temporäre Verzeichnisse, ohne Netz und ohne manuelle Freigabe.
Warum wird Sandboxing unter Windows nicht unterstützt?
Weil die Windows-Version noch das ältere Berechtigungssystem ausführt. Googles Dokumentation hält fest, das aktualisierte System sei „derzeit auf macOS und Linux verfügbar, wo die Sandbox standardmäßig aktiviert ist", und Windows werde „in einer künftigen Version auf das vereinheitlichte Berechtigungssystem umgestellt". Bis dahin zeigt Windows andere Regler: eine Terminal Execution Policy, eine Outside of Folder File Access Policy und einen Schalter Sandbox Mode in einem eigenen Preset.
Wie umgeht man die Berechtigungen in Antigravity, und sollte man das?
Kein Flag, das man aus Claude Code mitbringen könnte: ein Gegenstück zu --dangerously-skip-permissions auf der Kommandozeile gibt es nicht. Vorgesehen sind das Turbo-Preset und eine Regel command(*). Unter macOS oder Linux laufen beide weiterhin in der Sandbox, und genau das macht sie überlebbar; unter Windows fehlt dieser Boden heute. Das bessere Mittel gegen Freigabemüdigkeit bleibt, die fünf Befehle zu erlauben, die Ihr Projekt wirklich ausführt.
Kann Antigravity Terminalbefehle ohne Rückfrage ausführen?
Ja, mit dem Default-Preset unter macOS und Linux, innerhalb der Terminal Sandbox. Das ist dokumentiertes Verhalten und keine Fehlkonfiguration: „Befehle können in der Sandbox ohne manuelle Freigabe laufen", wobei der Zugriff auf Workspace und temporäre Verzeichnisse begrenzt bleibt, ohne Netz. Unter Windows brauchen nicht deklarierte Befehle weiterhin eine manuelle Freigabe.
Kann man einen Antigravity-Skill von GitHub gefahrlos installieren?
Behandeln Sie ihn wie eine Abhängigkeit, denn die Dokumentation bietet kein Vertrauensmodell an. Ein Skill liegt in .agents/skills/ oder ~/.gemini/config/skills/, verlangt eine SKILL.md und kann einen Ordner scripts/ mitbringen, und der Agent „entscheidet anhand des Kontexts", ob er ihn nutzt, ohne dass jemand ihn darum bittet. Die Sandbox hält die Befehle eines Skills zurück, nicht seine Anweisungen, und eine bösartige Anweisung erzeugt ein sauberes Diff.
Kann ein MCP-Server in Antigravity Werkzeuge ohne Freigabe ausführen?
Standardmäßig nicht. Die Dokumentation sagt, „nicht konfigurierte MCP-Werkzeuge laufen im Ask-Modus und erfordern vor der Ausführung Ihre Freigabe", konfiguriert in ~/.gemini/config/mcp_config.json oder .agents/mcp_config.json. Das verbleibende Risiko ist nicht die Ausführung, sondern die Werkzeugbeschreibung, die das Modell liest, bevor Sie überhaupt gefragt werden.
Wie erzwingt man eine Regel in Antigravity?
Mit einem Hook oder einer Deny-Regel, nicht mit Prosa. Ein PreToolUse-Hook, der "force_ask" zurückgibt, „fragt immer den Nutzer und ignoriert zwischengespeicherte Berechtigungen": er ist der einzige Entscheidungspunkt, den ein früheres Always Allow nicht übergehen kann. Deny schlägt ebenfalls alles andere, da widersprüchliche Regeln strikt als Deny > Ask > Allow ausgewertet werden.
Garantiert eine GEMINI.md, dass der Agent meine Regeln befolgt?
Nein, und Googles Dokumentation behauptet das nie. Regeln liegen in ~/.gemini/GEMINI.md oder .agents/rules, begrenzt auf 12.000 Zeichen je Datei. In unserer kontrollierten Studie mit 90 Läufen auf einem vergleichbaren Agenten setzte ein realistisch von Hand geschriebener Regelabschnitt genau 7 von 55 Regeldetails exakt um: dasselbe Ergebnis wie ganz ohne Regeldatei. Lassen Sie erratbare Konventionen dort stehen, und bringen Sie willkürliche Werte, Fehlercodes und Schwellen dorthin, wo der Agent ihnen im Moment der Änderung begegnet.


