Legal
Privacy Policy
Version 2.0.0 · Effective October 5, 2026
Our privacy pledge: we never sell your information
This is the promise we want you to read before anything else in this policy. It covers everything we hold about Customers and Contacts: account and billing details, address books, request records, audit logs and every uploaded file.
We never sell it. We do not sell, rent, trade or license personal information or uploaded files to anyone, for money or for anything else of value.
We never pass it to related companies or partners. We do not give it to any affiliate, subsidiary, parent company, partner or data broker, whether for marketing, advertising, profiling, training artificial intelligence or any other purpose.
No subsidiary loophole. Some companies promise not to sell your data, then hand it to a related company that does. We do not. A company related to us gets no more access to your information than a stranger would.
The only outside parties that handle it are named on our sub-processors page. They handle it under contract and only to run the Service: Lunanode operates the servers, easyDNS relays the emails the Service sends, and Stripe processes payments. Like any regulated payment processor, Stripe also uses billing details to prevent fraud and to meet its own legal obligations. A provider that is not on that list does not receive your information.
Delivering what you asked for is not sharing. When the Service emails an invitation to the Contact a Customer named, delivers a Contact's upload to the Customer who requested it, or sends a file to the recipient a Customer chose, it is carrying out that instruction.
One exception, on our public marketing and signup pages only. Those pages carry Google Analytics and Google Ads tags. Google receives nothing unless you accept the cookie banner. If you accept, Google receives your activity on those pages, your IP address, its cookie identifiers, and whether your visit ended in a signup, and uses them under its own terms for measurement and advertising. Signing in or creating an account moves you into the secure service through a full page load that carries no Google code. No analytics or advertising event is ever sent from the dashboard, the upload pages or the download pages. Section 11 has the detail.
Legal demands: only when the law requires it, with one emergency exception. Apart from the sub-processors named above and from carrying out your own instructions, we disclose personal information or files to a government, a court or anyone else only when the law requires it: a valid court order, warrant, production order or subpoena, or a statutory duty such as reporting a breach to the Privacy Commissioner of Canada. An informal request, even from police, is not enough. We check that the demand is valid, push back on overbroad demands, and disclose only what it compels. We tell the affected Customer before we disclose unless a court order or the law prohibits notice, or we reasonably believe that notice would itself break the law, for example by obstructing an investigation the demand tells us is under way. When the prohibition ends or the concern lapses, we tell them then. The one exception is an emergency: if someone faces an imminent risk of death or serious bodily harm, we may give the minimum information needed to emergency services, police, or the person exposed to the danger or their representative. We record every such disclosure and tell the affected person in writing without delay, as the law requires. Section 5.4 describes our yearly transparency report.
The promise survives a sale. If Viscous Bits is ever sold, merged or reorganized, this promise stays attached to the information. Personal information and files will not be transferred to a buyer or successor, or sold as a business asset, unless the recipient is bound by this same promise.
The detail behind these points is in the numbered sections below.
1. Who we are
ReceiveVault (the "Service") is operated by Viscous Bits Computing Solutions Inc. ("Viscous Bits", "we", "us", "our"), a corporation incorporated under the Canada Business Corporations Act and based in Ontario, Canada. We provide a hosted service that lets our customers ("Customers") request files from people who do not have an account ("Contacts") through secure single-use links, and send files to them the same way.
The person accountable for our compliance with privacy law is our Privacy Officer, Viscous Bits Computing Solutions Inc., reachable at legal@receivevault.com.
2. Scope and roles
This policy describes how we handle information about:
- Customers and their users: the businesses that hold an account, and the people who sign in to it.
- Contacts: people who receive a request or delivery link from a Customer and upload or download files through it.
- Visitors: anyone who reads our public pages without signing in or using a link.
We play two roles.
For Contact information and uploaded files, the Customer is the accountable organization under privacy law. It decided to collect the files, it chose the Contact, and it sets how long the files are kept. We are its service provider and handle that information only on its instructions, as described here, in the Terms of Service and, for business customers who sign it, in our Data Processing Addendum. The upload and download pages carry a short notice to Contacts, given on the Customer's behalf; it is also published as our Contact notice.
For account information (users, billing, audit records, support correspondence and analytics) we are the accountable organization in our own right.
3. Information we collect
3.1 Account information (we are accountable)
| What | Detail |
|---|---|
| Profile | Email address, display name, role on the account, account name, chosen plan, preferred currency and region, notification and email preferences, the Terms version you accepted |
| Credentials | Password hash (Argon2id; never the plaintext password), encrypted TOTP secret, passkey public keys and device names, hashed recovery codes. All authentication secrets are stored hashed or encrypted |
| Devices and sign-ins | For device recognition, a fingerprint derived from your browser identifier and your network block (the /24 for IPv4 or /64 for IPv6), not from the full address. Separately, the full IP address and browser identifier of each sign-in, shown to you on your Security page |
| Billing | Stripe customer and subscription identifiers, billing cycle, trial and renewal dates, invoice history. Card numbers are entered on Stripe's pages and never reach us |
| Team | Invitations sent, accepted and revoked |
| Branding and domains | Logo, colours and copy you set; a custom domain and sending domain you connect |
| Attribution | The referral code and campaign parameters (utm_source, medium, campaign, term, content) present when you first visited, written to the account at signup |
| Support | Email you send to support or legal, and our replies |
| Audit log | For every meaningful action (sign-in, password or MFA change, request created, file uploaded or downloaded, team change, billing change, admin action): the actor, the action, a timestamp, the IP address and the browser identifier |
| Exports | The ZIP archive you generate when you export your account, for 10 minutes while the download link is valid |
| Beta invitations | The email address and note a beta user enters when inviting someone, who invited them, and whether the invitation was used |
| Invitation opt-outs | The email address of anyone who used the unsubscribe link in a beta invitation email, and when |
| Download usage | The size and time of each download from the account and which file it was, not who downloaded it |
| Beta access requests | The name, email address and message you send us when asking for a beta invitation, and your firm's name if you give it |
| Feedback and bug reports | See section 3.5 |
3.2 Customer content (the Customer is accountable)
| What | Detail |
|---|---|
| Address book | Contact name, email address, phone, organization, notes and tags the Customer writes, and where the entry came from (manual, CSV or vCard import) |
| Requests and deliveries | Title, description, the message to the Contact, the Contact's name and email address, expiry and limits, the link token (hashed), and for deliveries any password-protection parameters (we hold a salt and a check value, never the password) |
| Files | The file itself, its original filename, size, type, SHA-256 hash, scan result, and end-to-end encryption parameters where used |
| Government identification images | Where a Customer asks for it, an image of the front or back of an identity document, recorded with the document type and side. Stored like any other file, encrypted at rest, on the Customer's retention schedule, and not openable by our administrative tools. We do not read or verify the document. Text a Contact's browser decodes from a licence barcode to check legibility is never sent to us |
| Access records | For each upload and each download: the IP address and browser identifier of the device that did it, and the time. For email access codes: the address the code went to, the hashed code, IP address and browser identifier |
3.3 Technical and anonymous information
| What | Detail |
|---|---|
| Server logs | Web server logs with IP address, requested path, time and browser identifier, on our own server |
| Rate-limit counters | Per-surface counters keyed to an IP address or account, kept for at most twice the rate-limit window |
| Device performance telemetry | When a Contact uses the identification capture feature: anonymous measurements of the browser, device model, processor count, memory and camera capabilities, with no link to the Contact, the Customer or the file |
| Marketing analytics | Only on public marketing and signup pages, only after you accept the cookie banner: see section 11 |
| Region | We look up the country of your IP address in a database bundled with our software, with no network call, to show you the Canadian or US site and currency |
3.4 Information we do not collect
- We do not use analytics, advertising or profiling tools inside the secure service (the dashboard, the upload pages and the download pages).
- We do not collect biometric data. Passkeys are stored as public keys; the biometric never leaves your device.
- We do not knowingly collect information from children. See section 12.
3.5 Feedback and bug reports
Feedback is accepted only from signed-in account users, through the feedback form in the dashboard. Contacts on upload pages cannot send feedback. When you send feedback, we record what you write, the type of report, whether we may contact you about it, whether you gave us permission to quote it, the page you were on (with any link token removed), your browser type and screen size, and your account and user. We use this only to fix problems and, if you said we may, to reply to the email address on your account. If you gave permission to quote it, we ask you again before publishing any quote on our website, and show only your first name, last initial and role. Reports are kept for 12 months, then deleted. Please do not put files, passwords or other people's personal information in a report.
4. How we use information
We use the information above to:
- provide, secure and maintain the Service, including authenticating users, enforcing access control and detecting unauthorized access;
- scan uploaded files for malware (section 8) and tell the Customer when a file is malicious;
- send the emails the Service exists to send: invitations, reminders and receipts to Contacts at the Customer's request, and security, billing and account emails to users;
- send Customers three kinds of account-lifecycle email: a reminder that a trial ends soon, on an account that has one (factual account information; beta accounts have no trial), a nudge if you have not sent a request within your first month, and a check-in if your account has been quiet for 90 days. The last two are commercial messages sent on the basis of our existing business relationship: while you hold a subscription and for up to two years after it ends, as CASL allows. A beta account owner receives them as part of the invite-only beta they joined. Every one carries an unsubscribe link, and you can turn them off in your notification settings;
- send invitation emails to a person a beta user names, in that user's name and ours, and limit the number of invitations per account;
- review requests for a beta invitation and reply to them;
- apply download limits and detect abuse of the Service;
- bill you through Stripe and keep the records tax law requires;
- respond to support requests and legal notices;
- measure and advertise our public pages, only with your consent (section 11);
- comply with legal obligations and respond to valid legal demands (section 5.3).
We do not use personal information or uploaded files to train any machine-learning or artificial-intelligence model, and we do not permit our sub-processors to do so.
5. Sharing, sub-processors, and our own access
5.1 Sub-processors
The vendors that handle personal information on our behalf, what each one can see, where it operates and whether it is subject to US jurisdiction are published on our sub-processors page, which is the list of record. Today they are Lunanode Hosting Inc. (servers, Toronto), easyDNS Technologies Inc. (outbound email relay, Ontario), Stripe, Inc. (payments, United States) and Google LLC (marketing analytics and advertising after consent, United States). Object storage and virus scanning run on our own server and are not separate vendors.
If we add or replace a sub-processor that will handle your information, we email account owners at least 30 days before it does, and you may close your account without penalty in that window. Only an emergency replacement, for example a vendor failing, may happen faster, with notice as soon as practicable. Removing a vendor needs only a page update. The page carries a dated change log.
5.2 Our staff
Our staff (one person today) can see account details and file metadata such as filenames, sizes, dates, scan results and Contact names and email addresses, in order to run the Service, provide support, handle abuse reports and meet legal duties. Our administrative tools cannot open file contents. We open the contents of a file only at the Customer's written request or when the law requires it, and each such access is recorded in the audit log. End-to-end encrypted files cannot be read by us at all. Views of customer records in our administrative tools are themselves recorded.
5.3 Legal demands
Beyond our sub-processors and carrying out your instructions, we disclose personal information only as set out in the pledge above: when a valid legal demand compels it, or in an emergency involving an imminent risk of death or serious bodily harm. We tell the affected Customer before disclosing unless a court order or the law prohibits it, or notice would itself break the law; the Customer decides what to tell its Contacts. Our internal procedure for handling demands is summarized on request.
5.4 Transparency report
Each year we publish a transparency report on this page describing the legal demands for personal information we received, how many we complied with in whole or in part, and how many Customers we were able to notify, to the extent the law permits and subject to any non-disclosure order in force. The first report covers the year in which this policy took effect.
5.5 Successors
If the business is sold or reorganized, the pledge above binds the recipient.
6. Where your information is stored
The application, the database and uploaded files run on a server in Toronto, Ontario, Canada, operated by a Canadian company. Backups are encrypted and stored in Canada: each night the database is backed up in encrypted form and copied, together with the stored files in the encrypted form the Service keeps them in, to backup storage in Ontario operated by us. Deleted data drops out of backups within 30 days.
Email leaves through easyDNS, a Canadian company, and is then delivered to each recipient's own email provider, which may store it outside Canada. Messages are encrypted in transit wherever the receiving provider supports it. Message bodies never contain uploaded file contents.
Stripe processes billing information in the United States and globally. Google processes marketing-page analytics in the United States and globally, only after consent.
If we ever move the primary storage of your information outside Canada, we will update this policy and give notice under section 13 first.
Customers in Quebec: information you and your Contacts give us is communicated outside Quebec, to Ontario, for storage and processing. We have assessed that transfer as required by Quebec law, and the information receives protection equivalent to what the Quebec Act requires.
7. How long we keep information
| Information | Kept for |
|---|---|
| Files received through a request | 90 days after the request's last activity by default. The Customer may set 7 to 365 days. One year is the maximum at every plan level. The Customer receives a warning email 7 days before the first deletion in the account |
| Files sent through a delivery | 30 days after the delivery expires. Deliveries expire 30 days after sending by default, 90 at most |
| Request and delivery records (title, filenames, sizes, hashes, uploader network address, timestamps) | Customer content: kept until the Customer deletes the request or delivery, one year after the Customer archives it, or the account closes, whichever comes first. The browser identifier recorded with an upload is removed when the file is deleted |
| Address book | Until the Customer deletes the entry or the account closes |
| Government identification images | Same as files received through a request |
| Account information | While the account is open. After closure: removed from the live Service within 31 days, out of backups within a further 30 days |
| Beta accounts | While the account is open. An account is never suspended or deleted because the beta ended: when the beta ends it moves to the Free plan unless its owner subscribes. Its files and records follow the rows above |
| Free-plan accounts | While the account is open. An account over the Free plan's limits (for example after the beta ends) has nothing deleted because of it; new uploads are refused until it is back under the limits or on a paid plan. Files keep the deletion dates above, and automatic storage cleanup runs only if a user on the account has turned it on |
| Paid accounts that are cancelled or unpaid | Read-only from cancellation or from 21 days after a failed renewal; marked for deletion 90 days after becoming read-only, with warning emails at day 60 and day 83; removed from the live Service within a further 31 days; out of backups within 30 days after that |
| Sign-in devices | While the device is listed on your Security page, at most 12 months after its last use, or until the account is purged, whichever comes first |
| Audit log | 12 months from the event, then deleted. Entries from closed accounts are kept for the same 12 months so that security investigations and legal claims about that account can still be answered; nothing else survives purge. Customers who need a longer record export it (audit.csv in the account export) |
| Rate-limit counters | At most twice the rate-limit window, minimum one day |
| Device performance telemetry | 90 days |
| Beta invitations | Until the invitation is used, revoked or expires, then 90 days |
| Invitation opt-outs | Kept indefinitely so we never invite that address again; deleted on request, after which an invitation could reach it again |
| Download usage | 35 days |
| Beta access requests | 12 months |
| Feedback and bug reports | 12 months |
| Marketing analytics (Google) | Event and user data in our Google Analytics property: 2 months. Google's cookies: see section 11 |
| Server logs | Kept 14 days on our server, then deleted; not exported |
| Delivery logs are kept briefly by easyDNS under its policy; we do not keep a separate copy of message bodies | |
| Billing records | As long as tax law requires, currently six years after the end of the tax year, held with Stripe and in our accounts |
Customers may delete files, requests, deliveries and address-book entries at any time before these windows pass.
8. Security and breaches
We protect information with TLS in transit, server-side encryption of all stored files, encrypted authentication secrets (Argon2id for passwords, AES-256-GCM for TOTP secrets), HTTP-only secure session cookies, optional end-to-end encryption on eligible plans, multi-factor authentication available on every account, rate limiting, virus scanning of every upload we can read, and a per-event audit log. Our Security page describes these controls.
No system is perfectly secure. If we confirm a breach of security safeguards involving your information, we will notify the affected Customers without undue delay, and we aim to do so within 72 hours of confirming it, and keep them updated as we learn more. The Customer notifies its Contacts unless the law requires us to notify them directly, in which case we coordinate with the Customer first where the law allows. We report to the Privacy Commissioner of Canada, and to provincial regulators where required, whenever the breach creates a real risk of significant harm. We keep a record of every breach for 24 months.
9. Your rights
If you are an individual whose information we hold, you may:
- ask for access to the personal information we hold about you and how it has been used and disclosed;
- ask us to correct inaccurate or incomplete information;
- withdraw consent to a use, subject to legal and contractual limits (for example, you cannot withdraw consent to our processing of your account credentials while keeping the account);
- ask us to delete your information, subject to records we must keep;
- complain to the Office of the Privacy Commissioner of Canada if you believe we have not handled your information lawfully. If you are in Alberta, British Columbia or Quebec, you may instead complain to your provincial privacy commissioner.
Write to legal@receivevault.com. We respond within 30 days. We may need to verify your identity first; we ask only for what is needed to do that.
Contacts: the Customer who asked for your files is accountable for them. Ask the Customer first; if you cannot reach them, write to us and we will help.
10. Residents outside Canada
We serve customers in the United States and elsewhere from Canada, under Canadian law. Wherever you live, you have the rights in section 9, including access, correction and deletion. We do not sell personal information, and we do not use it for targeted advertising beyond the consent-based marketing analytics in section 11. We do not target the European Union or United Kingdom.
12. Children
The Service is for businesses and is not intended for children. We do not knowingly collect personal information directly from a child. A Customer may ask a parent or guardian to upload a child's documents (for example for a school, clinic or family-law matter); the parent or guardian confirms their role in the Contact notice, and the Customer is accountable for those documents. If you believe a child's information has been provided to us in error, write to legal@receivevault.com and we will delete it.
13. Changes to this policy
The version number and effective date at the top of this page identify the current version, and a dated list of what changed appears below. For a material change, including any change that removes a commitment, we email account owners at least 30 days before it takes effect and show a notice in the dashboard until then. Non-material corrections take effect when published and are listed in the change log.
14. Contact us
Privacy Officer, Viscous Bits Computing Solutions Inc.
legal@receivevault.com
Support: support@receivevault.com
Viscous Bits Computing Solutions Inc., operating as ReceiveVault, Ontario, Canada.
What changed
- 2.0.0 (this version). Full rewrite. Operator named as Viscous Bits Computing Solutions Inc.; Privacy Officer designated; contact address moved to legal@receivevault.com. The "No AI tools, ever" pledge bullet is removed; the no-training commitment in section 4 stays. Section 3 becomes a three-part data inventory and now names government identification images, per-upload and per-download IP addresses, address-book fields, attribution parameters, device telemetry, beta invitations, invitation opt-outs, download usage, beta access requests and feedback reports. New section 3.5 describes feedback and bug reports. Section 3.1 corrects the earlier statement that we never hold a full IP address. Section 5 names all four sub-processors, describes staff access and legal-demand handling in detail, and adds a yearly transparency count. Section 6 states where backups are held. Section 7 replaces the previous list with a full retention table, including beta, Free-plan and cancelled accounts, sign-in devices, beta invitations, invitation opt-outs, download usage, access requests, feedback and the audit log's 12-month limit. Section 9 names the Alberta, British Columbia and Quebec commissioners. Section 8 sets a Customer notification commitment without undue delay, aiming for 72 hours. Section 10 replaces the California notice with a paragraph for all residents outside Canada. Section 11 lists every first-party cookie by name and lifetime, removes the incorrect "CSRF cookie" line, names the Google cookies, and describes the 2-month analytics retention. Section 12 rewritten for parent-or-guardian uploads.
- 1.2.0 (2026-09-14). Privacy pledge published above section 1.
- 1.1.0 (2026-06-20). Retention schedule for files added to section 7.
- 1.0.0. First version.