Finding Internships Privacy Policy
App Privacy Terms

Effective October 15, 2026

Privacy Policy

Finding Internships publishes normalized internship listings and helps signed-in users track applications, find public professional profiles, prepare personalized outreach, send user-approved emails, maintain a Google Sheets CRM, and detect replies. This policy explains what data the application handles and how it is protected.

Information the application handles

  • Job listing information: public internship data such as company, title, location, category, posting date, description, and source URL supplied by the Internship Tracker publisher.
  • Application tracking information: the jobs you save, application stages you select, optional notes, one-time legacy tracker imports, and links between jobs and outreach prospects. This information is scoped to your signed-in account. Jobs you manually add include your entered company, title, optional posting URL/location, stage and notes. They are private tracker records, not public catalog submissions. Pasting a URL does not trigger an automatic fetch, extraction or provider call.
  • Private-beta access information: when the beta gate is enabled, a verified Google email address, Google account subject identifier where retained, request status, and request timestamps. Current denials retain the subject to enforce account restrictions; older decisions may have cleared it. Ordinary signup with email verification enabled does not need owner approval. If an owner explicitly chooses an acceptance notice for a future new approval, the app sends a fixed access email using that approving owner's connected Gmail, not the applicant's account. The recipient, approval revision, sender account, notification state, attempt/sent timestamps and Gmail message identifier are retained for duplicate prevention and owner-visible recovery. No outreach text or attachments are included, and existing approved entries are not emailed retroactively.
  • Legacy Google signup email verification, when enabled: new signups confirm an additional emailed link after Google identity validation. The application stores the server-verified Google subject and email, a pending browser binding, token/CSRF hashes, expiry/consumption times, and bounded delivery status/attempt identifiers. Raw email-link tokens are not stored in the database or application browser storage. Existing registered user identities are exempted once at activation; approved email invitations alone do not create that exemption. Opening a link or refreshing status cannot sign a browser in. Explicit confirmation in the original Google-bound signup browser can create the normal session and open the workspace without owner approval. Already-confirmed applicants can also use Google sign-in. Account restrictions remain enforced; ordinary admission grants no owner permissions or Google service/outreach consent. Pending verification is not workspace access.
  • Clerk authentication, when selected: Clerk manages the configured sign-in methods and verification. The application checks your verified primary email, identity and active session, and stores an issuer/identity mapping and session binding to your internal workspace ID. Application code does not write raw Clerk tokens to application tables or local/session storage; Clerk manages its authentication cookies. A matching email alone does not transfer an existing Google workspace; verified Google ownership is required to link it. Google sign-in through Clerk does not send the legacy additional signup-link email. Configured email-code sign-in still requires code entry or supported autofill.
  • Google account information: your Google account identifier, email address, name, and profile image when available.
  • Gmail data: authorization to send messages you explicitly approve and limited access needed to identify replies to outreach sent through the application. The application may store Gmail message or thread identifiers, reply timestamps, sender addresses, and short reply snippets.
  • Google Sheets and Drive data: authorization to create and update the Finding Internships CRM spreadsheet in your Google account.
  • Outreach information: search criteria, public professional-profile results, email addresses, drafts, approval statuses, sending history, and the personal context you choose to provide for drafting. Approved preparation also stores bounded public source links/snippets, lookup provider and outcome, match/email status, and attempt timestamps alongside the owned contact. Raw enrichment responses, phone numbers, and personal-email reveal results are not stored.
  • Provider credentials: API keys you choose to add for services such as Tavily, Hunter, Gemini, OpenAI, or Anthropic. Optional Apollo credentials cannot be added until the server's integration-authorization gate is enabled.
  • Resume data: a resume file you choose to upload and the factual profile information extracted from it for your review.
  • Tutorial progress: the optional tutorial's status, current step, version, revision, and last-save time, stored for your authenticated account so you can resume across devices. It contains no API keys, profile text, resume contents, or outreach data.
  • Security and operational records: session, rate-limit, request, and audit records used to operate and secure the service, provide your account-scoped activity view, and support restricted owner operational-activity administration. Secrets and message bodies are not intentionally written to application logs.

How information is used

