This privacy statement describes how File Pty. Ltd. ("we", "us") handles personal and sensitive information when you use 1Share at https://1share.com.au.
1Share is a secure sharing service for credentials and other sensitive messages. It is intended for organisational use. You should not treat it as an anonymous public pastebin.
This statement is provided so that senders, recipients, and operators can see what is stored, what is discarded, and what is kept for compliance.
1. Who provides this service
| Product name | 1Share |
| Organisation providing this instance | File Pty. Ltd. |
| Service URL | https://1share.com.au |
File Pty. Ltd. determines the purposes of processing for this instance (hosting, security, and the compliance log described below).
2. What the service is for
You (or a colleague) may upload text and files to generate a time-limited link. A recipient with that link can decrypt and read the content until the view limit or expiry is reached, or until the message is deleted.
3. What we collect
3.1 Content you submit (the secret)
When a message is created we process:
- The text of the message
- Attached files and their original file names
- Options you choose (maximum views, expiry, whether a passphrase is required, and — on premium accounts — whether a reply link is enabled)
Plaintext content is not stored. It is encrypted in the application immediately. The database and the file directory hold only ciphertext (plus, if TDE is enabled, that ciphertext is also encrypted on disk by the database). The decrypt key for each message is split: one part is given to you in the link (#k=) and is not stored on the server; the other part is stored in wrapped form.
If you set an extra passphrase, that passphrase is not stored. Recipients must have both the link and the passphrase.
3.2 Premium accounts
If you create an account we store your email address and a password hash (Argon2id). We send a verification link to that address. Optional authenticator (TOTP) secrets are stored encrypted. Authenticator codes and passwords themselves are not logged. Recipients do not need an account to open a link.
At signup we also check the address locally (format, disposable-provider list, and domain DNS). That check does not send your email to a third-party API.
Signed-in accounts can open history to see metadata for secrets they created: created time (UTC), encrypted size, and whether the secret was opened, is still waiting, expired without reading, or was deleted without reading. History does not include decrypt keys, message text, or file contents.
3.3 Technical and compliance data
For security and compliance we record:
| Data | When | Why |
|---|---|---|
| Date and time (UTC) | Create, decrypt attempt, delete, expiry purge, reply-link create | Security investigation and compliance |
| Uploader IP address | When a secret or reply token is created | Accountability for who sent material |
| Downloader IP address | Each decrypt attempt (successful or denied) | Accountability for who accessed a multi-view link |
| Original file names | Create and successful decrypt | Compliance: what files were shared, without keeping the files after disposal |
| HMAC fingerprint of text | Create and successful decrypt | Integrity / “what was sent” without storing the text |
| HMAC fingerprint of each file | Create | Same, for attachments |
| User-agent (truncated) | Successful decrypt | Distinguishing browsers from obvious automation in investigations |
| Share identifier | On related events | Linking audit rows after the secret itself is gone |
HMAC fingerprints use a server-side secret. They are not raw hashes and are not designed to be looked up in public rainbow tables. The same content sent twice on this instance will still produce the same fingerprint, which is intentional for internal checks.
3.4 What we do not keep
We do not store or log:
- Message plaintext
- File bytes (except as encrypted objects until disposal)
- The URL decrypt key (
#k=) in the database or audit log - User passphrases
- Authenticator / MFA codes
- Account passwords (only Argon2id hashes are stored)
- Verification and password-reset URLs (those are sent to you by email over SMTP and are not written to application logs)
A reply-notification email to the premium account that issued the reply link does include the retrieve URL with #k=, so that mailbox (and any mail gateway that sees the message) can open that one reply. Do not forward that mail.
4. Where data is stored
| Location | What is there | Encrypted at rest? |
|---|---|---|
| Database (Percona Server for MySQL) | Ciphertext, wrapped key share, view/expiry metadata, encrypted file names, account records (email, password hash, wrapped authenticator secret), hashed auth tokens, compliance log | Application encryption for message content, wrapped key shares, filenames, and authenticator secrets. Passwords are stored as Argon2id hashes, not reversibly encrypted. Compliance log columns (IP addresses, file names, HMACs) are not application-encrypted so they can be reviewed. TDE encrypts these tables on disk so a stolen volume or raw tablespace file is unreadable without the database keyring. TDE does not hide those columns from a live SQL session. |
| File directory | Encrypted attachments only | Yes (application encryption). Not covered by database TDE. Host disk encryption may add a second layer. |
| Redis | Rate-limit counters, short-code cache, short-lived download sessions, and login sessions (hashed session identifier → user id) | Not used as long-term content storage. Sessions last seven days by default, or until you log out. Download sessions expire in 10 minutes. |
| Your browser / chat client | The full link including #k= if you copy it; session and CSRF cookies | Under your control. Treat the link as a secret. |
All application encryption is performed in PHP. The database engine is not the message encryptor. TDE, when enabled, is InnoDB tablespace encryption as a second layer for stolen disks. See the security statement.
5. How long we keep it (retention)
| Data | Retention | Disposal |
|---|---|---|
| Encrypted message and files | Until the chosen expiry, or until you or the recipient delete the message, or until a purge job runs after expiry | Ciphertext is nulled; encrypted files are deleted from disk; the share is marked destroyed |
| Exhausted-view ciphertext | Kept until the same expiry so a recipient can finish downloading files after the last decrypt; further decrypts are refused | Same purge after expiry |
| Reply tokens | Until their own expiry, or after the single use | Rows removed by the purge job |
| Compliance / audit log | 730 days from each event (default 730 days / 2 years) | Older audit rows are deleted by the purge job. Destroying a secret does not delete its audit trail before this period |
| Redis rate-limit keys | Minutes to one hour | Automatic key expiry |
| Login sessions (Redis) | Seven days by default, or until you log out | Deleted on logout or when the session expires |
| Download tokens | 10 minutes | Automatic expiry |
The compliance retention period is longer than message lifetime on purpose, so File Pty. Ltd. can show that a share occurred (who, when, which file names, content fingerprints) after the secret itself is gone.
6. Disposal
Disposal is performed by the application and by a scheduled purge job:
1. Manual delete by someone who has the URL key: ciphertext and files are removed immediately; a deleted audit event is written.
2. Expiry: after the chosen expiry, purge removes remaining ciphertext and files; a purged audit event is written.
3. View limit: further decrypts are refused once views are used. Files may remain until expiry so the last recipient can download them; then purge removes them.
4. Audit: records remain until 730 days have passed, then they are deleted by the same purge job.
We cannot dispose of copies a sender or recipient made outside the system (screenshots, forwarded mail, downloaded files).
7. Web server logging
This section is intended for privacy assessments of web server logs, which are separate from the 1Share compliance table.
7.1 What Apache is configured to log
Production Apache access logs record, for each HTTP request:
- Client IP address
- Time of the request
- Method (
GET,POST,DELETE) - URL path only (for example a retrieve path or an API path). The path may contain a message identifier, which is not the decrypt key
- Protocol and status code
- Response size
Query strings are not written to the access log.
7.2 Decrypt keys and Apache
The decrypt key is placed in the browser fragment (#k=...). Fragments are not sent to the server, so they do not appear in Apache access logs, error logs, or reverse-proxy logs under normal browser behaviour.
You should still:
- Avoid putting secrets in query strings (1Share does not put the decrypt key in a query)
- Treat Apache logs as personal data because they contain IP addresses
- Restrict who can read web server logs
Error logs may contain PHP or Apache diagnostics. They are not intended to contain message plaintext. Operators must not increase log verbosity in a way that would print secrets.
7.3 Retention of Apache logs
1Share does not automatically delete Apache logs. Log rotation and retention are a hosting control of File Pty. Ltd. (for example logrotate on Red Hat Enterprise Linux 9.8). Typical practice is 30–90 days of access logs, which may be shorter or longer than the 730-day application audit retention. Those two stores should not be assumed to be the same.
7.4 Other logs
- PHP / PHP-FPM logs — errors and slow requests; should not contain message bodies.
- Database logs — general and query logs stay off so ciphertext and SQL parameters are not written in operational logs.
- Redis — ephemeral keys only; not a compliance archive.
- Cloudflare Web Analytics (if enabled) — a browser beacon to measure page views and performance. It does not receive message plaintext or the
#k=fragment.
8. Who can access data
- Senders and recipients with the link can decrypt content until disposal.
- System administrators of File Pty. Ltd. can read configuration, ciphertext (not plaintext without the URL key), and the compliance log (IP addresses, file names, fingerprints).
- Database administrators with SQL access see ciphertext, account emails, password hashes, and the compliance log, not message plaintext, unless they also have the server wrapping key and a URL key. TDE does not change what a live SQL session can read; it protects the files on disk.
- We do not sell this information. We do not use message content for marketing or profiling.
9. International and legal notes
IP addresses and file names can be personal data. File Pty. Ltd. should restrict access to the compliance log and Apache logs, and document any extra lawful basis required for its jurisdiction (for example employee monitoring or security logs). This statement describes what the software stores; it is not legal advice.
10. Your choices
- Do not put secrets in the same channel as the passphrase; use a second channel.
- Use the shortest view count and lifetime that still works.
- Delete a message after it has been read if you have the link.
- Recipients can refuse to decrypt; opening the link does not by itself reveal content.
If you need a copy of compliance records, or deletion of audit rows before the retention period, contact File Pty. Ltd.. Statutory rights (access, erasure, complaint to a regulator) depend on your location and relationship with File Pty. Ltd..
11. Changes
This statement reflects the behaviour of this 1Share software. Operational retention of Apache logs is set by File Pty. Ltd. on the host. The live copy is published at https://1share.com.au/privacy.
12. Contact
File Pty. Ltd.
Service: 1Share
https://1share.com.au