Sådan virker LinkPilots hemmelige links.

1. Oversigt

LinkPilot har to adskilte pipelines til links på samme platform: intelligente links til kortlinks med eget domæne og klikstatistik, og hemmelige links til levering af følsomme oplysninger, der kan åbnes én gang, udløber og kan beskyttes med en adgangssætning. De holdes adskilt i data, i koden og i produktet, så hemmeligt indhold aldrig kan sive ud i statistikdashboards, dataeksporter eller AI-funktioner.

Denne side beskriver pipelinen for hemmelige links: hvordan en hemmelighed oprettes, hvordan den vises, hvad der sker, efter at den er set, og hvilke metadata vi logger undervejs.

2. Sådan virker hemmelige links

1. Afsenderen opretter en hemmelighed og kan vælge en adgangssætning, en udløbstid og et maksimalt antal visninger, før den slettes.
2. Afsenderens browser krypterer indholdet, før noget bliver sendt. Det, der når frem til os, er chiffertekst. Den skrives i en særskilt secret_links-tabel, som er adskilt fra tabellerne med klikstatistik.
3. LinkPilot returnerer en kort URL (fx shrd.link/s/<slug>#k=<key>), som du deler med modtageren. Den del, der står efter #, er dekrypteringsnøglen. Den dannes i afsenderens browser og sendes aldrig til os. Vi kan ikke genskabe URL'en senere.
4. Når modtageren åbner linket, kalder appen edge-funktionen secret-reveal. En GET returnerer kun metadata (status, og om der kræves en adgangssætning). Det er først en POST med adgangssætningen, der returnerer chifferteksten. Modtagerens browser dekrypterer den derefter med nøglen fra den del af linket, der står efter #. Funktionen, der viser hemmeligheden, dekrypterer aldrig noget selv og ville ikke kunne gøre det, selv hvis den ville.
5. En vellykket visning registreres atomisk og kan med det samme markere hemmeligheden som burned, afhængigt af indstillingen for antal visninger, før den slettes.

3. Krypteringsmodel

Vi vil være præcise her, fordi ordene ”krypteret” og ”zero-knowledge” ofte bruges løst.

• Under overførslen: al trafik er TLS-krypteret hele vejen mellem modtageren, vores edge-netværk og vores administrerede database.
• I din browser, før overførslen: siden den 29. september 2026 krypteres indholdet på klientsiden med AES-GCM-256 og en 256-bit-nøgle, der dannes i din browser. Vi gemmer chifferteksten og intet andet. Nøglen ligger i den del af delingslinket, der står efter #, og den del sender browsere ikke til nogen server, hverken til os eller til Cloudflare, som leverer siden, hvor hemmeligheden vises.
• Ved lagring: chifferteksten ligger i en kolonne, der er logisk adskilt fra statistikdata, på en administreret Postgres-instans, som også har kryptering på diskniveau.
• Adgangssætninger: når du angiver en, bliver den først bragt på en standardiseret Unicode-form (NFKC), så den samme adgangssætning giver den samme nøgle, selv om den er skrevet på et andet tastatur eller med en anden indtastningsmetode. Derefter strækkes den med PBKDF2-SHA256 (210.000 iterationer) og kombineres med linkets nøgle via HKDF-SHA256. Hverken linket eller adgangssætningen kan alene dekryptere hemmeligheden. Ud over det sendes en SHA-256-hash af adgangssætningen, så serveren kan nægte overhovedet at udlevere chifferteksten til den, der ikke kender den. Adgangssætningen i klartekst skrives aldrig i vores database eller logfiler.
• Hvad det beskytter, og hvad det ikke beskytter: det fjerner os, vores database og vores edge-netværk fra den kreds, man skal stole på. Det beskytter ikke en hemmelighed, hvis fulde link er blevet videresendt, fanget på et skærmbillede eller logget af noget på modtagerens side, for linket indeholder nøglen.
• De to undtagelser, sagt ligeud: hemmeligheder, der er oprettet før den 29. september 2026, er gemt i klartekst. De bliver aldrig omskrevet i det skjulte, de virker præcis som før, og de forsvinder, efterhånden som de udløber. Vedhæftede filer krypteres også i browseren med en nøgle, der er afledt af hemmelighedens egen nøgle, så ét link åbner begge dele, og vi har ingen nøgle til nogen af dem. Det, vi stadig kan se, er en fils navn, størrelse og type: det er metadatakolonner, ikke indhold. Vedhæftede filer, der er uploadet før den 29. september 2026, ligger fortsat som almindelige filer.

Konsekvensen i praksis skal siges tydeligt: fordi vi aldrig har nøglen, kan vi ikke gendanne en hemmelighed for dig. Hvis delingslinket går tabt, er indholdet væk.

Kontrollér det selv. Du behøver ikke tage krypteringen i browseren for gode varer. Den samme krypteringskode findes i vores repository linkpilot-cli, som er open source (MIT-licens) og indeholder CLI'en, TypeScript-SDK'et og MCP-serveren. Repositoryet indeholder de testvektorer, webappen bliver kontrolleret mod, så du kan læse nøgleafledningen, køre vektorerne og selv se, at det, der forlader en klient, er chiffertekst, og at nøglen kun havner i den del af linket, der står efter #. Finder du en forskel mellem koden og denne side, så anmeld den.

4. Hvad der sker, når en hemmelighed er set

• Visningen registreres atomisk via en databasefunktion, så samtidige forsøg på at vise hemmeligheden ikke kan lække den to gange.
• Når grænsen for antal visninger er nået, skifter hemmelighedens status til burned, og det gemte indhold overskrives med [REDACTED].
• Senere forsøg på at vise den får et tydeligt svar om, at den ”allerede er set og destrueret”, med HTTP 410.
• Revisionsloggen registrerer hver visning, sletning og tilbagekaldelse med en hashet IP-adresse. Det er nyttigt ved hændelseshåndtering og ved skift af loginoplysninger.

5. Udløb og tilbagekaldelse

• Alle hemmeligheder kan have et tidsbestemt udløb, 1 time, 24 timer eller 7 dage på alle planer eller en selvvalgt dato og et tidspunkt på Pro, og et valgfrit maksimalt antal visninger.
• Udløbne hemmeligheder skifter til expired ved næste adgang, og indholdet fjernes i samme skrivning.
• Ejeren kan til enhver tid tilbagekalde en hemmelighed manuelt fra dashboardet. En tilbagekaldt hemmelighed afviser straks alle forsøg på at vise den og returnerer HTTP 410.
• Når en hemmelighed er slettet, udløbet eller tilbagekaldt, kan indholdet ikke gendannes via produktet. Der findes bevidst ingen funktion til at ”fortryde tilbagekaldelse” eller ”gendanne”.

6. Beskyttelse med adgangssætning

• Adgangssætninger er valgfrie, men vi anbefaler dem til alle hemmeligheder, som en uvedkommende ikke må komme til at åbne.
• Adgangssætningen hashes med SHA-256 i browseren, sendes over TLS og sammenlignes som hash på serveren. Den rå værdi når aldrig vores database.
• Vi begrænser forsøg på adgangssætningen til 5 pr. IP-adresse pr. minut pr. hemmelighed. Grænsen håndhæves både af en begrænser i hukommelsen og af et glidende tidsvindue i databasen.
• Hvert mislykket forsøg skrives i revisionsloggen med en hashet IP-adresse, så ejere af arbejdsområdet kan se mistænkelig aktivitet.
• Vi anbefaler at sende adgangssætningen via en anden kanal end linket, for eksempel linket via e-mail og adgangssætningen som direkte besked i Slack eller som sms.

7. Beskyttelse mod linkscannere og forhåndsvisningsbots

Sikkerhedsscannere til e-mail og linkforhåndsvisninger i chatapps (Slack, LinkedIn, iMessage, Outlook) henter rutinemæssigt URL'er, så snart de dukker op. For et link, der slettes efter læsning, ville et naivt design betyde, at den allerførste forhåndsvisning sletter hemmeligheden, før modtageren ser den.

LinkPilot forhindrer det på tre måder:

• Separate endpoints til metadata og visning. En GET mod visnings-endpointet returnerer kun status, og om der kræves en adgangssætning. En visning registreres kun ved en udtrykkelig POST, som er det, et menneske udløser ved at klikke på knappen Vis.
• Spærring med adgangssætning. Når der er angivet en adgangssætning, udleveres indholdet ikke til nogen, hverken bot eller menneske, uden den korrekte hash.
• Cache-Control: no-store på alle svar, der viser en hemmelighed, så mellemled ikke gemmer indholdet i cache.

8. Hvilke metadata vi logger

For hvert forsøg på at vise en hemmelighed registrerer vi kun det, der skal til for at give ejere af arbejdsområdet en troværdig revisionslog:

• Tidspunkt for forsøget.
• Hashet IP-adresse: SHA-256 af klientens IP-adresse kombineret med et salt, der skiftes dagligt, afkortet til 32 tegn. Den rå IP-adresse gemmes aldrig.
• Grov geografisk placering (land og by) fra vores edge-netværk, når udbyderen leverer den.
• User-Agent-streng, som klienten oplyser.
• Hændelsestype: created, viewed, failed_passphrase, burned, expired, revoked.

Vi logger ikke: indholdet af hemmeligheden, adgangssætningen i rå form, den rå IP-adresse, cookies hos modtageren (der er ingen) eller nogen former for sporingspixels fra tredjepart.

9. Forskellen på hemmelige links og statistiklinks

De to pipelines deler brand, dashboard og teamindstillinger, men dataene krydser aldrig hinanden.

10. Vedhæftede filer

• Filer krypteres i browseren med en nøgle, der er afledt af hemmelighedens egen nøgle, så ét link åbner både teksten og filen.
• De leveres via kortlivede, signerede URL'er bag den samme adgangssætning, det samme udløb og den samme sletning som teksten.
• En fils navn, størrelse og type er fortsat synlige for os som metadata. Indholdet er ikke.
• Vedhæftede filer, der er uploadet før den 29. september 2026, ligger fortsat som almindelige filer, indtil de udløber. De bliver aldrig omskrevet.

11. Opbevaring

• En hemmeligheds indhold overskrives, når den slettes, udløber eller tilbagekaldes. Der er bevidst ingen gendannelse, og vi kan ikke gendanne det for dig.
• Kontodata opbevares, så længe arbejdsområdet er aktivt, og i 30 dage efter sletning, så en sletning ved en fejl kan fortrydes.
• Klikstatistik for kortlinks samles efter 90 dage til anonymiserede tal.
• Hændelser i revisionsloggen indeholder kun de hashede og saltede værdier, der er beskrevet i afsnit 8. Der er ingen rå adresse at opbevare.

12. Anonyme hemmeligheder og hemmeligheder i et arbejdsområde

Den gratis generator til hemmelige links opretter hemmeligheder uden konto. Slet efter læsning er altid slået til, udløbet er 1 time, 24 timer eller 7 dage, formularen er beskyttet af Turnstile mod automatiseret misbrug, og den samme kryptering i browseren gælder.

En hemmelighed i et arbejdsområde får desuden revisionsloggen, tilbagekaldelse fra dashboardet, vedhæftede filer og på Pro adgangssætninger samt en selvvalgt udløbsdato og et tidspunkt. Krypteringsmodellen er den samme i begge tilfælde.

13. Begrænsninger, sagt ligeud

• Et videresendt link er en videresendt hemmelighed. Intet i designet kan forhindre en modtager i at sende linket videre, før det åbnes. Kort udløb og en adgangssætning sendt via en anden kanal er det, der begrænser risikoen.
• Et mistet link er en mistet hemmelighed. Vi har aldrig nøglen, så der er intet at gendanne.
• Undtagelsen før den 29. september. Hemmeligheder, der blev oprettet før den dato, var gemt i klartekst, indtil de udløb.
• Ikke open source og ikke til selvhosting. Krypteringsklienten er offentliggjort med testvektorer i CLI-repositoryet under MIT-licens, men selve tjenesten er et hostet produkt. Hvis du skal kunne hoste tjenesten selv, så se alternativerne med open source.
• En visning er ikke en person. Loggen registrerer, hvornår og nogenlunde hvorfra en hemmelighed blev åbnet, aldrig hvem. Hvis den forkerte har åbnet den, så skift loginoplysningerne.

14. Anmeld en sårbarhed

Sikkerhedsfund og misbrugte links kan anmeldes på /report og går direkte til teamet. Henvendelser om privatliv og data sendes til privacy@uselinkpilot.com og besvares inden 30 dage. GDPR-siden viser, hvad vi behandler, og på hvilket grundlag.

15. Ofte stillede spørgsmål