Information is used only to provide the features you request:

  • authenticate you and keep each user's workspace separate;
  • remember optional tutorial progress, skipping, and completion;
  • admit verified ordinary signups and let configured owners manage invitations, denials, revocation and explicit access restoration;
  • publish and filter current internship listings;
  • save jobs and synchronize your private application pipeline;
  • find public professional-profile results;
  • enrich contact information and generate drafts;
  • analyze an uploaded resume, populate profile suggestions, and attach the resume only when you select that option for a specific email;
  • send only the exact emails you approve;
  • create and update your CRM spreadsheet;
  • detect replies and update outreach status; and
  • show account-scoped application, networking, company, and recent activity counts calculated from your existing records;
  • let configured owners administer the beta using basic registered account identifiers and limited operational event summaries;
  • prevent abuse, duplicate sends, and unauthorized access.

Google API data

Finding Internships's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is not used for advertising, sold, or used to train general-purpose AI models by Finding Internships.

Third-party services

The application uses Cloudflare to host the service and store application data. A separate Internship Tracker publisher sends signed, normalized public job snapshots to an internal ingestion endpoint. Adzuna-sourced adverts display a self-hosted official attribution image; the image does not cause the browser to contact Adzuna. Opening the attribution or a source job link navigates to the relevant external site under that site's privacy policy. When you activate a feature, the minimum necessary information is sent to the relevant provider: Clerk for authentication when selected; Google for legacy authentication or separately connected Gmail, Drive, and Sheets; Tavily for public-web discovery; Hunter for email enrichment; and your selected AI provider for drafting or resume analysis. When legacy signup email verification is enabled, Resend receives only the server-verified recipient and the verification message/link from the application's verified sender domain. It does not receive resumes, outreach drafts, workspace content or user provider credentials for this security email. This is separate from optional owner-sent Gmail beta acceptance notices, which automatic signup does not queue; no marketing, open tracking or click tracking is introduced by this feature. PDF resume analysis uses the user's configured Gemini credential. If you explicitly click Find more with AI using Gemini, OpenAI, or Anthropic, the application may send only public job-networking criteria (company, professional role/topics, location, approved source domains, and result count) to that selected provider using your encrypted provider key and configured model. It does not send your profile, resume, email, drafts, personal context, or credentials in that prompt. Only one provider is called per explicit AI action, without rerunning Tavily, and direct source citations are required. Search and ordinary Retry use Tavily only; a shortfall never triggers AI automatically. Those providers process information under their own terms and privacy policies.

After explicit contact approval, an authorized and selected Apollo integration receives only public identity needed for an ordinary work-email lookup: name, employer/domain and LinkedIn URL. It does not receive your resume, background, private drafts or Google data. Apollo is server-disabled pending provider authorization of this product and its authentication model; a saved key cannot authorize integration. No phone or personal-email reveal, waterfall lookup, Apollo people search or automatic Hunter fallback is used.

Approved-person research sends only that person's public name and employer to one bounded Tavily search. Matched public professional evidence and your factual saved profile/experience are sent to your selected drafting model, without recipient email or credentials in the prompt. Resume suggestions contribute only after you review and save them as profile facts. Sources are treated as untrusted information, shown in draft review rather than automatically cited inside emails. Regeneration reuses recorded email/research outcomes and does not repeat those provider calls; failed stages require explicit retries. Operational events contain only stage/provider categories and counts, not recipient addresses or research bodies. Source caches follow the contact's existing retention/deletion handling, not a new expiry promise.

The Analytics page and owner activity dashboard do not use a third-party analytics or advertising service. The personal Analytics page runs bounded, account-scoped queries over records already stored to provide the workspace. Decorative interface crops and the Three.js Career Journey runtime are self-hosted and do not contact an image-generation service or runtime CDN.

Bug reports you choose to share

Signed-in beta members can submit a summary, description and safe page label to a private owner inbox. Your basic account name and email identify the reporter. The app does not automatically attach outreach content, credentials, raw errors, search criteria or URL/OAuth tokens. Do not put passwords, API keys or private email contents into a report.

Only configured owners can read reports and mark them open or resolved. Reports persist for support across reloads; resolving is not deletion. Reports are removed when the associated account is deleted. No report email notifications or additional visit tracking are introduced.

