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.
Related
This question comes up because of very specific HIPAA requirements. A Covered Entity(CE) eg, doctor can't use a cloud storage provider (CSP) unless they have a Business Associate Agreement (BAA) with the CSP, even if the data are encrypted and the CSP has no access. I'm not a security expert, but most web hosts' security would IMO satisfy HIPAA, IF there were a BAA.
There's a conduit exception for video, ISPs, and other electronic equivalents of USPS that do not store electronic Protected Health Information (e-PHI.)
I don't know why, but the web hosts who will sign a BAA charge $100-300/ mo for very basic hosting other sites charge $5-15/mo for. I think they're preying on CE ignorance with the perception there's lots of money sloshing around, true for radiology, but not for primary care.
G-Suite will execute a BAA, which makes G-Suite a reasonably-priced solution for gathering Protected Health Information (PHI) patient input, while keeping the CE compliant with HIPAA.
It's worth noting that "HIPAA compliance" is ONLY a property of CEs and Electronic Medical Records, not other software or sites. Any other product or service claiming "HIPAA compliance" is misrepresenting itself.
I find Google Sites not as user-friendly as most web hosts. There's less hand-holding for doing things like installing WP add-ins, or adding SSL certificates. Or maybe Google just does a terrible job of explaining how to actually DO something with a site hosted there. In any case, it seems easier to run a website on a web host that's set up to manage software and WP plug-ins for amateurs.
I'm willing to be educated on this. (24 hours later--I did a lot of self-education-see answer below.)
The basic HIPAA privacy requirements are rather simple:
CEs can use PHI to treat and carry out essential functions, but must
not share it with anyone not entitled to it.
The basic HIPAA security requirements are also simple:
Make a security risk analysis.
Implement reasonable security measures and
Document why various measures were taken or not.
Some elements are required, others must simply be addressed, evaluated and documented.
For example, 2FA is "addressable" as is data encryption, but making an analysis, having physical security and employee training are required.
So my question is whether a G-Suite form embedded in a website on another web host stores any data on that web host, or does it all go back to G-Suite, eg G-Drive, where it's secure and covered by a BAA?
The problem when you know very little about a topic is, you don't know what to ask. I know a bunch about HIPAA, not much about HTML. I did a lot more research, and there's at least two answers.
The short answer is, NO, the embedded frame is an iframe HTTPS linked to G-Suite.
The form in the iframe is a window into docs.google.com, so data never gets off docs.google.com, where it's covered by G-Suite's BAA. The host site is in effect a conduit.
<iframe src="https://docs.google.com/forms......…</iframe>
Note https
Embedding the form does not create a HIPAA violation.
The second answer is, G-Suite has its own content management system and website builder, which requires very little technical skill. Thus there's no need to install Wordpress or anything else, you just drag-and-drop to create a site. All the back end stuff is done for you. Duh. And they execute a BAA, all for $6 a month. So G-Suite is much simpler, in fact so simple that only a child can do it. Their help pages leave much to be desired.
Bottom line--for small covered entities, G Suite is a very economical website solution that doesn't create a HIPAA violation. Wish I knew this yesterday!
FYI: HIPAA compliant Cloud Services
We have a WordPress website that sells and ships products all over the world including European countries. We have modified UK-Cookie-Consent plugin to our needs. We currently display the following warning at the top of the page where clicking on "Find out more" takes the user to our privacy page:
At the same time, we do not display cookie warnings on continents other than Europe. We also have several 3rd party tracking cookies such as facebook, google analytics and klaviyo that we use for various tracking purposes.
When I scanned our website for GDPR compliance via various web scanners such as cookiebot, cookieserve.com, gdprcookiescan.eu and ezigdpr.com, the website shows up as non-compliant.
My question is as a wordpress developer, what additional steps if any I can take to make the website GDPR compliant.
My additional question is on whether the results of the GDPR scans from aforementioned scanners should be taken with concern and whether there are other more respected scanners out there that are recommended to use to ensure GDPR compliance.
Some background info first:
This is important since there is a lot of misinformation and confusion about this topic out there. I'll do my best to clarify it. There are 2 different laws(regulations/directives) that come into play here.
ePrivacy Directive: This is the directive responsible for the cookie banners, which was actually implemented in 2003 already and had its last amendment in 2009. Its currently being reworked again at the moment. Since its a directive and not a regulation, each EU member country is responsible for implementing their own "version" of it. This has resulted in different requirements depending on the country. (I know, not helpful) Some countries required an opt-out for cookies, others just an informational banner, which is what you see most of the time.
GDPR (General Data Protection Regulation):
The new buzz in the industry, doesn't actually explicitly deal with cookies. This deals with the processing of personal data and "personally identifiable information" (PII), which is any data that can be used to identify an individual. Examples: Name, Email address, phone number, credit card number, IP-Address (under certain conditions). According to the GDPR, you need to have a so-called legal basis (why am I legally permitted to process the data) for processing any personal data. There are 6 of these you can look them up here: Lawfulness of processing
So what does all that mean and how does it fit together?
You need to show a cookie banner because of ePrivacy and you need to have a legal basis for processing data retrieved via cookies because of GDPR which can vary depending on what the cookie is used for. There are 3 types of legal bases that will probably be relevant for your website: Legitimate Interests, Consent and contract (To process the customers purchase)
IMPORTANT: According to the GDPR you are required to provide your users with the information about which data is processed, under which legal basis as well as the purpose of the processing. This needs to go into your privacy policy.
So when can I set which types of cookies?
Strictly necessary cookies: Can be set without explicit consent. (still required your to inform your users that you use cookies via banner) These are cookies which your website requires in order to operate. Like your customer's login session and shopping cart.
Statistics: Assuming that your site uses some kind of analytics service that doesn't share any data with an ad network. You could argue that you have the legitimate interest, in this case being something like "improving the website by analyzing website usage". I would definitely at least provide an opt-out for this type.
Targeting/Marketing Cookies: Here it's difficult to argue that you have a "legitimate interest" since users are being tracked and profiled. For these opt-in is a must. That means if a user opts-in, your legal basis is consent. Facebook pixel, for example, should be opt-in.
Answers:
My question is as a WordPress developer, what additional steps if any I can take to make the website GDPR compliant.
You need to do a lot more than just handle the cookies properly. That is only a small aspect of what you need for GDPR compliance. You need to determine what your processing purposes for all types of personal data you collect from your customers/users. This needs to be included in your privacy policy, not forgetting the legal basis for processing. You need to be able to inform (privacy policy) your users/customers about the following when you collect any personal data: GDPR Article 13
My additional question is on whether the results of the GDPR scans from aforementioned scanners should be taken with concern and whether there are other more respected scanners out there that are recommended to use to ensure GDPR compliance.
I would not rely on scanners in general, except maybe to figure out what types of cookies your site is setting that you may have overlooked. These scanners can not tell you if your site is GDPR compliant, in the best case they can tell you if your cookie consent dialogue is working by it only finding "strictly necessary" cookies for example. That banner that you have is for implicit consent, by the way, that would have been ok in most cases before GDPR, however, is no longer ok. If you are setting cookies like those of Facebook before the user clicks "I consent" then that is probably why the scanners are saying you are not compliant.
Hope I didn't freak anyone out ;) Everyone is in the same boat of not being entirely sure of some aspects, even the big enterprises. There are a lot of aspects of the GDPR where the text is not entirely clear, leaving room for interpretation.
Side note:
We built a solution for some customers that continuously auto-generates the privacy policy, keeping it aligned with the website, central updates for policy changes as well as managing the privacy controls for cookies, social media etc. We're in the process turning it into a generic solution that anyone can use. We're looking for pilot customers that we can work with to further develop it. You can check it out here: TRUENDO
You may use this Cookie Consent Solution for GDPR, it will automatically block the cookies prior to the consent. It works for all platforms like WordPress, Drupal...etc.
I'm building a shiny app where users upload transaction data to get access to an analytics dashboard. Can I assure these people that their data is secure from sniffers/hackers and will be removed from the shiny server when their session expires? How does this actually work in Shiny? (Note that I'll be hosting my app on shinyapps.io)
This is not to do with shiny, but whatever server you're storing the data on, how you're using encryption/hashing, and software/app security methods you've used to protect against specific vulnerabilities.
Having said that, here's the (rather minimal, IMHO) security statement for shinyapps.io:
shinyapps.io is secure-by-design. Each Shiny application runs in its
own protected environment and access is always SSL encrypted. Standard
and Professional plans offer user authentication, preventing anonymous
visitors from being able to access your applications.
I would say that the burden will heavily fall on you to use good encryption and data storage practices.
There are many official and unofficial guidelines you can look to for guidance on data storage. One which big companies, particularlly companies going public, must follow is Sarbanes-Oxley.
From grtcorp.com:
The Sarbanes-Oxley Act (SOX Act) was passed by Congress and signed
into law in 2002 in response to major cases of financial fraud, of
which the rise and collapse of Enron is the best known. The overall
focus of the measure is on financial reporting responsibilities, and
ensuring that financial audits are genuinely independent.
However, SOX also includes provisions that relate to the security and
preservation of financial data. And the standards set out for its
implementation "recognized that senior management can't just certify
controls ON the system, these controls also have to control the way
financial information is generated, accessed, collected, stored,
processed, transmitted, and used through the system."
Senior management is thus held ultimately responsible for financial
data security, including putting in place appropriate controls and
procedures to ensure this data security. The good news is that
powerful tools, including data discovery and Data Masking, are
available to meet these standards.
I would also encourage you to familiarize yourself with OWASP's list of the top 10 major web app vulnerabilities:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
My employer has recently switched to using Skype for Business. Aside from a somewhat painful user experience on the Mac, its not so bad. However, several of us have noticed that certain employees can join meetings without being listed amongst the attendees. I don't mean anonymously- I mean the attendee count doesn't even register the additional bodies.
Is this some kind of audit feature that allows certain users the ability to secretly join a meeting? Or perhaps its just a feature that allows someone to slip in late without disturbing the flow? Or maybe just a bug?
I don't mean to sound paranoid but this activity only seems to occur for division heads, which is why several of us have taken notice.
The short answer is yes.
But "normal" people can't do it directly, as the only type of participant that can be hidden is a UCMA trusted application, using a trusted application endpoint.
For "normal" Skype clients to connect hidden, is to connect to a UCMA trusted application endpoint that does a B2BUA call into the conference.
You can see an example of this in Microsoft's UCMA reference Call Center application.
I am submitting an app that uses the dropbox SDK to upload photos from the iPhone to a specified folder in dropbox. I am stuck on a question as I don;t know how/what/if dropbox sdk uses cyroptograhy. Can you help me answer the following questions?:
Is your app designed to use cryptography or does it contain or incorporate cryptography? (Select Yes even if your app is only utilizing the encryption available in iOS or OS X.)
If so,
Does your app qualify for any of the exemptions provided in Category 5, Part 2 of the U.S. Export Administration Regulations?
Make sure that your app meets the criteria of the exemption listed here. You are responsible for the proper classification of your product. Incorrectly classifying your app may lead to you being in violation of U.S. export laws and could make you subject to penalties, including your app being removed from the App Store. Read the FAQ thoroughly before answering the questions.
You can select Yes for question #2 if the encryption of your app is:
(a) Specially designed for medical end-use
(b) Limited to intellectual property and copyright protection
(c) Limited to authentication, digital signature, or the decryption of data or files
(d) Specially designed and limited for banking use or "money transactions"; or
(e) Limited to "fixed" data compression or coding techniques
You can also select Yes if your app meets the descriptions provided in Note 4 for Category 5, Part 2 of the U.S. Export Administration Regulations.
If not,
Does your app implement one or more encryption algorithms that are proprietary or yet to be accepted as standard by international standard bodies (such as, the IEEE, IETF, ITU, and so on)?
Etc.
I work for the Dropbox API team. I'm not a lawyer, nor familiar with the App Store process. Presumably it asks this question of everyone submitting an app, and many apps already approved use the Dropbox SDK.
That said, reading through the question ISTM that the Dropbox SDK qualifies under (b) and (c). In the SDK that links with your app we use OAuth and SSL for authentication, SSL for keeping your users' files safe from prying eyes, and either digital signatures or cryptographic hashes to safeguard against data corruption and to detect duplicates.
For more info on this topic see also a recent thread on the Dropbox forum: https://forums.dropbox.com/topic.php?id=114805