Fill in this file and tell me when it is ready. This is the single input file for the next implementation pass. Background: privacy audit.
Follow-up — 10 September 2026: real contact details for Yonatan Dankner have
replaced the preview values below; the email uses plain-text (at) at the user's
request. The user confirmed it is his main mailbox and requested an independent
storage review/removal of unnecessary storage without a consent-banner system.
D7 now authorizes that focused cleanup: preference writes only on user changes;
API caches, diagnostics and the badge in memory; legacy cache/log/badge cleanup.
The prior shared-decision answer remains relevant; sole controllership has not
been established. Existing database, moderation and administrator restrictions
remain unchanged. See current notes for the resulting behavior.
The user authorised implementation and explicitly requested sample operator
details for local review. The legal pages now use Max Mustermann, Musterstraße 1,
12345 Musterstadt, Deutschland, and datenschutz@example.invalid from one shared
frontend/src/features/legal/legalOperator.ts configuration. These are preview
values only; the real operator facts below remain UNKNOWN.
Implemented: D1/D2 preservation and legal-page improvements; D3 contact display with an inert sample mailbox; a small manual D4/D11 procedure in privacy-notes.md; accurate descriptions of the existing storage, diagnostics and retention behavior. The broad implementation request does not reverse the explicit database or administrator restrictions. D5/D6 behavior, D8 access, D9 logged fields and retention/database operations remain unchanged. Storage behavior and the separate AI integration remain pending concrete decisions/verification.
Latest follow-up: the user approved the deleted-account session fix, anonymous feedback, and minor dead-code cleanup. Registration now randomises the existing session-version field for each new account; no schema migration or existing-row rewrite was added. Feedback now omits account cookies, referrer, page context and automatic authenticated diagnostics. Server-side metadata is normalised without changing the feedback schema. Existing catalog headers were explicitly left alone. Shared administrator access and applied migration history remain unchanged.
- Replace
TODOwith your answer. Short answers in English or German are fine. - Write
UNKNOWNwhen you do not know; I will identify how to verify it. - For a recommendation, write
ACCEPTor describe your alternative. - Recommendations are proposals, not already accepted decisions. Blank answers do not authorise feature removal, data deletion or publication of personal details.
- Fill sections 1–3 first. You do not need to research legal articles or Cloudflare internals yourself; factual answers and preferences are enough.
- This file is tracked by Git. Only put intended public contact details here. Use a local file reference for private evidence; do not paste passwords, tokens, customer records, reports from users or private contracts into this file.
Your small-project approach is reasonable. Keep the existing protections, use manual request handling, and avoid a new privacy dashboard, ticket system or complex moderation workflow. A separate company, office, paid compliance suite or automated daily cleanup is not a prerequisite just to complete this brief.
UNKNOWN is appropriate for facts you have not verified. It is an internal
placeholder, not text for the public notice and not an exemption from resolving
required information. No rejected decision below has been changed to ACCEPT.
| Item | What needs to happen |
|---|---|
| Full operator identity | First names and “we are students” are insufficient for the final operator identification. Agree which real people/entity operate the service and the full public identification. You need not form a company. |
| Postal address | No separate office is needed, but the applicable public provider identification needs an address at which the operator can actually be reached. An authorised university or other serviceable address may be an option; do not invent one or publish an address without authority. |
| Working contact | Choose one monitored email address and a handler. A separate backup person is optional if the group can reliably provide cover. |
| Hosting facts | Keep the confirmed Free plan. Verify the actual account customer, processing terms and enabled services before publishing claims about them. |
| Shared privileged access | You rejected changing it. Preserve that instruction, but do not describe access as individually restricted or verified safe until ownership/access has been checked. |
| Review decision | Your “No” rejects the combined D5 proposal; it does not tell us whether you want reviews removed, unchanged, or only a simpler reporting process. Preserve behavior until clarified. |
The identification point follows section 18(1) MStV. Clear information and a usable rights channel are covered by EDPB rights guidance. The shared-access concern follows EDPB security guidance.
- One contact mailbox and a short private record; no dedicated request portal.
- One short internal operating note; no separate policy for every feature.
- Manual export first; build an export helper only if an actual request makes it useful. The team still needs to be able to retrieve the relevant data.
- Agree a realistic cleanup method later. Do not promise daily deletion merely because the original questionnaire suggested it.
- Defer a new inactivity-deletion feature, custom moderation state machine and blanket age-verification system. Do not remove existing protections.
- Keep technical/provider uncertainties for implementation verification instead of asking the student group to guess legal conclusions.
This review edits the brief only. It does not make the deployed legal pages complete, change access rights, or alter the database.
- The student group operates the website independently of the university.
- Anyone with the link can use it; it is not restricted to the group.
- The goal is a simple, proportionate implementation.
- Existing account security and self-service deletion should remain intact.
Corrections to the above, if any: NONE
Confirmed follow-up — 10 September 2026: all four decide jointly. Yonatan is the contact and handles requests, technical exports/deletions and review complaints; the team assigns an available member during absences. Ben owns the Cloudflare account (Free; Pages, Workers, D1; no additional products reported). The team will record responsibilities in writing; no completed Article 26 agreement was supplied. Account/study data is used only for requested functions and secure operation, not sold or used for advertising, research or AI training; outside the team only engaged providers receive non-public data. Catalog data supports planning and reviews support course-experience exchange. Lecturers have not been informed. See privacy-notes.md for outstanding legal assessments and current behavior.
These answers supply the Impressum and privacy notice. A contact person and the actual operator can be different; describe the situation rather than guessing a legal company type.
| Information | Your answer |
|---|---|
| Who actually runs the service and decides how user data is used? List the people or existing organisation involved. | Lena, Emre, Ben and Yonatan; full public identification is unresolved. |
| Is there one decision-maker or do several members decide together? | All four decide together. Assess the appropriate joint-operator arrangement from these facts. |
| Exact full operator name(s) intended for the public pages | Yonatan Dankner as shared contact; complete identities for Lena, Emre and Ben still missing. |
| Public postal address: street, number, postcode, city, country | Yonatan: Hafengasse 11, 72070 Tübingen, Germany. No common address for all four confirmed. |
| German federal state where the operator is based | Baden-Württemberg |
| If using a university/other organisation's address: permission and ability to receive mail there confirmed? | UNKNOWN |
| Public email for privacy requests and review reports | yonatan.dankner@gmail.com; display with (at) and no link/helper. |
| Is this mailbox working, and who checks it? A first name/team role is enough internally. | Yonatan uses his main mailbox and checks it regularly (user-confirmed). |
| Backup person during holidays/exams | An available team member by internal arrangement; no fixed deputy named. |
Which of the above details are ready to appear on the website, and which are still drafts? Yonatan's contact is approved; identification of all joint operators is incomplete.
If several people jointly operate the service, describe the division of work (hosting, development, user requests, moderation): Ben owns the hosting account. Yonatan handles requests, technical exports/deletions and complaints. All four decide jointly; remaining operation/access duties need a written allocation.
| Information | Your answer |
|---|---|
| Current public website URL(s) | One service confirmed. Exact current URL: UNKNOWN; verify deployment rather than guessing from repository configuration. |
| Is the site already used with real accounts/grades? Approximate user count? | UNKNOWN — operator says “not really”; this is not confirmation of zero real accounts or grades. Verify with the team without copying user data here. |
| Team size: the existing notes say four people; is that correct? | Yes |
| Any fees, advertising, affiliate links, donations, sponsorship or planned monetisation? | NO |
| Intended audience; are users under 18 expected? | University students; under-18 users are not specifically targeted but can use the site. Actual ages: UNKNOWN. No adult-content offering reported. Do not infer a need for identity checks or that age-related privacy questions are settled. |
| Is the ChatGPT/Claude/MCP catalog integration publicly available and still wanted? | UNKNOWN |
| Target date or event for the next release, if any | UNKNOWN |
Write ACCEPT in each row you agree with. You can accept most rows and change
only the ones that matter to you. Legal applicability will still be checked
against the facts; these are product choices, not declarations of compliance.
| ID | Recommendation | Your decision |
|---|---|---|
| D1 | Keep the existing planner, accounts, browser PDF parsing and account deletion. | ACCEPT |
| D2 | Publish concise German privacy/imprint pages; avoid blanket privacy-consent checkboxes. Say if English is also wanted. | ACCEPT |
| D3 | One contact for requests/reports without login or a star rating. | CONFIRMED: Yonatan's email as plain-text (at), no link/helper. |
| D4 | Manual handling, without a new dashboard. | CONFIRMED: Yonatan handles requests and technical exports/deletions; internal absence cover. |
| D5 | Decide whether reviews remain and how reports are handled. | CONFIRMED follow-up: course-experience reviews remain; Yonatan handles reports by email. No new moderation platform or feature removal. |
| D6 | Decide whether custom lecturer-name input should remain; this is separate from database changes. | Database changes rejected. Feature decision: UNKNOWN. Preserve existing input and records pending clarification. |
| D7 | Keep analytics/advertising absent; assess storage individually. | Focused storage cleanup authorized and committed on 10 September; see current privacy notes. |
| D8 | Replace shared/demo administrator privileges with named operators. Keep the existing security protections. | REJECTED (“no”). Do not change privileges under this brief; actual access remains unverified and a security concern to resolve. |
| D9 | Retain minimal diagnostics for troubleshooting; remove usernames from new app error records unless a specific support need is identified. Verify provider logs separately. | UNKNOWN |
| D10 | Keep the current database; verify hosting arrangements without changing them. | Do not change the database. No schema/data changes, new database, swap or migration authorised by this brief. Hosting changes also require a concrete decision. |
| D11 | Keep internal documentation small: processing record plus practical request, moderation, incident and cleanup instructions. | ACCEPT |
Features or behavior that must not change: Preserve the database and existing security controls. Do not infer review removal or administrator changes from ambiguous/rejected answers. Other constraints: UNKNOWN.
Other priorities or decisions: Keep the project simple and make public legal information accurate. Other priorities: UNKNOWN.
Use existing application usernames only, never passwords. Listing an operator does not verify that the account is controlled by that person.
| Information | Your answer |
|---|---|
| App usernames allowed to inspect diagnostics | UNKNOWN — repository currently lists test; this is not verification of intended access. |
| App usernames allowed to moderate reviews | UNKNOWN — current code uses the diagnostics allow-list. |
| Are these individual accounts already created and controlled by the intended operators? | UNKNOWN |
Who currently uses the shared test account? Is it a public demo account? |
UNKNOWN |
What should happen to test? |
No privilege change authorised (D8). Account ownership and safe intended use: UNKNOWN. |
| Who manages Cloudflare and production deployments? Team role/name only. | Ben owns the account; other access/deployment duties remain to be allocated. |
| Is two-factor authentication enabled for hosting administrators? | UNKNOWN |
UNKNOWN is a useful answer here. Do not accept contractual terms just to fill
in this form. The implementer must distinguish repository config from confirmed
account settings and can provide verification steps for anything missing.
| Information | Your answer |
|---|---|
| Cloudflare contracting customer: person or organisation (no account ID needed) | Account in Ben's name; exact contractual identity not independently verified. |
| Cloudflare plan: Free / Paid / UNKNOWN | Free |
| Has the applicable data-processing agreement been confirmed? By whom and when? Public terms link or private evidence reference only. | UNKNOWN |
| Any known region settings, transfer safeguards or related contract evidence? | UNKNOWN |
| Cloudflare Analytics, Web Analytics, Zaraz, Turnstile or other dashboard features enabled? | None reported beyond Pages, Workers and D1. Verify dashboard; repository Workers observability is enabled. |
| Other providers: domain registrar, contact mailbox, monitoring, external backups, etc. | UNKNOWN |
| Logs exported elsewhere or database backups downloaded? Where, who has access, and for how long? Do not include contents. | UNKNOWN |
| Known provider log/backup retention, if checked | UNKNOWN |
The durations below are implementation proposals based on the current app, not legal deadlines. An accepted schedule must also work when nobody visits the site.
| ID | Recommendation / question | Your decision |
|---|---|---|
| R1 | Current app policy: 14 days, maximum 500 diagnostic entries; cleanup depends on requests. Verify effectiveness before promising a maximum duration. | UNKNOWN — proposed policy not accepted; no new deletion authorised. |
| R2 | Current app policy: six calendar months for feedback; cleanup on submission. | UNKNOWN — proposed policy not accepted; no new deletion authorised. |
| R3 | Current app removes stale rate-limit windows on later writes, after roughly one additional day. | UNKNOWN — verify actual cleanup; no new deletion authorised. |
| R4 | Choose a reliable periodic cleanup method when agreeing retention. A daily scheduled job is optional, not a legal requirement. | UNKNOWN — defer implementation; respect the no-database-change instruction. |
| R5 | Keep account/planning data while the account is in use and remove it on deletion. For inactive accounts, what period and warning process would you support? Leave UNKNOWN for a proposal; no automatic account deletion without an agreed rule. | UNKNOWN |
| R6 | Project shutdown: who decides and communicates closure, and how much time should users have to retrieve their data? | UNKNOWN |
Do any of these contain real user data: previous test database, legacy
review_notices, old user tables, local exports, test fixtures? List known
locations and who can verify them; do not include records: UNKNOWN
Any data that must be retained for an existing unresolved request/dispute? State only that a restriction exists and who to contact privately: UNKNOWN
Legacy-data handling recommendation: inventory first and propose precisely scoped cleanup before deleting existing records. Your decision: Do not change/delete database records. Inventory contents and any later cleanup decision remain UNKNOWN.
| Information | Your answer |
|---|---|
| Why are lecturer names/custom lecturer names useful to users? | To plan the semester and know who is teaching which courses. |
| Do you need lecturer emails/contact details, or would names and course associations be enough? | Names and course associations are enough. Operator believes no lecturer emails are held; actual stored/exposed fields: UNKNOWN (schema has an email column). Do not claim absence or delete data without verification. |
| Known ALMA reuse permission, agreement or correspondence? Public link/private reference only; UNKNOWN is fine. | UNKNOWN |
| Have lecturers already been informed about this service, or is there an existing public notice? | UNKNOWN |
| Who handles review reports and lecturer correction/removal requests? | UNKNOWN |
| Where can the team keep a small private request/incident record with restricted access? | UNKNOWN |
Filled in by / date: Operator answers reviewed by the assistant on 8 September 2026. No new recommendation was accepted on the operator's behalf.
Answers still awaiting another team member or account check: Full public operator identity, serviceable address, monitored email, exact URL and real-data usage; Cloudflare customer/terms/features; privileged-account ownership; intended review behavior. Other UNKNOWN items can be investigated during implementation.
Anything else the implementer should know: Keep unresolved facts in this internal brief; never copy UNKNOWN or unsupported “we collect no personal data” claims to the public legal pages. Documentation changes alone do not fix runtime gaps.
Use explicit answers as the implementation brief and refer to decision IDs in
the change summary. Treat TODO/UNKNOWN as unresolved, not as consent to the
recommendation. Continue work that does not depend on missing facts. Do not
invent operator identities, contracts, retention facts or legal conclusions.
Keep private operational details out of public pages and Git. Verify legal and
provider details when implementing. Preserve the existing database and migration
history. Filling this file does not itself deploy the app, authorise bulk deletion,
send messages, or accept provider terms; follow the user's implementation request
and existing repository workflow when the work begins.