Usage analytics and account activity

Limited recorded actions are linked to your account and can be associated with your name and email address. Configured owners can use these records to understand use of the existing job, application, People and outreach features, and to administer and support the beta. Your own Analytics page shows account-scoped counts and activity, not other members' records.

Only owners configured in the server's beta-administrator allowlist can access the owner dashboard. It shows non-deleted registered accounts' names, email addresses, account identifiers and registration times, recorded action counts, and a paginated feed of event types and timestamps for a selected recent 7- or 28-day period. Examples include people searches, job saves, application changes, draft actions, sends, and beta-access decisions. Where already recorded, only allowlisted search-fallback provider, outcome and error-reason categories are shown. This view does not expose API keys or key hints, tokens or session hashes, resumes, private profile text, draft or email bodies, recipient details, search queries, raw provider responses, or raw audit metadata.

The dashboard adds no pageview tracking, keystroke or screen recording, browser fingerprinting, or live polling. Recorded events are not visits or exact login times. Background work is not evidence that a user was online, and the dashboard does not infer live presence or session duration. No events in a selected period means only that no activity was recorded in that period, not that the account was never used. Not every operation or failure is recorded; historical activity is not reconstructed. Ordinary users cannot access other accounts' owner-dashboard records.

There is no separate in-app opt-out for these operational records. For privacy questions or a verified account-data deletion request, use the contact and deletion process described below. The 7- and 28-day display windows do not mean records are automatically deleted.

Storage and security

  • Traffic is encrypted in transit using HTTPS.
  • User API keys and Google refresh tokens are encrypted using AES-256-GCM before being stored in Cloudflare D1.
  • Resume files are encrypted using AES-256-GCM before being stored in segmented Cloudflare D1 records.
  • The master encryption key is stored separately as a Cloudflare Worker secret.
  • Credential encryption is bound to the user, credential type, and provider.
  • Plaintext credentials are not returned to the browser after they are saved.
  • Session tokens are stored server-side as cryptographic hashes, and security controls include secure cookies, CSRF protection, same-origin checks, rate limits, and restrictive browser headers.

No online service can guarantee absolute security. Users should protect their Google and provider accounts with strong passwords and multi-factor authentication.

Retention and deletion

The owner dashboard's 7- and 28-day display windows are query limits, not deletion schedules. Audit records do not currently have a fixed automatic expiry. Existing retention and verified deletion handling below still apply; this dashboard creates no new retention guarantee.

Data is retained while needed to provide the service and maintain the user's application and outreach history. Job listings that disappear from a publisher snapshot are marked inactive; a signed-in user's state may retain a reference so their history remains understandable. Provider API keys and uploaded resumes can be deleted in the application's Settings page. Google access can be revoked through Google Account permissions. To request deletion of your account data, encrypted credentials, Google token, tutorial progress, saved jobs, application states, prospects, drafts, and audit records (including private user-added jobs and their role links, signup verification records and any legacy-verification exemption), email evanastonlowe@gmail.com from the verified sign-in email associated with the workspace. Verified deletion requests will be completed within 30 days unless retention is required by law or for security purposes.

Pending or denied beta-access requests may be retained long enough to avoid duplicate active requests, support review, and prevent abuse. A requester may use the same contact address to request deletion.

Legacy signup email links expire within 30 minutes and pending signup browser state after one hour. When verification is enabled, routine maintenance removes pending challenge records more than 24 hours after their expiry. Stale unverified identity records with no remaining challenge or account are also removed after that cleanup window. The subject/email proof and fixed legacy exemption remain while needed for account access and security; they do not automatically expire with the pending link. Account deletion also removes those linked proof records. Resend's own delivery/security metadata is subject to its service policy.

Sharing and sale of data

Personal information and Google user data are not sold. Information is shared only with service providers needed to perform a feature you request, when required by law, or when necessary to protect users and the service.

Children's privacy

The service is not directed to children under 13, and it is not intended to knowingly collect personal information from children.

Changes and contact

This policy may be updated as the service changes. Material revisions will be reflected by the effective date above. Questions and privacy requests can be sent to evanastonlowe@gmail.com.