Privacy Policy

Last updated: 5 August 2026  ·  Effective: 5 August 2026

Applies to the Solid Share Android application (package com.erfangholami.solidshare) in every distribution, and to the website solidshare.app.

1. Who is responsible

Solid Share is developed and published by Erfan Gholami, an independent developer. For the limited data described in this policy that actually reaches us or our processors — essentially, diagnostics from the Google Play build and website request logs — Erfan Gholami is the data controller.

For the content you keep on your Solid Pod, you are in control: it is stored by the pod provider you chose, under your own account, and Solid Share is only the client application you use to work with it.

Contact for privacy questions and data requests: erfangholami76@gmail.com.

2. Where your data lives

Solid Share is a client for Solid Pods. It is not a service that stores your data.

When you sign in, you authenticate directly with the pod provider you picked, using Solid-OIDC. From then on the app reads and writes resources on your pod: files, contacts, tickets, share records and notifications. Those requests go from your phone to your pod provider. They do not pass through any server operated by us, because no such server exists.

The domain solidshare.app serves only static files:

• this website;
• the OAuth Client ID Document at /.well-known/clientid.jsonld, which your pod provider fetches during login so it can identify the app;
• the Android App Links verification file at /.well-known/assetlinks.json;
• share and ticket links, which the app intercepts and opens locally (see §4.6).

Your pod provider has its own privacy policy and terms, which govern the data you store there. Please read them — that is where your content actually resides.

3. Two builds of the app

Solid Share ships in two forms. They contain the same features, but differ in one privacy respect: diagnostics.

If you would rather no diagnostics were collected at all, install the FOSS build. Both builds are produced from the same public source code at github.com/erfangholami/SolidShare, which is MIT-licensed, so every claim in this policy can be checked against the code.

4. What the app handles

4.1 Your Solid identity and sign-in

Signing in opens your pod provider's own login page in a browser tab. Solid Share never sees, handles or stores your password. Once you approve, the app receives and keeps on your device:

• your WebID (the URL that identifies you) and your pod provider's address;
• the profile information published at your WebID — typically your name, photo and any details you chose to make public;
• OAuth tokens and a cryptographic key pair used to prove that the tokens are yours (DPoP, RFC 9449).

Tokens and the key pair are stored encrypted on your device, with the encryption key held in the Android Keystore, and are sent only to your pod provider and your pod. You can sign in with several accounts; each account's data is kept separate on the device, and signing an account out erases its local data.

4.2 Files, photos and videos

The app uploads to your pod only what you explicitly choose: a file picked through Android's document picker, an image or video picked through Android's photo picker, or a photo or video you take in the moment with the camera. Downloads are written to the location you select.

Solid Share does not request broad access to your photo library or to all files on the device, and it does not scan your storage. It sees only what you hand it.

To make browsing work offline, the app keeps a local copy of file metadata — names, sizes, types, timestamps, pod addresses — and of changes you made while offline, until they can be sent to your pod. This cache is encrypted (see §12).

4.3 Contacts

Contacts are a feature you turn on, and they only ever move between your device and your pod. Nothing is sent to us or to any third party. Two directions exist, both requiring the Contacts permission:

• Pod → device. Contacts stored on your pod appear in your phone's Contacts app under a "Solid Share" account, one per signed-in WebID, so other apps on your phone can use them. Signing out removes those entries from the device. Edits you make to them in the Contacts app are sent back to your pod. This runs about every four hours and when you open the contacts screen.
• Device → pod. An explicit, one-time "Import phone & Google contacts" action copies contacts from your device into your pod. It is a copy: your phone contacts and your Google contacts are never modified or deleted by Solid Share.

You can also import and export contacts as vCard (.vcf) files through Android's file picker; the app reads or writes only the file you select.

The contact fields handled are the ordinary ones — names, phone numbers, email addresses, postal addresses, organisations, notes, photos, WebIDs and similar — and they are written to your pod and cached, encrypted, on your device.

Because contacts describe other people, please remember that uploading them to your pod makes you responsible for that data under applicable law, and that your pod provider will store it. If you do not want that, do not enable contacts: nothing else in the app depends on it.

4.4 Tickets and passes

Tickets you add — by scanning a barcode, filling in the form, or importing an Apple Wallet .pkpass file — are stored on your pod, together with the original pass file when there is one. Barcodes are decoded entirely on your device with a free-software decoder; no camera image ever leaves the phone.

Pass updates. If an imported pass declares an issuer update service, the app asks that issuer — the airline, transport operator or venue that produced the pass, not us — for an updated copy roughly every twelve hours. That request carries the pass identifiers and the pass's own authentication token, both of which were inside the file the issuer gave you. As with any web request, the issuer can see your IP address and that the pass is still in use. Deleting the ticket stops the requests.

