Privacy Statement

[thehabes]

Closes #474

This prompted an audit to find places where TPEN Services and TPEN Interfaces may expose an E-mail address. Any endpoint where E-mail strings end up as part of a response body, and anywhere Interfaces may know the E-mail enough to where the code could expose it.

This audit was performed by Claude Code, and only performed once just as a general "let's see what we find". For an exhaustive list more effort is required.

Interfaces main branch audit

Services development branch audit

[github-actions]

🚀 Deployed on https://69961c4a50dac10f5c6ea762--tpen-interfaces-preview.netlify.app

[cubap]

"Published Project Resources" is probably more clear, since it may not just be Manifests and is always a thing we create for a specific project.

[cubap]

This feels like a table layout would be tidier.

[cubap]

Should this whole thing be a markdown file on three.t-pen.org? It doesn't feel like an interface.

[cubap]

It might be worth rephrasing this as Auth0 is the identity provider for Rerum services, which this is one of. The public agent IRI is created and associated with the login token. T-PEN.org does not display or share user emails through its services.

[cubap]

Display name is generated from your email handle by default so if it is not changed it might be usable for some identifying mark.

[cubap]

More than "optional" this is all opt-in sharing with other TPEN Users.

[cubap]

is it worth saying that they URLs are obscure but openly available?

[cubap]

Also the downloaded resources and idToken, if this is the place for that.

[cubap]

(linked to your public Agent)

[cubap]

Do we collect this or just send the emails? I thought we had an "invite code" to reconnect these later?

[cubap]

This isn't a data collection thing.

[cubap]

"per User metrics" is maybe more specific?

[cubap]

These aren't saved on the server or even sent through the Internet, so I don't think we need to claim them.

[cubap]

This is a GitHub submission, as we state above, so I don't think this is User Information.

[cubap]

I would link rerum.io, as a user-facing site rather than store.rerum.io, which would be confusing.

[cubap]

I don't think it is available to the interfaces at all, which maybe is worth noting.

[cubap]

No user information at all is included in the reports. Only what they type and where they came from.

[cubap]

"public user agent"

[cubap]

Not quite. We use a mailrelay server, so SLU only sees the address because it isn't encrypted (as far as I know). There is an option for secure mail which we might be using. Point is, I don't think this needs to be disclosed other than to say it is only used for sending invites and is not stored for any purpose.

[cubap]

Do we really have Chota in the TPEN stack somewhere? I bet we can take that out.

[cubap]

I think libraries used inside of interfaces can be handwaved to say that TPEN3 is built on modular interfaces that we do not completely control and may call on libraries and frameworks served over CDNs.

[cubap]

I'll have to find this one...

[cubap]

I would get rid of IIIF language here. It is the case for all Internet Resources, specifically images and manifest documents.

[cubap]

IS this true? I think we just get rid of the token.

[cubap]

delete

[cubap]

This is so minimal I would not keep restating it.

[cubap]

"browser history"

[cubap]

I wouldn't make this promise, since we do not have a good way to notify people.

[cubap]

again, maybe not, but it could be

[cubap]

We should ticket this as a simple report we can just run on someone so they can click on their own.

[cubap]

same as above

[cubap]

maybe just say that all public information is editable by the user.

[cubap]

maybe just the organization page here?

[cubap]

delete.

[thehabes]

Thanks for the thorough review! All comments have been addressed. Here's the breakdown:

---

Section 1 — Who We Are

• "Published Project Resources" — Changed from "Published project manifests." Updated matching references in Sections 4A and 5D too.
• Table layout — Converted the services bullet list to a Domain / Purpose table.

Section 2 — Information We Collect

• Auth0 / RERUM identity provider — Rewrote using your suggested framing: Auth0 is the identity provider for RERUM services, public agent IRI is created and associated with the login token, T-PEN.org does not display or share user emails through its services.
• "Opt-in" not "Optional" — Heading now reads "Profile Information (Opt-In)." Body says "opt in to sharing … with other TPEN users."
• Display name from email handle — Added note: "defaults to your email handle and may be identifying if not changed."
• Downloaded resources & idToken — Added a "Cached resources" bullet covering downloaded resources (images, manifest documents) and the idToken in localStorage.
• "(linked to your public Agent)" — Added to the project membership bullet.
• Invite emails — collect or just send? — Confirmed the invited email IS stored in MongoDB as a temporary user record. Rephrased to: "stored to connect invite codes to temporary accounts until the invitee accepts."
• Project modification timestamps — Removed. Not a data collection item.
• "per User metrics" — Changed from "limited activity metrics."

