Full dataeksport

Du kan eksportere organisasjonens data når du vil fra adminflaten: hvert repository som en git bundle, issues, pull requests, kommentarer, etiketter, milepæler og utgivelser for hvert repository, pakkeoversikten din, skannefunn og beslutninger fra pakkepolicyen, bygge- og utgivelsesattesteringene dine med signaturer, SBOM-ene for repositoryene og containerimagene dine og revisjonssporet for de siste 90 dagene. Alt er i standardformater og kan lastes ned som én .tar.gz med et signert SHA-256-manifest som dekker hver fil.

Denne siden beskriver hva pakken inneholder, hvordan du verifiserer den, og hvilke grenser som gjelder. Eksporten er inkludert i planen til 30 € per bruker; du trenger ikke noe Enterprise-nivå.

Hva pakken inneholder

Strukturen i pakken, hver fil i den og formen på hver post er beskrevet på én side: Eksportskjema. Kort fortalt: én git bundle per repository, issues, pull requests, kommentarer, etiketter, milepæler, utgivelser og innstillinger for hvert repository som NDJSON, pakkeoversikten og fillisten din, oversikten over tredjepartskomponenter, tilgangsloggen for registeret, skannefunnene, beslutningene fra pakkepolicyen og de signerte attesteringene, SBOM-ene for repositoryene og containerimagene dine og revisjonssporet, alt under ett DSSE-signert SHA-256-manifest. Innholdet i pakkene kommer på forespørsel som et eget arkiv; se §«Innholdet i pakkene».

Innholdet i pakkene

Huk av for Ta med pakkeinnhold når du starter en eksport (eller send {"include_packages": true} til API-et), så lager eksporten et eget arkiv ved siden av pakken: hver fil i hver pakkeversjon organisasjonen din eier, lest fra registerets lagring på eksporttidspunktet.

export-<your-org-slug>-<timestamp>.packages.tar
└── packages/
    ├── npm/<name>/<version>/<file>               — e.g. npm/@acme/lib/1.2.0/lib-1.2.0.tgz
    ├── npm/<name>/<version>/<file>.cdx.json      — the file's SBOM (CycloneDX), and .spdx.json (SPDX)
    ├── maven/<group>/<artifact>/<version>/<file>
    ├── pypi/<name>/<version>/<file>
    ├── generic/<name>/<version>/<file>          — and the same shape for every other non-container type
    └── container/<image>/                        — one OCI image layout per image
        ├── oci-layout
        ├── index.json                            — one entry per tag
        └── blobs/sha256/<digest>                 — manifests, configs and layers

• Signert sammen med pakken. manifest.json i pakken registrerer arkivets navn, størrelse og SHA-256 (packages_archive) og hver fil i det (objects), så den ene DSSE-signaturen dekker begge nedlastingene. VERIFY.md i pakken har kommandoene; se også §«Verifisere pakken».
• SBOM-er. Hver pakkefil leveres med materiallisten (SBOM) som fremforge laget for den da den ble lastet opp: <file>.cdx.json (CycloneDX) og, der en ble laget, <file>.spdx.json (SPDX), ved siden av filen, for alle typer unntatt container. De står i manifestets objects som alle andre filer. En fil som skanneren ikke kunne behandle, har ingen. Hvis en pakke selv leverer en fil med nøyaktig det navnet, beholdes pakkens fil, og SBOM-en utelates. Containerimager får ikke SBOM-er per fil her; SBOM-ene deres er beskrevet under SBOM-er.
• Containere er OCI image layouts, som skopeo, crane, oras og podman leser direkte. For eksempel, for å pushe en tag til et annet register: skopeo copy oci:packages/container/<image>:<tag> docker://<registry>/<image>:<tag>.
• Vanlig .tar, ikke komprimert: pakkefiler (.tgz, wheels, jar-filer, image-lag) er allerede komprimert.
• Nedlastingslenke: vises som Pakkeinnhold ved siden av lenken til pakken og returneres av API-et som packages_signed_url. Gyldig i 7 dager, som lenken til pakken. Selve arkivet slettes etter 7 dager; start en ny eksport hvis du trenger det igjen.
• Grense på 50 GiB. Hvis innholdet i organisasjonens pakker er større enn 50 GiB, avvises forespørselen med en gang (export-too-large), og eksporten uten pakkeinnhold er fortsatt tilgjengelig. Kontakt support@frem.sh for en assistert eksport av større registre.

