Hvordan Skriveøkt by Papertek beskytter lærere og elever.
Hva som faktisk lagres avhenger av innloggingsmåten. Tabellen rett under viser de tre modusene — og hvilke av punktene over som gjelder i hver.
Skriveøkt kan brukes på tre måter, og personvernet er vesentlig forskjellig i hver. Forskjellen handler både om hvor mye som lagres og om hvem som har det juridiske ansvaret.
| Modus | Om eleven | Om læreren | Juridisk grunnlag |
|---|---|---|---|
| Anonym Prøvekode + kallenavn (elev) Lærernøkkel eller Vipps (lærer) |
Bare kallenavnet eleven skriver inn. Tilfeldig ID per prøve — ikke sporbar på tvers av prøver. | Ingenting. Vipps lagrer bare en anonym kode («sub») som ikke kan spores tilbake til personen. | Ingen personopplysninger behandles — ingen databehandleravtale nødvendig. Dette er den eneste modusen som er unntatt. |
| Google-konto Privat eller skoletilknyttet Google-konto |
Navn og e-postadresse fra kontoen lagres på deltakerraden, sammen med fokus- og integritetsdata. | Navn og e-postadresse lagres på lærerkontoen. | Databehandleravtale kreves — på lik linje med Feide. Google-kontoer er som regel ikke skoleadministrerte, så skolen har ingen kontroll over identitetene. Bruk Feide i skolesammenheng. |
| Feide Skolekonto — elev og lærer |
Navn og e-postadresse fra skolekontoen. Svar, skrivehistorikk og fokus-/integritetsdata kan knyttes til den identifiserte eleven. | Navn og e-postadresse fra skolekontoen. | Databehandleravtale (DBA) mellom skolen/kommunen og Papertek. Skolen er behandlingsansvarlig, Papertek er databehandler. Dette er den tilrettelagte veien for skolebruk. |
Det viktigste skillet går mellom anonym og identifisert bruk — ikke mellom Google og Feide. Plikten til å ha databehandleravtale følger personopplysningene, ikke innloggingsleverandøren: så snart navn og e-post behandles på vegne av en skole, kreves avtale. Det gjelder Google like fullt som Feide. Bare anonym bruk — prøvekode og kallenavn, med lærernøkkel eller Vipps på lærersiden — er unntatt, fordi det da ikke behandles personopplysninger i det hele tatt.
Forskjellen på Google og Feide er derfor praktisk, ikke juridisk: Feide er skoleadministrert, slik at skolen kontrollerer identitetene, tilgangene og avslutningen av dem. En Google-konto er som regel elevens eller lærerens egen, utenfor skolens kontroll. Derfor er Feide den støttede veien når elever pålegges å bruke verktøyet — og en skole som likevel bruker Google-innlogging trenger like fullt en databehandleravtale med Papertek.
Avsnittene under om anonym bruk — kryptografisk adskilt læreridentitet, «ingen persondata om elever» og lav konsekvens ved datainnbrudd — gjelder derfor verken Google- eller Feide-modus. Der er vernet i stedet tilgangsstyring, dataminimering, kort lagringstid (~30 dager for elevtekst) og sletting.
Premium-opplesing (ElevenLabs) er teknisk sperret for Feide-prøver, slik at ingen elevtekst sendes til en ekstern KI-tjeneste.
Når en lærer logger inn med Vipps, lagrer Skriveøkt by Papertek ingen personopplysninger i databasen — ikke navn, ikke e-post, ikke telefonnummer.
Det eneste som lagres er en anonym identifikator (en tilfeldig kode fra Vipps, kalt «sub»). Denne koden kan ikke brukes til å finne ut hvem læreren er — den er kun en referanse for å koble læreren til sine prøver.
Firebase Authentication (innloggingssystemet) håndterer selve påloggingen og vet midlertidig hvem du er under økten. Men vår database (Firestore) — der prøver og lærerdata faktisk lagres — mottar aldri navn, e-post eller telefonnummer.
Selv etter betaling forblir læreren anonym i databasen. Betalingen kobles til lærernøkkelen via den anonyme identifikatoren — ingen persondata legges til.
Resultat: Ved et datainnbrudd finnes det ingen kobling mellom Vipps-lærere og deres virkelige identitet i databasen. En angriper ser bare en anonym kode.
Lærernøkkelen er en tilfeldig 12-tegns kode — ikke et passord, ikke en e-postadresse. Den brukes kun til å koble læreren til sine prøver.
Prøver kobles til læreren via kryptografisk hashing (HMAC-SHA256) med en hemmelig servernøkkel — selv ikke Papertek kan koble en prøve tilbake til en spesifikk lærer uten nøkkelen.
Ved datainnbrudd ser angriperen hashede referanser, ikke hvem som eier prøvene.
Presisering: hashing er ikke det samme som kryptering. En hash kan ikke dekrypteres tilbake til nøkkelen — det er nettopp derfor vi bruker den her.
Læreren kan selv melde nøkkelen som kompromittert — alt sperres umiddelbart, med 7 dagers gjenopprettingsvindu.
Nøkler utløper automatisk (årlig).
Merk: Med Vipps-innlogging får læreren automatisk en nøkkel uten å måtte håndtere den manuelt. Lærernøkkelen er fortsatt tilgjengelig som et alternativ for administratorer som ønsker å tildele anonyme innloggingsnøkler, eller for lærere som foretrekker å ikke bruke Vipps eller Google.
Ved anonym bruk: elever trenger ikke konto — de skriver inn prøvekoden og et valgfritt kallenavn. Ingen e-post, passord eller persondata samles inn.
Ved Google- eller Feide-innlogging: navn og e-postadresse fra kontoen lagres på deltakerraden, slik at læreren ser hvem som deltok.
Kryptert under overføring (TLS) og ved lagring (Firestore-kryptering i ro). Merk at dette ikke er ende-til-ende-kryptering: læreren leser teksten i sanntid, og Papertek har teknisk tilgang til den for å drifte tjenesten. Krypteringen beskytter mot avlytting og mot at noen leser diskene i datasenteret — ikke mot lærer eller leverandør.
Elevtekst og skrivehistorikk slettes automatisk etter 30 dager. Deltakerlisten — kallenavn eller navn/e-post, innleveringsstatus, ordantall og fokusdata — står til læreren sletter prøven, og ryddes senest i den årlige oppryddingen i juli.
Læreren kan slette når som helst. Revisjonsspor for all sletting.
Ved anonym bruk: prøvedata inneholder ingen identifiserbare opplysninger om lærere (kun HMAC-referanse), og elevdata inneholder kun kallenavn (ikke navn, e-post eller personnummer). Anonyme elever har tilfeldig UUID per prøve — ikke sporbar på tvers av prøver.
Selv med full databasetilgang kan en angriper da ikke koble svar til virkelige personer. Konsekvensen av et innbrudd blir en midlertidig lekkasje av anonyme skoletekster — lav risiko.
Ved Google- eller Feide-innlogging er dette annerledes: navn og e-postadresse er lagret, og et innbrudd vil kunne knytte elevtekst og fokusdata til en navngitt elev. Risikovurderingen over gjelder ikke identifisert bruk — der er vernet tilgangsstyring, kort lagringstid og sletting, ikke anonymisering.
Strenge feltbaserte tilgangsregler i Firestore Security Rules.
Anti-juks: fokussporing, innlimingsblokkering, DevTools-deteksjon, fullskjerm-overvåkning.
Alle tellervariabler er monotone (kan bare øke) — håndhevet av server.
Automatisk rydding av foreldreløse data (ukentlig).
Strenge HTTP-sikkerhetsheadere i produksjon: Content-Security-Policy, HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff og en restriktiv Permissions-Policy.
Minimerte tredjepartsskript: Tailwind/CSS, fonter og eksportbibliotek serveres lokalt fra Paperteks domene; gjenværende tredjepartsskript er begrenset til Google/Firebase.
Sikkerhetskopiering: point-in-time recovery (7-dagers vindu) og daglige sikkerhetskopier (7 dagers retensjon) for produksjonsdatabasen.
Skriveøkt kjører i nettleseren på elevens egen maskin. Det gir god innsikt i skrivevinduet: vi ser når eleven skriver, når det står stille, når vinduet forlates, og når tekst limes inn utenfra. Hele skriveprosessen lagres, slik at læreren kan spille den av i ettertid.
Det vi ikke ser, er resten av rommet. En elev med telefon i fanget, en annen maskin ved siden av, eller nok teknisk kompetanse til å forsøke å omgå begrensningene i nettleseren, er ikke noe et nettleserbasert verktøy kan stoppe alene. Vi mener det er riktigere å si dette rett ut enn å love mer enn vi kan holde.
Derfor er Skriveøkt laget for å komme i tillegg til vanlig tilsyn underveis, ikke i stedet for. Læreren i rommet ser det skjermen ikke ser. Sammen gir de to et vesentlig sterkere grunnlag enn hver for seg — og et som tåler å bli diskutert i en vurderingssituasjon.
How Skriveøkt by Papertek protects teachers and students.
What is actually stored depends on the login method. The table right below shows the three modes — and which of the points above apply in each.
Skriveøkt can be used in three ways, and privacy differs substantially between them. The difference is both about how much is stored and about who carries the legal responsibility.
| Mode | About the student | About the teacher | Legal basis |
|---|---|---|---|
| Anonymous Test code + nickname (student) Teacher key or Vipps (teacher) |
Only the nickname the student types in. Random ID per test — not traceable across tests. | Nothing. Vipps stores only an anonymous code (“sub”) that cannot be traced back to the person. | No personal data is processed — no data processing agreement required. This is the only exempt mode. |
| Google account Personal or school-issued Google account |
Name and email address from the account are stored on the participant record, together with focus and integrity data. | Name and email address are stored on the teacher account. | A data processing agreement is required — exactly as with Feide. Google accounts are usually not school-administered, so the school has no control over the identities. Use Feide in a school setting. |
| Feide School account — student and teacher |
Name and email address from the school account. Answers, writing history and focus/integrity data can be linked to the identified student. | Name and email address from the school account. | Data processing agreement (DPA) between the school/municipality and Papertek. The school is the data controller, Papertek the data processor. This is the supported path for school use. |
The key distinction is between anonymous and identified use — not between Google and Feide. The obligation to have a data processing agreement follows the personal data, not the login provider: as soon as names and email addresses are processed on behalf of a school, an agreement is required. That applies to Google just as much as to Feide. Only anonymous use — test code and nickname, with a teacher key or Vipps on the teacher side — is exempt, because no personal data is processed at all.
The difference between Google and Feide is therefore practical, not legal: Feide is school-administered, so the school controls the identities, the access and the termination of both. A Google account is usually the student’s or teacher’s own, outside the school’s control. That is why Feide is the supported path when students are required to use the tool — and a school that nonetheless uses Google login still needs a data processing agreement with Papertek.
The sections below about anonymous use — cryptographically separated teacher identity, “no personal data about students”, and low consequence in a data breach — therefore apply to neither Google nor Feide mode. There the protection is instead access control, data minimisation, short retention (~30 days for student text) and deletion.
Premium read-aloud (ElevenLabs) is technically blocked for Feide tests, so no student text is sent to an external AI service.
When a teacher logs in with Vipps, Skriveøkt by Papertek stores no personal data in the database — no name, no email, no phone number.
The only thing stored is an anonymous identifier (a random code from Vipps, called “sub”). This code cannot be used to identify who the teacher is — it is only a reference to link the teacher to their tests.
Firebase Authentication (the login system) handles the actual login and temporarily knows who you are during the session. But our database (Firestore) — where tests and teacher data are actually stored — never receives name, email, or phone number.
Even after payment, the teacher remains anonymous in the database. The payment is linked to the teacher key via the anonymous identifier — no personal data is added.
Result: In a data breach, there is no link between Vipps teachers and their real identity in the database. An attacker sees only an anonymous code.
The teacher key is a random 12-character code — not a password, not an email address. It is used only to link a teacher to their tests.
Tests are linked to the teacher via cryptographic hashing (HMAC-SHA256) with a secret server key — even Papertek cannot trace a test back to a specific teacher without the key.
In a data breach, the attacker sees hashed references, not who owns the tests.
To be precise: hashing is not the same as encryption. A hash cannot be decrypted back into the key — which is exactly why we use one here.
The teacher can report their key as compromised — everything is locked immediately, with a 7-day recovery window.
Keys expire automatically (annually).
Note: With Vipps login, teachers automatically get a key without having to manage it manually. The teacher key is still available as an option for administrators who want to assign anonymous login keys, or for teachers who prefer not to use Vipps or Google.
In anonymous use: students do not need an account — they enter the test code and an optional nickname. No email, password, or personal data is collected.
With Google or Feide login: the name and email address from the account are stored on the participant record, so the teacher can see who took part.
Encrypted in transit (TLS) and at rest (Firestore encryption at rest). Note that this is not end-to-end encryption: the teacher reads the text in real time, and Papertek has technical access to it in order to operate the service. The encryption protects against eavesdropping and against someone reading the disks in the data centre — not against the teacher or the vendor.
Student text and writing history are automatically deleted after 30 days. The participant list — nickname or name/email, submission status, word count and focus data — remains until the teacher deletes the test, and is cleared no later than the annual July cleanup.
The teacher can delete at any time. Audit trail for all deletions.
In anonymous use: test data contains no identifiable information about teachers (only an HMAC reference), and student data contains only nicknames (not names, email, or national ID numbers). Anonymous students have a random UUID per test — not traceable across tests.
Even with full database access, an attacker then cannot link answers to real people. The consequence of a breach is a temporary leak of anonymous school essays — low risk.
With Google or Feide login this is different: name and email address are stored, and a breach could link student text and focus data to a named student. The risk assessment above does not apply to identified use — there the protection is access control, short retention and deletion, not anonymisation.
Strict field-based access rules in Firestore Security Rules.
Anti-cheat: focus tracking, paste blocking, DevTools detection, fullscreen monitoring.
All counter variables are monotonic (can only increase) — enforced server-side.
Automatic cleanup of orphaned data (weekly).
Strict HTTP security headers in production: Content-Security-Policy, HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a restrictive Permissions-Policy.
Minimised third-party scripts: Tailwind/CSS, fonts and export libraries are served locally from Papertek’s domain; remaining third-party scripts are limited to Google/Firebase.
Backups: point-in-time recovery (7-day window) and daily backups (7-day retention) for the production database.
Skriveøkt runs in the browser on the student's own machine. That gives a clear view of the writing window: we see when a student is writing, when nothing is happening, when the window is left, and when text is pasted in from outside. The whole writing process is stored, so the teacher can replay it afterwards.
What we do not see is the rest of the room. A student with a phone in their lap, a second machine beside them, or enough technical skill to attempt to work around the browser's limits, is not something a browser-based tool can stop on its own. We would rather say so plainly than promise more than we can keep.
Skriveøkt is therefore built to come in addition to normal supervision, not instead of it. The teacher in the room sees what the screen cannot. Together the two give a substantially stronger basis than either alone — one that holds up when a submission is discussed.