Section 3 — How We Use Your Information

• Auto-save drafts row — Removed from table. Drafts never leave the browser; already disclosed in Section 6B (Local Storage).
• Feedback / bug reports row — Removed from table. This is a GitHub submission; already covered in Section 4C.

Section 4 — Information Sharing

• Link rerum.io not store.rerum.io — Done.
• URLs obscure but openly available — Added: "These URLs are obscure but openly available to anyone with the direct link."
• Email not available to interfaces — Now reads: "Email addresses are not available to the TPEN interfaces at all and are only used server-side for sending invitations."
• No user info in feedback reports — Simplified to: "No user information is included in the report — only what you type and the page URL you submitted from."
• "public user agent" — Replaced "user agent identifiers" / "user agent IRI" throughout (Sections 3, 4A, 5B, 8B).

Section 5 — Third-Party Services

• Email delivery → mailrelay — Now says emails go through a "mailrelay server at Saint Louis University" and the address "is only used for sending the invitation and is not stored by the mail service for any other purpose."
• CDN table → general statement — Replaced the 11-row table with: "TPEN3 is built on modular interfaces that may load libraries and frameworks served over third-party CDNs (such as jsDelivr, Cloudflare, Skypack, and unpkg)." Google Fonts is still named with a privacy policy link.
• Chota CSS — Confirmed still in use (css/index.css imports from unpkg). Covered by the general statement.
• Lucid diagram — Confirmed still in use (quick-guide.html). Covered by the general statement.
• Drop IIIF language — Section renamed to "External Resource Servers." Rephrased to "manifest documents" and "images." Cleaned up remaining IIIF references in Sections 2C and 2F.

Section 6 — Cookies & Local Storage

• Logout only removes the token — Confirmed: TPEN.logout() only calls localStorage.removeItem("userToken"). Fixed the false claim in Section 6C and 8C. Corrected Duration columns in the localStorage table for drafts, vault cache, and tpen_redirected.
• "What We Do Not Use" subsection — Deleted entirely.

Section 7 — Security

• Secure cookie attributes bullet — Removed. Already stated in the cookie table.
• "browser history" — Changed from "browser URL."
• Breach notification — Softened to: "we will make reasonable efforts to notify affected users and relevant authorities in accordance with GDPR and applicable US state regulations."

Section 8 — Data Retention

• Local storage retention — Corrected to: "Your authentication token is removed from browser storage when you log out. Cached resources and transcription drafts may persist until cleared manually or by your browser."

Sections 9–10 — GDPR / CCPA Rights

• Self-service data report — Noted for a future ticket. Leaving language as-is for now.
• Right to Correct — Simplified to: "All public information is editable by you through your profile settings."

Section 13 — Changes & Contact

• "About TPEN" link — Removed.
• GitHub link → org page — Now links to github.com/CenterForDigitalHumanities instead of the specific repo.

Meta

• Move to three.t-pen.org? — Agreed this isn't really an interface. Keeping it here to finish the review cycle; will migrate afterward.

[thehabes]

The claim "Email addresses are not available to the TPEN interfaces at all" is incorrect. The interfaces can and do access emails in these cases:

1. Your own email — shown to you on your profile page
2. Collaborator emails as fallback names — shown on the manage page when a member has no display name set
3. Invitee's own email — shown on the decline-invitation page
4. Legacy import emails — shown to the owner during TPEN 2.8 import

Would you like me to correct lines 215 and 340 in privacy.html to reflect this? The manage page fallback (#2) is the most notable — it means other project members can potentially see your email.

It does seem like Classes may be able to get to that information, in which case it could be shown by an interface. I am not sure where the API will respond with those E-mail addresses, but essentially if TPEN Services returns it as part of a response an interface can pick it up.

[cubap]

Okay.

Chota CSS — Confirmed still in use (css/index.css imports from unpkg). Covered by the general statement.
Lucid diagram — Confirmed still in use (quick-guide.html). Covered by the general statement.

These are on their way out, so we can remove them from the specific call-outs.

RE:Emails — I think we should outline how we use these more clearly. TPEN doesn't store them (except invites) but they are encoded in the Rerum User payload from Auth0 so any application you are authenticated with will be able to see it. When you invite another user, they see the email and not just the user from which the invite was sent (maybe we don't need to do that). I think we definitly don't need to show the email as a fallback if there is no displayName, as we already say the handle could be used. We should just show the pre-@ bit in that case.