Hver fil kontrolleres mot oversiktens størrelse og SHA-256 når den skrives, og hver SBOM mot størrelsen og SHA-256-verdien som ble registrert da den ble laget; en eksport der pakkefilene ikke stemmer, feiler i stedet for å levere et arkiv som ikke stemmer med manifestet.

Skannefunn, policy, attesteringer og SBOM-er

Hver eksport inneholder også sikkerhetsdataene fremforge har om organisasjonen din, dekket av det signerte manifestet som alle andre filer:

• findings/: funnene fra hver skanner, én NDJSON-fil hver (statisk analyse, avhengigheter, lisenser, containerimager, secrets, skadevare i opplastinger, avhengigheter og containerlag, sårbarheter og lisenser i registerpakker, workflow-actions som ikke er låst), med avvisningene: hvem som avviste et funn, hvorfor og til når.
• policy/: pakkepolicyen din, reglene for tillatelse og blokkering og godkjennerne, gjeldende vurdering for hver pakkefil, beslutninger fra sperrene (inkludert dem som shadow-modus ville blokkert), unntak med godkjenninger, overstyringer for skadevare og organisasjonsinnstillingene for hver skanner.
• attestations/: byggeproveniensen, utgivelsesattesteringene og attesteringene som er lastet opp sammen med en SBOM, hver med sin DSSE-konvolutt og, der en ble laget, sin nøkkelfrie Sigstore-bundle.
• sboms/: hver SBOM fremforge lagrer for repositoryene dine (sboms/repos/, CycloneDX og, der en ble laget, SPDX) og containerimagene dine (sboms/images/), som selve dokumentene, indeksert i sboms/index.ndjson. Hver linje i indeksen sier om dokumentet stemte med SHA-256-verdien som ble registrert da det ble lagret. SBOM-er for pakker ligger ikke her: de kommer ved siden av filene sine i arkivet med innholdet i pakkene.

Filene og feltene deres er oppført i Eksportskjema.

Hva pakken IKKE inneholder (og hvorfor)

• Innholdet i pakker og lag i containerimager, med mindre du ber om dem: da kommer de som et eget arkiv; se §«Innholdet i pakkene».
• Innhold i LFS-filer; se §«LFS-innhold».
• Ressurser i utgivelser: releases.ndjson inneholder metadataene for hver utgivelse, inkludert nedlastings-URL-en til hver ressurs; hent ressursene fra de URL-ene.
• Logger og artefakter fra Forgejo Actions: de eksporteres ikke. Last ned loggene og artefaktene til en kjøring fra kjøringssiden eller Actions-API-et mens du trenger dem.
• SBOM-er for pakker, med mindre du ber om innholdet i pakkene: SBOM-en for hver pakkefil i registeret følger filen i arkivet med innholdet i pakkene. SBOM-er for repositoryer og containerimager er med i pakken, under sboms/ (se §«Skannefunn, policy, attesteringer og SBOM-er»).
• Fakturaer og faktureringsdata: ikke en del av pakken; de ligger i adminflaten under Fakturering.
• Andre kunders data: utsnittet av revisjonsloggen inneholder bare organisasjonens egne revisjonshendelser.

Slik starter du en eksport

1. Adminflaten for organisasjonen → fanen Dataeksport.
2. Huk eventuelt av for Ta med pakkeinnhold (se §«Innholdet i pakkene»).
3. Klikk Start en ny eksport.
4. Eksportkjøreren plukker opp jobben innen 5 minutter. En liten organisasjon er klar noen minutter senere; tiden øker med størrelsen på repositoryene. Fanen Dataeksport viser statusen til jobben og, når den er klar, nedlastingslenken.
5. Nedlastingslenken er gyldig i 7 dager etter at pakken er klar, og pakkefilen slettes 7 dager etter at den ble laget, inkludert kopien for katastrofegjenoppretting. Under rettslig tilbakeholdelse beholdes filen.

Hvis en eksport feiler, får personen som ba om den, en e-post med årsaken, og du kan starte en ny med en gang.

Frekvensgrense