4.5 Sharing

When you share something, the app, acting as you and on your pod:

• writes an access-control rule granting the recipient's WebID the access level you chose;
• records a share entry so the app can show what you shared, with whom and when;
• may place a notification in the recipient's Solid inbox, so their app can tell them. That notification contains your WebID, the resource address and the access level, and it is delivered to the recipient's pod provider.

The recipient — and their pod provider — necessarily learn your WebID and what you shared. That is the point of sharing, but it is worth stating plainly.

Roughly every fifteen minutes, the app checks your own pod's inbox for incoming share notifications so it can show them to you. That check goes to your pod, nowhere else.

4.6 Share links and QR codes

A share link looks like https://solidshare.app/s?resource=…&owner=…&type=…. Anyone holding the link can read those values, so treat a share link as sensitive and send it only to the person it is meant for.

When the link is opened on a device with Solid Share installed, Android hands it straight to the app and nothing is requested from the network. If it is opened in a web browser instead — for example on a computer, or on a phone without the app — then, as with any web address, the full link including its parameters is sent to the server hosting solidshare.app and may appear in that host's standard request logs (see §15). We do not read, analyse or build profiles from those logs.

Ticket links (https://solidshare.app/t#…) keep their payload after the #, which browsers never transmit to the server.

4.7 Notifications and background work

Notifications are generated locally on your device — new shares, sync results, import and export progress. Solid Share uses no push messaging service, so no third party is involved in delivering them. Import and export run as foreground data-sync jobs so Android does not interrupt them; the notification you see is what that requires.

4.8 Diagnostics — Google Play build only

The Google Play build includes Firebase Crashlytics, Google Analytics for Firebase and Firebase Performance Monitoring, so that crashes and failures can be found and fixed. They are active in released Play builds and collect:

• Crash and error reports — exception type, stack trace, a short error message, the operation that failed, app version, device model, Android version, locale, timestamp, and a Firebase installation identifier;
• A small set of app events — that a login succeeded or failed, that a session expired with a short error code, which screen the app started on, how long an operation took, and non-fatal errors;
• Performance measurements — app start-up and screen rendering times.

What is deliberately kept out of these reports:

• No file, contact or ticket content, and no resource addresses. Network diagnostics record only the origin of a pod server (scheme://host); the path of a resource, which in Solid identifies both you and the thing itself, is stripped before anything is reported.
• No WebID. Where an identity provider is recorded, it is recorded as a host name only.
• No advertising ID. Its collection is switched off in the app's manifest, and there is no advertising or attribution SDK in the app.
• No precise location. The app requests no location permission at all.

Google processes this data on our behalf as a processor. See Firebase's privacy documentation and the Google Privacy Policy. Google deletes Crashlytics reports after 90 days; analytics event data is deleted by Google at the end of the retention window configured for the project, which is at most 14 months.

If you want none of this: install the FOSS build from F-Droid or GitHub. It contains no Firebase code, so nothing is collected or transmitted.

4.9 Data stored on your device

The app keeps, on the device only: the encrypted offline cache described above, your settings, sign-in state and tokens, imported pass files, and the queue of changes waiting to reach your pod. Android's own backup feature may include app data in the backup of your device if you have that turned on in your Android settings; that backup goes to your Google account, not to us, and is governed by Google's terms. You can exclude Solid Share in Android's backup settings.

5. Permissions

Every permission below is requested at the moment the feature needs it, with an explanation, and can be withdrawn at any time in Android's settings.

The app requests no location, microphone, SMS, call-log, calendar, health, "all files access" or broad media permissions.

6. Who receives data

There is no other recipient. We do not use advertising networks, attribution SDKs, marketing platforms, customer-data platforms or data brokers, and we do not disclose data to anyone for their own purposes. If we were ever legally compelled to disclose something, we could only hand over what we actually hold — which is the diagnostics and log data described above, and nothing from your pod.

7. What we never do

• We never sell or rent personal data, and never share it for advertising.
• We show no ads and use no advertising identifier.
• We do not track you across apps or websites, and we build no user profiles.
• We have no access to your pod, your files, your contacts or your tickets — no credentials, no back door, no copy.
• Solid Share creates no account with us; there is no account with us to create.
• We do not read the contents of your device beyond the items you explicitly pick.

8. Legal bases (GDPR)

Where the GDPR applies, we rely on:

• Performance of a contract / provision of the service you requested (Art. 6(1)(b)) — handling the data needed to sign you in and to move your content between your device and your pod, at your instruction;
• Consent (Art. 6(1)(a)) — every Android runtime permission: camera, contacts and notifications. You give it in the system dialog and can withdraw it at any time in Android's settings, with effect for the future;
• Legitimate interests (Art. 6(1)(f)) — the crash and stability diagnostics in the Google Play build, whose purpose is keeping the app working and secure. We minimise them as described in §4.8, and a build with no diagnostics at all is published alongside it so the choice remains yours.

For the content you place on your pod, the pod provider processes it under the agreement between you and them.

9. Retention

10. Deleting your data

Solid Share creates no account on any system we operate, so there is no account with us to delete. Your Solid identity belongs to your pod provider; closing it is done with them.

To remove data:

• Sign an account out in the app — erases that account's local data, its tokens, and the contacts mirrored into your phone's Contacts app.
• Delete resources on your pod — files in the Files tab, tickets in Wallet, contacts in Contacts (including "Delete all contacts"). Deletion happens on your pod, so it is permanent.
• Stop a share — revoke access in the app; the recipient loses access at your pod.
• Uninstall the app, or clear its storage in Android's settings — removes everything the app kept on the device. Your pod is untouched.
• Diagnostics (Play build) — write to erfangholami76@gmail.com and we will delete what we can identify; otherwise the reports expire on the schedule in §9. Installing the FOSS build prevents any further collection.

11. Your rights

Subject to your local law, you have the right to access, correct, erase, restrict, object to and receive a portable copy of your personal data, and to lodge a complaint with a data protection authority.

In practice, most of these you exercise yourself and immediately: the data is on your pod, under your identity, and Solid Share reads, edits, exports (contacts to vCard) and deletes it on your instruction. No request to us is needed, and we could not act on your pod on your behalf even if you asked.

For anything we do hold — the diagnostics and website logs — write to erfangholami76@gmail.com. We answer within 30 days. If you are in the EU/EEA or the UK and you are not satisfied, you may complain to the data protection authority of the country where you live or work.

12. Security

• All communication with your pod, your identity provider and any other server is over HTTPS. On Android 9 and newer the system additionally forbids the app from making unencrypted HTTP connections at all.
• Access tokens are bound to a key pair held by your device (DPoP), so a stolen token is not usable on its own.
• Tokens and identity material are encrypted at rest with a key held in the Android Keystore, which is hardware-backed on most devices and never leaves it.
• The offline cache is stored in a SQLCipher-encrypted database whose randomly generated key is itself encrypted by the Android Keystore.
• The app is sandboxed by Android: no other app can read its data, and Solid Share cannot read theirs.
• The source code is public and MIT-licensed, so the security claims here are open to inspection. If you find a vulnerability, please report it to erfangholami76@gmail.com rather than filing a public issue, and we will respond as quickly as we can.

No system is perfectly secure. Because we hold no copy of your data, a breach of ours could not expose it — but the security of your pod and your device also matters, so please keep both protected.

13. Children

Solid Share is a general-audience tool and is not directed to children. It is not designed for, marketed to, or intended to be used by children under 13 (or the higher age of digital consent in your country, which is up to 16 in parts of the EU). We do not knowingly collect personal data from children. If you believe a child has provided data to us, write to erfangholami76@gmail.com and we will delete it.

14. International transfers

The processors named in this policy — Google (diagnostics, Play build) and Cloudflare (website hosting) — operate globally and may process data outside your country, including in the United States. Both offer transfer mechanisms recognised under EU law, including the European Commission's Standard Contractual Clauses, and both are certified under the EU-U.S. Data Privacy Framework.

Where your pod data physically lives is determined by the pod provider you chose, not by us.

15. This website

• No cookies are set by solidshare.app, and there is no analytics, tag manager or tracking pixel on it.
• This privacy policy page loads no third-party resources at all. Opening it contacts nothing except the site's own host.
• The site is served through Cloudflare, which processes requests as our hosting and delivery provider and keeps standard, short-lived request logs (IP address, requested URL, user agent, timestamp) for delivery, security and abuse prevention. See the Cloudflare Privacy Policy.
• The home page currently loads a web font from Google Fonts, which means Google receives your IP address when that page loads. No other page does.
• Share links opened in a browser transmit their parameters to this host, as explained in §4.6.

16. Changes to this policy

If the app's data handling changes, this page changes with it, and the date at the top is updated. Material changes will also be noted in the release notes of the version that introduces them, so you can see what changed and when. Because the page is served from a public git repository, its full history is auditable.

17. Contact

Privacy questions, data requests and security reports: erfangholami76@gmail.com

Bugs and feature requests: the GitHub issue tracker

Controller: Erfan Gholami, independent developer, publisher of Solid Share.