Add privacy policy and terms of service drafts - #37
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAdds attorney-review drafts for PrivKey LLC’s Privacy Policy and Terms of Service, coordinated disclosure and safe-harbor guidance, and an internal publication checklist covering data practices, service obligations, payments, intellectual property, liability, termination, and dispute resolution. ChangesLegal documents
Estimated code review effort: 2 (Simple) | ~15 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@legal/privacy-policy.md`:
- Around line 3-8: Finalize the privacy policy before publication by removing
the draft banner and resolving every bracketed placeholder throughout the
document, including dates, vendors, retention periods, contacts,
representatives, tooling, and implementation details. Ensure the resulting
document contains only attorney-approved, publication-ready content with no
unresolved placeholders.
- Around line 22-27: Validate the enforceable commitments in the privacy policy
against production tooling, vendor terms, and deletion workflows, especially the
third-party AI training restriction and minimum-collection/deletion statement.
If operational evidence confirms them, retain the current wording; otherwise,
soften or revise those statements to match verified practices before
publication.
- Around line 111-120: Revise the cookie sections 7.1–7.3 to remove or qualify
unverified claims about analytics consent, the consent banner, cookie settings,
and GPC handling, matching the currently deployed behavior. Do not publish
statements that depend on unimplemented controls; retain only confirmed cookie
practices.
- Around line 234-247: Remove the “Reviewer Checklist — Resolve Before
Publication” section and all ten checklist items from the public privacy policy
content. Preserve the surrounding policy sections, and move or retain these
publication tasks only in an internal checklist or issue tracker so they are not
rendered on /privacy/.
- Around line 124-141: Resolve all bracketed retention durations in the Section
8 “Data Retention” table, including the entries referenced near the Section 9
destruction commitments, only after confirming each period is operationally
enforceable. Align the published schedule with documented deletion ownership,
legal-hold and dispute exceptions, backup handling, secure-destruction
procedures, and certificate-of-destruction evidence; do not promise 30-day
destruction or certificates unless those controls are implemented.
- Around line 197-201: Update Section 13’s breach-notification language to apply
the direct notification commitment only when PrivKey is the controller for the
affected personal data. For business-client processor engagements, state that
notification is made to the applicable client/controller without undue delay,
with the MSA or DPA governing the engagement-specific requirements; remove the
blanket promise of notifying individuals and supervisory authorities within the
GDPR 72-hour window.
- Around line 178-184: Update sections 11.3 “Timing” and 11.5 “Appeals and
complaints” to replace the broad U.S. 45-day wording with jurisdiction-specific
deadlines or an “applicable law” qualifier. Preserve the stated 45-day response
and extension for CCPA/CDPA-like regimes, the one-month GDPR/UK GDPR response
with a two-month extension, and ensure appeal timing is not incorrectly applied
to GDPR requests.
In `@legal/terms-of-service.md`:
- Around line 259-270: Remove the “Reviewer Checklist — Resolve Before
Publication” section from the published Terms, including all eight internal
review items. Ensure the document ends after the Contact section and does not
expose drafting or publication workflow content.
- Line 74: Update the key-material handling language in section 5.1 to match the
mandatory process in the Privacy Policy: state that PrivKey will delete
accidentally submitted private keys, seed phrases, or key shares and notify the
sender to rotate them, while retaining the existing responsibility and liability
statements.
- Around line 18-20: Revise the acceptance language in the Terms section so it
does not treat mere Site access as acceptance without an affirmative flow.
Either add a click-to-accept or scroll-to-accept mechanism that records the
accepted Terms version and date, or narrow the stated acceptance scope to
Services engagements covered by signed agreements.
- Around line 3-7: Finalize legal/terms-of-service.md by replacing every
bracketed placeholder with attorney-confirmed values and removing the draft
banner after approval: lines 3-7 for status and dates, 14 for formation state,
102-104 for payment terms, 110 for refund currency, 138 for confidentiality
survival, 154 for liability limits, 160 for claim limitation, 194-196 for
termination terms, 210 for arbitration panel size, 218 for the opt-out, 226 for
non-solicitation, 234 for legal notices, and 249-254 for the mailing address and
contact emails.
- Around line 34-54: Align the key-management service descriptions with the
non-custody representations in sections 4.1 and 5.1. After confirming the actual
workflow with counsel, either constrain the “Multisig Concierge Services” and
“Private key management advisory” entries to advisory/configuration assistance
that never involves possession or control, or update the corresponding
non-custody language consistently; preserve the SOW-based scope limitation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a85a7e78-93cf-469e-874f-f732f62b7566
📒 Files selected for processing (2)
legal/privacy-policy.mdlegal/terms-of-service.md
kwsantiago
left a comment
kwsantiago
left a comment
There was a problem hiding this comment.
Audit of the drafts against this repo and the live site. I skipped anything CodeRabbit already covered (placeholders, consent banner and GPC, retention schedule, response deadlines, the controller/processor split in Section 13, checklist removal before publication, click-to-accept, and key-material handling). Everything below is a mismatch with code or config in this repo, which is the class of problem an attorney review will not catch.
Inline comments cover: Miami vs Tampa, cookie and automatic-collection claims that the code contradicts, the empty subprocessor table (fillable from the code today), unverified Section 12 security controls, the researcher safe harbor conflict across three documents, unconfirmed email aliases, the MIT license conflict with ToS 9.1 and 15, uncapped confidentiality liability in 12.3, the service list outrunning what the site sells, and the survival list.
Three that do not anchor to a line in this diff:
1. Closes #36 will auto-close an issue that is one fifth done. #36 has five acceptance items: attorney approval with no remaining brackets, HTML pages at /privacy/ and /terms/, footer links, sitemap entries, and effective dates. This PR delivers the drafts. On merge the issue closes and the publication work goes quiet. Suggest Refs #36.
2. The contact form has no notice at collection. index.html:298 collects name, email, referral source, and free text with no privacy link anywhere near it. CCPA/CPRA requires notice at or before collection and GDPR Art. 13 likewise; a footer link alone does not cover it. Worth folding into the #36 publication work.
3. Delivery format. .md files under legal/ will not render as pages on a static host reading _headers; they serve as raw text or a download. Fine as a staging step since #36 already calls for HTML at /privacy/ and /terms/, just do not link to the .md paths. Related: privkey.io/subprocessors and privkey.io/pgp are both referenced and neither exists.
Drafting quality is high. The gaps are all in the seam between the documents and the deployed site.
|
Resolved
Deliberately not changed
Placeholders and the DRAFT banner stay until the attorney pass. Both files are still drafts and neither is linked from the Site. |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
legal/PUBLICATION-CHECKLIST.md (1)
1-5: 🔒 Security & Privacy | 🔵 TrivialVerify that the internal checklist is excluded from public artifacts.
The warning is documentation only. Confirm the site build and deployment configuration cannot publish
legal/PUBLICATION-CHECKLIST.mdor expose it as a raw public document.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@legal/PUBLICATION-CHECKLIST.md` around lines 1 - 5, Verify the site build and deployment configuration excludes legal/PUBLICATION-CHECKLIST.md from generated and deployed public artifacts, including direct raw-document access. Update the relevant inclusion, copy, or routing configuration if the checklist could currently be published, while preserving publication of privacy-policy.md and terms-of-service.md.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@legal/PUBLICATION-CHECKLIST.md`:
- Line 16: Update the checklist entry describing rights-request monitoring to
avoid presenting 45 days as a universal deadline. Record the applicable
jurisdiction and request type, distinguishing California’s 45-day period from
the generally one-month GDPR period, while preserving the existing mailbox
monitoring guidance.
- Line 52: Update the Section 9.1.1 checklist guidance to limit MIT-license
conclusions to repository source code and associated documentation actually
covered by that license. Explicitly distinguish those materials from website
content, policies, branding, fonts, images, and third-party works, which require
separate rights analysis.
In `@legal/terms-of-service.md`:
- Line 220: Update the Survival clause in Section 17.5 to replace the incorrect
“6 (indemnity)” label with the correct description for Section 6, while
preserving the existing section list and survival language.
In `@SECURITY.md`:
- Around line 17-21: Revise the safe-harbor language around “Research conducted
in good faith” to limit authorization to explicitly named in-scope assets and an
approved written Rules of Engagement, referencing the policy’s required
authorization process. Ensure activities outside that scope, including testing
beyond passive or reporting actions, require prior written authorization, and
align the third-party claim statement with the same constrained scope.
---
Nitpick comments:
In `@legal/PUBLICATION-CHECKLIST.md`:
- Around line 1-5: Verify the site build and deployment configuration excludes
legal/PUBLICATION-CHECKLIST.md from generated and deployed public artifacts,
including direct raw-document access. Update the relevant inclusion, copy, or
routing configuration if the checklist could currently be published, while
preserving publication of privacy-policy.md and terms-of-service.md.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f7768d30-f026-4170-92c3-524337a02306
📒 Files selected for processing (4)
SECURITY.mdlegal/PUBLICATION-CHECKLIST.mdlegal/privacy-policy.mdlegal/terms-of-service.md
…t payments accepted
…rve-out, fix survival label
|
@wksantiago handoff: state of play after the review passes. Where this stands. Three commits on top of your drafts ( The single source for what remains is Decisions already made (by Kyle, 2026-07-27):
Decision/ops items that block the attorney pass: items 3 (street address, state of formation), 4, 12-13 (retention durations and the 30-day destruction window), 14, 21, 23. None need a lawyer to answer. Counsel items: 1 (full pass, resolve every bracket), 17 (Art. 27 reps), 18 (DPA/SCC package), 24 (arbitration and class waiver vs consumer customers), 25 (E&O/cyber coverage vs the cap AND the uncapped exceptions), 28 (bracketed periods). Site work, part of #36 rather than this PR: HTML pages at /privacy/ and /terms/, footer links, sitemap entries, a notice-at-collection link beside the contact form (item 20), click-to-accept (29), and optionally self-hosting the web font to kill the Google Fonts IP disclosure (11). On merging: the PR is currently a draft, so CodeRabbit is skipping it. It is merge-safe as-is since nothing publishes; marking it ready triggers CodeRabbit's final pass. The body now says |
|
@wksantiago answering "what is mine and what is for the attorney," because the honest answer is that most of the brackets are ours, not the attorney's. A lawyer cannot tell us how long we keep scan output, which CRM we use, or what our payment terms are. They review the answers we supply. Handing the drafts over with the brackets empty buys an expensive round trip and a lawyer guessing at our operations.
Group A, ours and only we know it (~35 brackets). Vendor names in the Privacy Policy 5.1 tables, every retention duration in Section 8, the 30-day destruction window, which encrypted channel we actually use for deliverables, whether our AI tool contracts really prohibit training on our input, the eleven security controls in Section 12 (yes or no on each, strike what is not in place), the hosting provider's log fields, the Group B, ours to pick and counsel sanity-checks (~17 brackets). The commercial numbers: net 30 payment terms, 1.5% late interest, the 15-day suspension trigger, 5-year confidentiality survival, the 12-month liability cap basis, the $100 free-use cap, the 1-year claim limit, cure and notice periods, the 12-month non-solicit. We choose because it is our business; counsel confirms it is enforceable and market-standard. Group C, genuinely theirs (~8). Whether we need EU and UK Article 27 representatives. The SCC and DPA package. Whether the arbitration clause and class action waiver survive against individual training customers, and whether we need the 30-day opt-out. Whether the caps, disclaimers, and indemnities hold up under Florida law. Plus the final pass over our Group A and B answers. So: yes, the list in my earlier comment is ours to answer, not the attorney's. Work Group A and B first, then send the documents over. The ToS 12.3 confidentiality cap is the one item that is really a three-way conversation, and the third party is the insurer rather than the lawyer. Also in |
|
@kwsantiago latest push ( Completed
Pending your review / decision if any and send to counsel
Full tracking in |
|
@kwsantiago pushed Verified against the filed 2026 annual report (doc L18000284183):
Heads-up (no doc change needed): the 2026 report lists the principal place of business, mailing address, and registered agent as the RA's suite — 7901 4th St N Ste 300, St. Petersburg, FL 33702 (Registered Agents Inc) — not our Tampa address. You confirmed Tampa (8710 N Renfrew Pl) is the real operating address, so all docs + JSON-LD stay Tampa and arbitration stays Hillsborough County. Action for next filing: correct the PPB/mailing back to Tampa on the 2027 annual report (due by May 1, 2027) so the public record matches — if Registered Agents Inc files it for you, tell them to use the Tampa address, not theirs. Added to the docs so we don't need yearly edits: a Sunbiz pointer in ToS §1 and a Tracking in |
|
@wksantiago reviewed both commits line by line. Good calls in there, particularly deleting §12.5 (Fla. Stat. §95.03 does void a sub-one-year contractual limitations period, and the agreement is Florida-governed and Florida-seated, so it was dead weight), attesting §12 per control and actually striking monitored logging, background checks, and annual training rather than keeping them, and rewording FDE to file-level encryption because Cryptomator is file-level. Four things the pass introduced or left behind. Three are fixed in FixedKey material contradiction. PP 8 gained a row for Sanctions screening described in four places after the vendor row was struck. You struck the 5.1 row as "we don't screen today," but PP 3.1 still listed screening results as collected, 3.3 listed them as received from third parties, 4 gave them a legal basis, and 8 kept a 5-year retention row. Same shape as the cookie problem: the policy described a practice we do not have. All four are now explicitly conditional and point at ToS 14's "may conduct" reservation, so the reserved right survives without claiming we exercise it. Log wording. PP 3.2 said the logs are "used for security, abuse detection, and troubleshooting" immediately before the new sentence saying GitHub does not expose them to us. Reworded so the provider is the one holding and using them. Needs your decisionPP 8 assessment-report retention, 12 months, now conflicts with the liability window. The same pass that cut reports from 3 years to 12 months also deleted §12.5. Deleting §12.5 was right, but it restores Florida's 5-year written-contract SOL, so exposure got longer in the same commit that made evidence retention shorter. PP 9 "Findings retention" still says we keep the report "to defend against claims." At 12 months the report is destroyed with roughly 4 years of claim window left, and we would be defending a claim about an assessment whose report we deleted. There is also a row overlap: a delivered report is arguably "engagement records and correspondence" at term + 7 years, so two rows plausibly cover the same PDF with a 6-year gap between them. Three ways out, all yours to pick:
Tracked at the top of the Still Open section in SeparatelyConfirming GitHub Pages as the host surfaced that |
2 participants
Refs #36
Summary by CodeRabbit