Én eksport per organisasjon per 24 timer. Fast grense. En eksport som feiler, teller ikke, så du kan prøve på nytt med en gang. Grunnen: å lage en git bundle av et repository på flere GB og beregne hashene i manifestet er ikke gratis, og et feilklikk skal ikke sette i gang hundre eksporter i løpet av natten.

Hvis du virkelig trenger en eksport til innen 24 timer, kontakt support@frem.sh. Vi kan oppheve grensen på forespørsel.

Størrelsesgrenser

Arkivet strømmes til lagring mens det bygges, så størrelsen begrenses ikke av minne eller av en grense for enkeltopplastinger. Dette begrenser en eksport i dag:

• Omtrent 10 GB med repository-bundles og metadata, arbeidsområdet der eksportkjøreren legger filene før de arkiveres.
• Én time for hele eksporten.
• 50 GiB med pakkeinnhold, når du ber om det; avvises ved forespørselen, se §«Innholdet i pakkene».

En organisasjon over en av grensene feiler med en feilmelding i stedet for å få en ufullstendig pakke. Kontakt support@frem.sh, så kjører vi en assistert eksport i stedet (typisk en direkte synkronisering til din egen bøtte).

For de fleste organisasjoner er repositoryinnholdet den klart største delen; metadata og revisjonsdata er små til sammenligning.

Verifisere pakken

Å kontrollere at hver fil har kommet fram uskadd, krever én kjøring av sha256sum. Forutsetning: jq (SHA-256-verktøyet følger med alle moderne operativsystemer, sha256sum på Linux, shasum -a 256 på macOS).

Pakk ut arkivet, og kjør deretter dette i den utpakkede katalogen:

# Linux
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Hvis hver linje melder OK, stemmer hver fil i pakken med SHA-256-hashen fremforge registrerte. En avkuttet eller ødelagt nedlasting lar seg ikke pakke ut rent, eller feiler denne kontrollen.

Hva dette fanger opp, og hva det ikke fanger opp

SHA-256-kontrollen fanger opp manipulasjon etter eksporten (ødelagte nedlastinger, MITM-endringer i et usignert speil) og knytter pakken til manifestet fremforge laget. For å bevise at selve manifestet er laget av fremforge (og ikke av en tredjepart som byttet ut pakken din med sin egen), kjører du verifiseringen av det signerte manifestet i neste seksjon. Den binder manifestets bytes kryptografisk til fremforges publiserte Ed25519-byggenøkkel.

Verifisere det signerte manifestet

Pakken leveres med et DSSE-signert in-toto Statement over manifest.json i manifest.json.intoto.jsonl. Signaturen lages med fremforges SLSA-byggenøkkel (Ed25519), den samme nøkkelen som signerer SLSA-byggeproveniens for artefakter laget av den hostede runneren, og verifiseres mot den offentlige tillitsroten på https://www.frem.sh/.well-known/slsa-trust-root.json. Den aktive nøkkelen er fremforge-slsa-builder-v2, i bruk siden nøkkelbyttet 2026-09-12; kommandoene nedenfor velger den. VERIFY.md i pakken din har de samme kommandoene med nøkkelen som signerte akkurat den pakken, ferdig utfylt.

Bruk nøkkelen konvolutten navngir. keyid i manifest.json.intoto.jsonl (jq -r '.signatures[0].keyid' manifest.json.intoto.jsonl) er nøkkelen som signerte den. En pakke eksportert før 2026-09-12 er signert med fremforge-slsa-builder-v1, som blir værende i tillitsroten for å verifisere gamle signaturer (den signerer ikke lenger noe); for en slik pakke velger du fremforge-slsa-builder-v1 i trinn 1. En nåværende pakke verifiseres ikke under v1: trinn 2 skriver da ut DSSE signature verification FAILED.

Du verifiserer med curl, jq, openssl og python3, som alle følger med distribusjonene som standard. Ingen fremforge-CLI. Ingen avhengighet til Sigstore Fulcio / Rekor / TUF-CDN.

1. Hent den offentlige tillitsroten og trekk ut den offentlige nøkkelen

curl -sSfL https://www.frem.sh/.well-known/slsa-trust-root.json -o trust-root.json
jq -r '.trusted_keys[] | select(.kid=="fremforge-slsa-builder-v2") | .pem' \
  trust-root.json > builder.pub

