I want to use Firebase Cloud Messaging in a healthcare application. I want to know is FCM HIPAA Compliant and does it provide BAA?
We’ve just completed the HIPAA audit with a 3rd party for a Firestore Chat sample app (iOS and Android) that’s using End-to-End Encryption. If you’re implementing a healthcare Chat app, keep reading. Otherwise, this isn’t relevant.
The challenge: if you know how E2EE works, you realize that it alone should protect your patients’ data from Firebase/Firestore: apparently, lawyers don’t agree with that. So we had to implement an artificial data redaction that deletes chat messages from Firestore as soon as the messages are delivered. This enables your app to qualify for HIPAA’s Conduit exception, because it only acts as a message delivery system, it doesn’t store permanent health data. This way, your chat solution is exempt of HIPAA.
We’ve compiled the solution into a How-to blog post: https://VirgilSecurity.com/hipaa-firebase - with pointers to reusable sample apps.
Whitepaper that contains our HIPAA audit & 3rd-party data privacy expert’s notes: https://VirgilSecurity.com/firebase-whitepaper
According to the co-founder, as of now Firebase is not HIPAA compliant.
You can take a look at the updates here: https://groups.google.com/forum/#!topic/firebase-talk/sg-WCHVXs5k
Related
Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.
I'm thinking of using an MBaaS such as Firebase or Kinvey for my next app, and am wondering if any exist which encrypt application data end-to-end (i.e. such that the encryption keys are never shared with the service provider). This seems feasible in theory, since the server is not expected to do any computation on the data, only store it and deliver it to clients.
Does such a service exist? I've found ZeroDB and Crypton, but neither are available as services AFAICT, which means I'd have to administer, scale, and back them up myself. I also thought of using something like Firebase and encrypting my app's data before I pass it to the Firebase API, but I'm wary of writing a one-off crypto layer like that unless I have to (i.e. I'd rather use something that's been peer-reviewed).
Alternatively, if no such service currently exists, why not? Is it technically infeasible, or is there just no market for it?
Edit: This seems closest to what I'm looking for, but considering the broken links on their website I'm guessing it's defunct: Adreneline Mobility
The answer to your question is actually available on the market. CloudMine offers end-to-end encryption (disclosure - I work at CloudMine). They have a largely healthcare focused offering so it has to stand up to HIPAA and other government regs around data security.
Here's a good overview video on security featuring CloudMine's CTO. The first 45 sec. provide some more information on our encryption techniques.
I know I'm being the "sales guy" right now but I'm happy to hop on a call to share what we've built and discuss your specific use case. You can email me at nick at cloudmineinc.com if you're interested.
Virgil Security (full disclosure - I work there) has an end-to-end encryption SDK that works for any endpoint, and also has a special integration with Firebase. It's open source, of course. Check it out and feel free to ask any questions of the team here or on Slack - https://e3kit.readme.io/
I am about to submit an app to the Apple AppStore built in Swift that uses Crashlytics to capture crash information. As users of Crashlytics know, some information about usage, duration, crashes, etc. is captured and stored on the Crashlytics servers. My application does not ask for, store or attempt to capture any user data.
My question is about the privacy policy for my application. Since I don't capture any user data, I want to state that in my privacy policy but I'm not sure that's factual since I am using Crashlytics. Any feedback on people that have used Crashlytics in their app and have an actual privacy policy?
Thanks
--Vinny
Quick answer: yes, you need that privacy policy. There are ways to get it done fast, too.
Longer answer:
Third parties (here Crashlytics)
When dealing with a third party service like this, often a quick look into their legal documents will help (for Crashlytics in this case as described in your question).
(...) At all times during the term of this Agreement, Developer shall
maintain a privacy policy (a) that is readily accessible to users from
its website or within its online service (as applicable), (b) that
fully and accurately discloses to its users what information is
collected about its users and (c) that states that such information is
disclosed to and processed by third party providers like Crashlytics
in the manner contemplated by the Services, including, without
limitation, disclosure of the use of technology to track users’
activity and otherwise collect information from users. (...)
And
Developer shall at all times comply with all applicable laws, rules
and regulations relating to data collection, privacy and security,
including, without limitation, the Children’s Online Privacy
Protection Act (“COPPA”). Crashlytics may, at its sole discretion from
time to time during the Term of this Agreement, audit Developer Data
to verify compliance.
Crashlytics is actually being unusually vocal about this topic.
The App Store
At the time of writing (and since iOS8) Apple requires privacy policies for 5 categories:
Kids Category, HomeKit, HealthKit, Apple Pay, and Keyboard Extentions. Also they require privacy policies for user registrations (more). I can't tell if any of the above for your app is true. Apple still says in their App Store Review Guidelines that you need to be compliant with all applicable laws. This brings us to the third and most important reason.
Privacy related regulations
All of the above is just there because of global privacy regulations, these companies would most likely not care otherwise. As soon as you work with User data you are mostly under an obligation to disclose these facts. It's personal data like names, addresses or the tracking of user behaviour. It's been written at length why analytics services need privacy policies. All of it is more important as soon as you share data and use third party services for it. Mostly the disclosure or some kind of consent is the condition for it's compliant usage.
If you are interested in reading more about the matter in the context of mobile apps I'd suggest any of these documents:
ICO UK
Ireland
USA/California
Canada
Australia
Hope this helps.
(For proper disclosure: I do some work for iubenda, a tool that helps creating privacy policies for apps and websites)
Vinny, I think it's not mandatory (I've seen apps using Crashlytics wihtout a privacy policy), but it's recommended to have transparency in the communications with your users.
Crashlytics already has a privacy policy so you can just use that policy and add a statement informing that you are not collecting any sensitive information from the user, such as email or phone number.
I've been reading about Firebase and playing with it for a short while. The idea (BAAS) and implementation are impressive, and having programmed with Javascript it seems a viable choice. Not having to deal with scaling and other server side concerns makes it even more attractive.
My question is: generally speaking, is Firebase a first class back-end candidate for any average data-based application? e.g. billing, CRM, e-commerce, social, location based, etc. I do not include super light or heavy extremes such as a basic chat, or a nuclear plant monitor...
The answer may not be a clear yes/no, but was it built to support the general application space, or just stand out as a real-time read/write data service?
Would appreciate answers based on experience and existing production applications.
Thanks
Yes, Firebase is intended to be a first class back-end for any data based Web, iOS or Android application. The service offers real-time data reads and writes, but also comes with a powerful and flexible security system that allows you to write secure client-only apps, without needing any server code to enforce data boundaries.
There are several apps in production listed on the front page as customer and on the app showcase page on https://firebase.google.com/customers/
Firebase is now more capable and is considered as a full stand-alone back-end, especially after the introduction of cloud function. https://firebase.google.com/docs/functions/
Firebase may not have support for transaction spanning multiple business objects.
e.g. When a sales order is booked then it needs to update inventory for multiple items, update billing in receivables, give sales credit to multiple sales persons etc.
Firebase team is supposed to come up with a database trigger option which will make all these happen.
We have a very basic application (iOS/Android) done in Appcelerator that will receive a single update every week. This update will be sent to all the users subscribed to the push notifications service.
By this moment, we have around 35k installs but 7,000 active users on this application on last month. We've been evaluating two services for all the push notifications:
StackMob
Parse
Appcelerator Cloud services is fine, but we're not willing to pay that much. Parse and StackMob prices are lower than Appcelerator Cloud services and by our analysis, we could even use the free service on both services (StackMob = 60k push notifications + 60k api calls, and Parse 1M api calls + 1M pushes).
If we're going to use Parse, we'll need to buy the Android and iOS module from the Marketplace ($30/year each). Which is fine. On the counterpart, I think we could use the REST API on StackMob for subscribing to the push service.
Questions:
What are your thoughts on both services? Which one do you prefer and why?
Have you used StackMob REST API for subscribing to push notifications?
How do you retrieve Android's token?
Is there any (cost effective) alternative to these services? I also reviewed PubNub, which seems to be great but costs are higher than StackMob and Parse.
Thanks in advance.
Update
I asked the same question on Appcelerator forums. After a while, users came back with several answers and users using Parse.com for this.
I ended implementing Parse.com, which was really simple by using the Android and iOS plugins that are on the Appcelerator Market.
I wanted to chime in and point you to some StackMob references around Appcelerator.
Aaron Saunders has several projects on github showing how to use StackMob with Appcelerator.
https://github.com/aaronksaunders
He also wrote a series of blog posts about it.
http://developer.appcelerator.com/blog/2011/11/titanium-appcelerator-quickie-stackmob-api-module-part-one.html
Our REST API reference is available at https://developer.stackmob.com/tutorials/dashboard/REST-API-Reference
One of the big differentiators between StackMob and others is our custom code option. You can write your own logic in Java, Scala or Clojure and host it on StackMob. The custom code can interact with your user data and other 3rd party APIs.
https://developer.stackmob.com/tutorials/custom%20code
I haven't used those services myself, so I cant comment. However, Another alternative we use (and have been pretty happy with) is Urban Airship. It's relatively cost effective, supports Android, iOS and BB and it has server side libraries for a bunch different languages. There is also a neat blog post outlining how to easily do device registration (at least for iOS) via simple web requests in Appcelerator.
The blog post on its Appcelerator integration is here.