Developer guide
How to use Firebase without hurting the privacy of your users
Firebase can be incredibly helpful for analytics, crash reporting and messaging, but it also has the potential to collect more data than you or your users are comfortable with. In this article we show how to use Firebase consciously, in a way that respects privacy and fits well with a product whose core goal is to let people share files, transfer files and send files secure.
Start with a clear data philosophy
The most important decisions about privacy happen before you write any code. Ask yourself what you truly need to know about your users. Do you need to track every click, or is it enough to understand broad patterns like “how many transfers fail?” Do you need to attach analytics to real identities, or can you work with anonymous or pseudonymous identifiers?
At Free Transfer we chose a very conservative approach: we only care about metrics that directly help us improve reliability and speed. We are not interested in building detailed behavioural profiles. This philosophy informs every configuration decision we make in Firebase and other tools. If a feature does not serve that narrow purpose, we disable it.
Use the minimum set of Firebase products
Firebase is a large platform that includes analytics, crash reporting, real‑time databases, push messaging and more. You do not have to enable everything. In fact, enabling only a minimal subset reduces the risk of accidental data collection. For example, you might decide to use Crashlytics to understand stability issues, while leaving advanced marketing analytics turned off.
Go through each Firebase product you plan to use and map out what data it collects by default. Many SDKs allow you to disable certain automatic events or to opt out of features that are not essential. When in doubt, prefer less data, not more. If a future need arises, you can carefully add specific signals later instead of hoarding information “just in case”.
Disable unnecessary identifiers and ad features
Firebase and associated Google services can integrate with advertising IDs and remarketing systems. If your goal is to provide a privacy‑friendly way to share files and transfer files, there is usually no good reason to enable those options. In your Firebase project settings, turn off any integration that relates to personalised advertising, and avoid using identifiers that cross‑link behaviour across different apps or sites.
On the client side, review initialisation code to ensure that you do not inadvertently enable features such as automatic analytics collection in contexts where it is not appropriate. Many SDKs offer flags like setAnalyticsCollectionEnabled(false) or similar. Use them to align Firebase’s behaviour with your own privacy policy, instead of relying on defaults that were designed for ad‑driven apps.
Aggregate and anonymise wherever possible
When you do collect data, prefer aggregated metrics over detailed logs. For example, instead of recording every individual transfer with a long list of properties, you might only track counts of successful and failed transfers by broad categories such as region or device type. This is usually enough to identify reliability issues without exposing individual usage patterns.
If you need to correlate events over time, consider using short‑lived, random identifiers instead of persistent user IDs. That way you can still answer questions like “Did this new version reduce the number of errors?” without being able to reconstruct a full history of a specific person’s activity. This approach fits much better with the spirit of private file sharing and P2P tools.
Be transparent with your users
No matter how carefully you configure Firebase, you should still be upfront with your users about what you collect and why. Provide a clear, human‑readable privacy policy that explains which third‑party services you use, what data they receive and how long it is retained. Avoid vague language. If you only use Firebase for crash reports and basic performance metrics, say so explicitly.
Transparency builds trust. When users understand that you use Firebase to keep the app stable – not to spy on them – they are more likely to feel comfortable using your service to send files secure. For a tool like Free Transfer, where privacy is a core promise, this clarity is essential.
Keep Firebase separate from sensitive data flows
Wherever possible, do not send raw sensitive data to Firebase. For example, you should never log file names, contents or room identifiers that could be linked back to specific transfers. If you must log information about an error, strip out or hash any potentially identifying details. Remember that once data leaves the user’s device and enters a third‑party system, it is subject to that system’s policies and any legal requests they may receive.
This principle mirrors how Free Transfer handles file transfer itself. We design our P2P engine so that servers never see file contents. The same mentality applies to analytics: collect only what is needed to maintain and improve the service, and keep it abstract. You can still understand trends in how people share files without knowing exactly which files were involved.
Regularly review your configuration
Privacy is not a one‑time setting. As Firebase evolves, new defaults and features may appear that change what data is collected. Schedule periodic reviews of your project configuration. Check which events are being logged, whether any new integrations have been enabled and whether retention policies still match your intentions.
It is also wise to monitor your own codebase for logging statements or analytics hooks that might accidentally leak more information than intended. Over time, teams add debugging output, A/B tests or temporary experiments that can persist longer than planned. A regular audit helps you catch and remove such artefacts, keeping the system aligned with your privacy goals.