2. Verifiser signaturen på DSSE-konvolutten

python3 - <<'PY'
import base64, json, hashlib, subprocess, sys, pathlib

env = json.loads(pathlib.Path("manifest.json.intoto.jsonl").read_text().strip())
payload_type = env["payloadType"]
payload_b64  = env["payload"]
payload      = base64.b64decode(payload_b64)

# Reconstruct the DSSE pre-authentication encoding.
pae = (
    b"DSSEv1 "
    + str(len(payload_type)).encode() + b" "
    + payload_type.encode() + b" "
    + str(len(payload)).encode() + b" "
    + payload
)
pathlib.Path("pae.bin").write_bytes(pae)

sig_b64 = env["signatures"][0]["sig"]
pathlib.Path("sig.bin").write_bytes(base64.b64decode(sig_b64))

# Ed25519 verify with openssl: pkeyutl -verify needs the SAME bytes
# the signer hashed. EdDSA is "pure" — no pre-hash — so feed the
# raw PAE buffer.
r = subprocess.run(
    ["openssl", "pkeyutl", "-verify", "-pubin",
     "-inkey", "builder.pub",
     "-rawin", "-in", "pae.bin",
     "-sigfile", "sig.bin"],
    capture_output=True, text=True,
)
if r.returncode != 0 or "Signature Verified Successfully" not in r.stdout:
    print("DSSE signature verification FAILED:", r.stdout, r.stderr, file=sys.stderr)
    sys.exit(1)
print("DSSE signature: OK")

# Cross-check the signed manifestSha256 matches the on-disk manifest.json.
stmt = json.loads(payload)
claimed = stmt["predicate"]["manifestSha256"]
actual  = hashlib.sha256(pathlib.Path("manifest.json").read_bytes()).hexdigest()
if claimed != actual:
    print(f"manifestSha256 mismatch: signed={claimed} actual={actual}", file=sys.stderr)
    sys.exit(1)
print(f"manifestSha256: OK ({actual})")

# Sanity-check the predicate type.
if stmt["predicateType"] != "https://fremforge.eu/spec/export-bundle/v1":
    print(f"unexpected predicateType: {stmt['predicateType']}", file=sys.stderr)
    sys.exit(1)
print("predicateType: OK")
PY

3. Verifiser SHA-256 for hver fil mot manifestet (som nå er klarert)

# Linux:
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS:
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Hvis alle tre trinnene går gjennom, er pakken manipulasjonsavslørende fra ende til ende: hver fil stemmer med SHA-256-verdien fremforge registrerte, manifestet stemmer med det fremforge signerte, og signaturen er laget med den publiserte byggenøkkelen.

4. Innholdet i pakkene (bare hvis du ba om det)

Last ned .packages.tar til den samme katalogen, og kontroller deretter arkivet og hver fil i det mot det samme signerte manifestet:

echo "$(jq -r '.packages_archive.sha256' manifest.json)  $(jq -r '.packages_archive.name' manifest.json)" | sha256sum --check
tar -xf "$(jq -r '.packages_archive.name' manifest.json)"
sha256sum --check <(jq -r '.objects[] | "\(.sha256)  \(.path)"' manifest.json)

Hva signaturen beviser

