Privacy notice
Who is responsible
MDShare, operated by a sole trader based in Portugal, is responsible for the processing described here. For privacy questions and rights requests, contact hello@mdshare.online. Do not send share passwords or document content.
We process the data needed to deliver shares, authenticate subscribers and manage billing to perform our contract with you. We rely on legitimate interests to protect the service, enforce security and rate limits, measure visits with cookieless analytics, and respond to correspondence. We process data to meet legal obligations where applicable. You need not create an account to share; account email and billing information are required if you choose to sign in or purchase. We do not make automated decisions producing legal or similarly significant effects about you.
Documents and share records
We store the share payload, link identifier, owner account id for signed-in shares, file count and size, creation and access times, view count, expiry and burn status, a hash of the edit code, and any legal-removal timestamp and private reason. The payload includes file names and text. Password-protected payloads are encrypted in the browser; unprotected payloads are stored unencrypted. We store and return content, but do not read, scan, filter, log or decrypt it for our own purposes.
Optional password hints are public to anyone with the link. New protected shares also store an independently derived password-check hash and public salt, a bounded ledger of recent attempts using keyed IP hashes and times, a revision and UTC-day attempt counters. The password itself, content key and protected plaintext never leave the browser. A derived check is sent for creation, protected saves and checked burn claims; a stolen check can authorize a claim but cannot decrypt content by itself. It can help someone guess the password offline; a weak password can then expose the encrypted document.
Share records include a server-only keyed creator IP hash. These hashes are pseudonymous personal data, not anonymous data. The application does not store raw IP addresses in its share or limiter tables. Some older shares retain older unkeyed hashes until those shares are deleted. Hosting providers still receive network information needed to deliver requests.
Expiry denies access immediately; an expired or burned share is deleted by the daily 03:00 UTC cleanup job. A legal-removal marker alone does not delete the row: it remains until ordinary expiry, burn cleanup or authorized deletion. A never-expiring share can otherwise remain indefinitely. The password-check fields and creator hash live with the share; recent attempt entries are pruned as new attempts are processed, not by a separate guaranteed deletion timer.
Creation history and security limits
The creation log stores a random record id, keyed IP hash, account id if signed in, creation time and an import flag. It contains no share link or document content. It counts creations independently of whether shares are later deleted, burned or expired. A daily 03:15 UTC job deletes records older than 31 days, so deletion can lag that age until the job runs.
Short-term write limits use Postgres records containing an operation-scoped keyed hash, operation name, remaining budget and window/expiry times. They do not contain the original IP, original IP hash, share link or content. Fixed-window records expire at their window end; creation buckets expire when full again, at most two hours after their last refill. Expired limiter rows are purged every minute. Sign-in limits also use keyed IP and keyed normalized-email scopes with one-hour windows, not plaintext email in the limiter table. Billing requests use a keyed account-id scope shared by Checkout and the portal, limited to 20 requests per minute.
Application diagnostics include error details and fixed reason codes, never share content, passwords or raw IPs. Hosting address records are separate, as described below.
Accounts and payment records
Sign-in uses Supabase Auth with your email address and account id, through an email link or Google or GitHub when enabled. Supabase Auth also stores the session IP address and user agent as seen by its service; these may reflect the server or forwarded network details, not just the browser connection. If you choose Google or GitHub, Supabase stores provider identity/profile data such as name, avatar, username and provider id. Resend delivers sign-in emails through Supabase SMTP and subscription-lapse notices through its email API. Account records remain while the account exists; there is no automatic inactive-account purge.
For Supabase Auth, Write audit logs to the database is off: authentication audit entries are not stored in auth.audit_log_entries. Sign-in audit logs, which may include email addresses, stay only in Supabase’s platform logs for the plan’s log window: 1 day on Free or 7 days on Pro, at most 7 days. Account deletion does not immediately erase platform logs.
Stripe and Link receive the identity, billing and payment information needed for Managed Payments, subscriptions, receipts and their legal obligations, under their own notices. Link is part of every Managed Payments checkout, including guest checkout, not an optional MDShare processor. MDShare receives customer and subscription identifiers and billing status, not full card details.
Local billing records hold the account/customer mapping, checkout reservation and immutable first-checkout email, subscription and event identifiers, status, plan and billing dates, and event/refund history. These billing records are kept while the account exists and deleted with it; there is no separate timed purge. Stripe and Link keep their own financial records under their terms and legal obligations, which may continue after a refund or account deletion.
Providers, request logs and analytics
Supabase hosts the primary database in Paris, France, and provides authentication. Vercel hosts the application and its requests. Resend delivers sign-in emails and lapse notices. These providers process data for the service; Stripe and Link, and Google or GitHub if you choose those sign-in methods, also process data as independent controllers under their own notices. A database location does not mean every provider operation or recipient is confined to the EU. International transfers use applicable adequacy decisions or standard contractual clauses where required; provider terms and privacy notices describe their safeguards and retention.
Cloudflare Email Routing forwards mail sent to hello@mdshare.online to the owner’s inbox. It processes sender and recipient addresses and message content for routing, performs authentication checks, and rewrites the envelope sender. Cloudflare keeps a record of each routed message (sender, recipient, subject, message ID, authentication results and delivery status), which it states is retained for 31 days. Delivery may be retried after temporary failures. Correspondence is also held in the destination inbox to respond to your request. No fixed retention or deletion deadline is promised for correspondence in the destination inbox; provider terms and applicable legal obligations govern retention. Do not email share passwords or protected document content.
Vercel request logs include real request paths such as share links. Production Vercel Web Analytics is cookieless and also records visited page URLs, including real share links, without link redaction. These records are visible to MDShare’s owner in the hosting account. A recorded link can open an unprotected share while it is available; password protection still needs the password.
MDShare uses Vercel, with about 1 hour of request/runtime logs and a 1-month Web Analytics reporting window. An analytics reporting window is not a deletion guarantee: Vercel may store analytics longer to support upgrades. Application cleanup jobs do not erase provider logs, analytics, email delivery records or legally retained Stripe and Link records.
Cookies and browser storage
Sign-in uses necessary session and sign-in-flow cookies, including PKCE verification and the return destination. Auth cookies are HttpOnly, SameSite=Lax and Secure in production. Supabase’s session and verifier storage cookies use a default maximum age of 400 days when written; that storage lifetime is not a guarantee that a session or verification code remains valid that long. The return-destination cookie lasts up to one hour. Successful sign-in clears leftover verifier and return cookies; signing out clears this browser’s auth cookies. Abandoned flow cookies may remain until their expiry or browser deletion. There are no advertising cookies. Web Analytics does not use cookies.
When you explicitly choose a language, NEXT_LOCALE remembers it for up to one year (Path=/, SameSite=Lax). This preference is optional; language links still work without cookies. Indexed pages use their URL language; share and auth pages can use this preference. No preference cookie is written just by rendering a page.
The theme preference uses browser local storage rather than cookies. Edit codes are saved automatically, unencrypted, in this browser’s local storage when you create a share or successfully enter a code in Manage; anyone using this browser profile can read them. Storage can be blocked or fail, so keep a separate copy of codes you need. You can clear local storage in your browser. Clearing it does not delete server-side shares or cancel a subscription.
Deleting data and exercising your rights
Use a share’s edit code to delete it. On the account page, signed-in subscribers can confirm account deletion. It cancels an active subscription immediately, with no prorated refund; unused paid time is lost. This does not limit statutory refund rights. Deletion can be refused if cancellation cannot be confirmed. Deletion removes the Auth account, owned shares and local billing records, while platform audit logs follow the short retention window described above. It does not remove anonymous shares or restore used creation allowances. Creation-log account ids are cleared, but keyed IP history remains until the 31-day purge; short-term security records follow their own expiry.
Copies saved by readers, provider records and any backups follow separate retention and cannot be recalled by deleting a share. No backup-erasure deadline is promised; provider retention policies and any legal holds apply.
Depending on applicable law, you may request access, correction, erasure, restriction or portability, object to processing, and complain to your local data-protection authority. Contact the operator above; we may need to verify your identity or control of a share without asking for its password or plaintext. Mandatory rights are not limited by this notice.