• At bytene i pakken du mottok, er identiske med det fremforge laget på eksporttidspunktet.
• At manifestet er laget med fremforges byggenøkkel, ikke av en tredjepart.
• At det signerte predikatet (https://fremforge.eu/spec/export-bundle/v1) oppgir organisasjonens slug, ID-en til eksportforespørselen, antall filer og samlet antall bytes, slik at en pakke fra en annen kunde som ble byttet inn, ikke ville verifiseres.

Hva den ikke beviser

• Tidspunkt: den signerte exportedAt er fremforges egen påstand; for tidsstempler som en tredjepart kan bevitne, kryssjekker du utsnittet av revisjonsloggen i pakken mot den offentlige, WORM-forankrede revisjonskjeden.
• Tilbakekalling av nøkler: tillitsrotens JSON er fasiten; hvis fremforge senere tilbakekaller byggenøkkelen, slutter gamle signaturer å verifiseres når nøkkelen forsvinner fra trusted_keys. Hent tillitsroten på nytt hvis du verifiserer lenge etter at eksporten ble laget.

Klone et repository på nytt fra en bundle

Hver bundles/<repo>.bundle er en vanlig git bundle. Slik gjenoppretter du:

git clone bundles/<repo>.bundle <repo>
cd <repo>
git remote remove origin                  # bundle URL is local
git remote add origin <new-fremforge-or-elsewhere-url>
git push -u --mirror origin

--mirror bevarer alle brancher, tagger og refs. Bundlen gjenskaper hele historikken i repositoryet, med identiske SHA-er, uten at du trenger å force-pushe til noen ny remote.

LFS-innhold

Innholdet i LFS-filer er ikke med i pakken. Git-bundlen har pekeren til hver LFS-fil (oid og size), så historikken er fullstendig; selve innholdet blir liggende på LFS-serveren til fremforge. Å dra mange gigabyte med binære vedlegg inn i hver eksport ville blåst opp størrelsen for alle.

metadata/<repo>/lfs-manifest.ndjson er LFS-oversikten per repository: én linje per LFS-objekt som en branch, tag eller pull request i repositoryet viser til.

Oversikten bygges fra repositoryets historikk, så objekter som er lastet opp til LFS-serveren, men som ingen branch, tag eller pull request viser til, er ikke med. Et repository uten LFS får en tom fil. Hvis repositoryets historikk viser til LFS-objekter, men LFS-serveren til fremforge ikke kan spørres, feiler eksporten i stedet for å levere en ufullstendig oversikt.

For å laste ned LFS-innhold etter at du har klonet repositoryet på nytt fra bundlen:

git lfs install
git lfs fetch --all

Dette henter fra LFS-serveren til fremforge mens du fortsatt er betalende kunde (LFS-båndbredde er inkludert). Etter en oppsigelse beholder vi dataene dine i 90 dager; LFS-henting fungerer i den perioden.

For en enterprise-eksport som har LFS-bytene med i selve pakken, kontakt support. Vi beregner størrelsen på pakken og kan måtte kjøre eksporten som en synkronisering fra OBS til OBS i stedet for et nedlastbart arkiv.

Bytte til en annen leverandør (EUs dataforordning)

Denne seksjonen er informasjonen som artikkel 26 i EUs dataforordning (Data Act, forordning (EU) 2023/2854) krever. Avtalevilkårene bak den står i vilkårene §16.6.

Du kan bytte til en annen leverandør, flytte alt til din egen infrastruktur eller få alt slettet, når som helst, med eller uten å si opp.

Formater. Alt i pakken er i standard åpne formater (git bundle, JSONL, in-toto DSSE, JSON), dokumentert på siden Eksportskjema. Ingen formater som er proprietære for fremforge, og du trenger ikke fremforge-verktøy for å lese noe av det.

Import til en selvhostet Forgejo. fremforge kjører en modifisert Forgejo-bygg, men patchene endrer ikke datamodellen i Forgejo, så en eksport kan importeres direkte i en vanlig selvhostet Forgejo-instans. Klon hvert repository på nytt fra bundlen (§«Klone et repository på nytt fra en bundle») og push til den nye verten med --mirror. Issues og pull requests flyttes via de GitHub-API-kompatible endepunktene som er nevnt nedenfor.

Sletting i stedet. Hvis du vil at dataene skal slettes i stedet for flyttes, sier du det i den samme forespørselen. Vi sletter alle eksporterbare data og digitale ressurser etter databehandleravtalen §9 og bekrefter skriftlig.

Hjelp er en del av avtalen. Etter vilkårene §16.6(h) hjelper vi til med byttet i god tro, også ved å svare på tekniske spørsmål fra leverandøren du flytter til. Bare spør.

Oppsigelse og eksporten

Hvis du sier opp fremforge-abonnementet:

• Det siste eksportvinduet på 7 dager er fortsatt gyldig. Den signerte URL-en fortsetter å virke.
• En ny eksport kan startes når som helst i den skrivebeskyttede oppbevaringsperioden på 90 dager etter oppsigelsen. Samme flyt, samme brukergrensesnitt, samme pakke.
• En eksport som settes i kø sent i perioden på 90 dager, selv ved +89 dager og 23 timer, blir gjennomført: fremforge holder igjen den fysiske slettingen av Forgejo-organisasjonen din i opptil 7 dager etter 90-dagersmerket så lenge en eksport står i kø eller kjører. Når eksporten er ferdig, fortsetter slettingen ved neste planlagte opprydding.
• Etter 90 dager (pluss eksportfristen over) slettes dataene etter databehandleravtalen §9, og muligheten til å eksportere forsvinner med dem.

Hvis du sier opp nettopp fordi du vil ha en siste eksport, tar du eksporten først, verifiserer den lokalt og sier deretter opp. Fristen er romslig, men å verifisere før sletting er den grundige framgangsmåten.

Bare ett repository?

Den fulle eksporten gjelder hele organisasjonen: hvert repository med issues, pull requests og utgivelser, pakkeoversikten og utsnittet av revisjonsloggen, i én signert pakke. Hvis du bare trenger ett repository, finnes det enklere veier:

• git clone --mirror: full Git-historikk, brancher og tagger som et bart repository som kan klones offline. fremforge eksponerer ikke port 22 offentlig; bruk enten SSH-over-443-endepunktet (ssh.frem.sh:443) eller HTTPS-formen:

  # SSH over port 443 (single endpoint for all orgs; uses your registered SSH key):
  git clone --mirror ssh://git@ssh.frem.sh:443/<org>/<repo>.git
  
  # OR HTTPS clone with a PAT (`ffp_…`) from Settings → API tokens:
  git clone --mirror "https://x-access-token:${FREMFORGE_PAT}@frem.sh/<org>/<repo>.git"
  
  cd <repo>.git
  git lfs fetch --all   # if the repo uses LFS

  Fingeravtrykkene for vertsnøklene til ssh.frem.sh er publisert på www.frem.sh/ssh-fingerprints; kontroller dem ved første tilkobling. Resultatet er en katalog som er klar for git bundle; kjør tar -czf på den for én flyttbar fil.

• Nedlasting av repositoryet som zip/tarball: frem.sh/<org>/<repo>/archive/<branch>.zip eller .tar.gz for et øyeblikksbilde av én ref. Ingen historikk, ingen LFS, bare arbeidstreet i den branchen.

• Issues og PR-er per repository som JSON, via API-et: GET /api/v1/repos/<org>/<repo>/issues?state=all&type=issues og ?type=pulls. Migreringsveiledningene viser formen på kallet; svaret er GitHub-API-kompatibel JSON.

Den signerte eksporten for hele organisasjonen er riktig verktøy når du vil ha alt (hvert repository, metadataene, utsnittet av revisjonsloggen, det signerte manifestet); veiene per repository over passer for det hverdagslige tilfellet «jeg må sende akkurat dette repositoryet til noen».

Programmatisk API

Den samme eksporten kan nås via REST-API-et:

# Start a new export
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# ... or with package contents (separate archive, 50 GiB limit)
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" -H "Content-Type: application/json" \
  -d '{"include_packages": true}' \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# Poll for status
curl -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports/<job-id>

# When status=ready, follow the signed_url field
# (and packages_signed_url, if you asked for package contents)

OpenAPI-spesifikasjon: docs.frem.sh/reference/api/.

Personverngarantier

Eksporten kan revideres begge veier:

• Hvem som eksporterte: hver eksportforespørsel registreres i din egen revisjonslogg (data-export.requested fra adminflaten, data-export.queue.api fra API-et) med brukeren eller tokenet som ba om den. Handlinger som fremverks support utfører på organisasjonen din, merkes som det i den samme loggen.
• Hvis data: utsnittet av revisjonsloggen velges ut fra organisasjonens kunde-ID, så det inneholder bare organisasjonens egne revisjonshendelser.
• Hygiene for signerte URL-er: nedlastings-URL-en er en forhåndssignert lenke med bare lesetilgang til ditt ene arkiv, gyldig i 7 dager. Etter det slutter URL-en å virke, og eksporten forsvinner fra fanen Dataeksport.

Se også

• Priser: inkludert i planen til 30 € per bruker; ikke et eget nivå.
• Databehandleravtalen §9: forpliktelsen til å levere tilbake data som dette oppfyller.
• Tillit: hvordan dette passer inn i den større historien om suverenitet og kontroll.