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.
Related
My question is more of a conceptual one, but in my specific case I am using Google Analytics 4. If the question is unclear, here it is in scenario form: Some guy visits my site x.com after a google search. He closes the tab, does another google search, and arrives at my other site y.com. How do I know it's the same person? I don't think there's anything I can do with User ID's in this situation. How would I solve this?
This isn't without fault, but if you are implementing it via Google Tag Manager, you have more control over the data being sent and on top of that, if you are transporting the data via Google Tag Manager server side container.
You would use a single server (but possibly different containers) or use BigQuery and either use the templateDataStorage API call or the BigQuery API call.
Essentially, the first time you see a google cid or an IP address or combination of user agent and ip address you would store it in the server or in a BigQuery table as a key and create a random associated value next to it.
At each time, across all your sites, you would check to see if the IP address or CID or combination of user agent and ip exists in the server or in the BigQuery table, then output the random value as a custom dimension and if not, it will create one.
Actually you probably wouldn't.
Presumably you could try fingerprinting, but depending on your legislation that might not be quite legal, and it tends to work a lot better in a lab than in real life. Also browsers start to implement anti-fingerprinting measures such as trimming the user agent, and denying access to browser properties such as installed plugins.
I have heard of experimental approaches to recongnize users via usage patterns - e.g. how do they move their mouse etc. I am not aware of any actual product that uses this, and I am not convinced it is a useful (or even legal) approach.
But in general, when it comes to cross-domain detection for unrelated visits (moving from domain to domain works via link decorators, and even that is affected by browser protections) you have the combined power of browser vendor against you, who try to make this harder (either for genuine concerns about privacy, or to establish themselves as the single gatekeeper for user identity. E.g. Google has a huge user base that is almost constantly logged in to Google accounts or Android smartphones, which helps with identifying users all over the web).
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
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 just used a great PDF Converter, but I noted that they have a 30 minute intermission between conversions (to get paying customers). So I got curious as to how the restriction might be is implemented; and afaik it doesn't seem to be (solely?) cookie-based.
IP-address doesn't seem likely (wouldn't that block entire NATted organizations collectively?), and using filename would be too blunt. Can Javascript generate hardware-unique info these days? What other other ways are there? What is secure, what is easy to implement and what is just rotten?
I think the problem here is to uniquely identify a client's browser.
Can Javascript generate hardware-unique info these days? What other
other ways are there?
A simple solution (may not be exhaustive) I can imagine, is to consider not just the cookie or the ip address but all possible parameters like
cookies
ip address
browser details
flash cookies and
then those information that can be pulled off from a client's browser via Javascript (which is enabled for most of the browsers and needed by most sites like the one you mentioned) such as plugins installed, their versions.
With all these information, one can identify a machine uniquely on the internet to a great extent.
What is secure, what is easy to implement and what is just rotten?
Personally, I have never implemented this, but it seems quite doable.
Some interesting links that I found during the course of this short interesting research are:
Peter Eckersley. 2010. How unique is your web browser?. In Proceedings of the 10th international conference on Privacy enhancing technologies (PETS'10), Mikhail J. Atallah and Nicholas J. Hopper (Eds.). Springer-Verlag, Berlin, Heidelberg, 1-18.
How unique and trackable is your browser?
Is browser fingerprinting a viable technique for identifying anonymous users?
How do I uniquely identify computers visiting my web site?
Browser fingerprinting code snippet
Flash Cookies, a Little-Known Privacy Threat
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
At the moment it seems that most webapps store their user-data centrally.
I would like to see a movement towards giving the user total access and ownership of their own personal information and data; ultimately allowing the user to choose where their data is stored.
As an example - with an application like facebook, the user's profile data could exist on any device that they own (e.g. their mobile phone) ... facebook would then request the data from the user, and make use of it.
Does anyone see this idea becoming a reality? Is it a ridiculous idea?
CLARIFICATION:
The information would at least need to be cache-able. The motivation behind the idea was to give the user more control over their own data - the user is self-publishing an
authoritative version of what they are happy for the world to see.
I'm imagining a future which is largely dictated by choices which are made now. Perhaps physical location of the data isn't actually important - and is more a symbolic gesture... but I think that decoupling the relationship between our information and the companies that make use of it could be a positive thing.
But perhaps, the details do need a bit more work ;)
What's with performance? Imagine you want to search for data that is located on hundreds of mobile phones or private distributed systems.
what your describing is simulator to a combination of OpenID Attribute Exchange, Portable Contacts and OpenSocial. Having one repository of user data that every other provider would feed off. Its nice for a user but I would not go so far as to tie it to a specific device. Rather a federated identity that you control from one vendor's website/application.
I am with you on this one.
And I think the key technology might be RDF. Since protocols such as F.O.A.F. are already used in these social applications, it is a small step from $Facebook storing your RDF Graph, to you storing it yourself, and saying: This is me, these are my friends, or anything else you might want someone to know.
This approach might be globalised to other personal information you might ened an authorised party to know, like Health Records.
There are quite a few conceptual problem with what you are suggesting.
Firstly, everytime you reconnected to the system, you would need to upload your personal information back into the system so that it could interact with you. This adds quite an overhead to the signin/handshake/auth with the remote system.
Secondly, alot of online systems (particularly online communities) rely on you leaving an online profile of yourself so that other users can interact with you (via your profile) when you yourself are offline. This data would have to be kept somewhere central.
At the very least, the online system would need a very basic profile to represent you, so that you could login & authenticate against... which sounds like a contradiction to what you are suggesting.
Performance would suffer should the user have physical possession of the data; e.g., thumb drive, local drive. However, if a "padded cell" solution were possible where the user has complete rights to a vault that the application could reach quickly, then there might be a possibility.
This really isn't a technology solution, rather one of corporate policy. Facebook could easily craft a policy that states that your records are yours, just like a bank should. They just don't. For that matter, many other institutions who are supposed to guard our personal information - our property if I can evoke John Locke - but fail miserably. If they reviewed their practices for violation of policy and were honest, you could trust. Unfortunately this just doesn't happen.
The IRS, Homeland Security and other agencies will always require that an institution yield access to assets. In the current climate I can't see how it would be allowed for individuals to remain in physical possession of electronic records that a bank or institution would use online.
Don't misinterrpret me - I think your idea is a good one to pursue, but it's more of a corporate policy issue than a technical solution.
You need to clarify what you mean by ownership. Are you trying to ensure that the data is only stored on your own devices? As others have pointed out, this will make building social networks impossible. You would disappear from Facebook when you weren't connected to it, for example.
Or are you trying to ensure that a single authoritative copy exists and that services defer to it? This might be more possible, and would require essentially synching the master copy on your cell phone with the server when possible.
Or are you trying to ensure that you can edit/delete your account at any time? Most sites already work like this.
The user still wouldn't be sure they 'own' their data, simply because they'd have to upload it every time they connect, and the company it's being sent to could still do whatever it wants with it. It could just not display your profile when you're not online, but still keep a copy of it somewhere.
Total access, ownership and location choices of personal information and data is an interesting goal but your example illustrates some fundamental architecture issues.
For example, Facebook is effectively a publishing mechanism. Anything you put on a public profile has essentially left the realm of information that you can reasonably expect to keep private. As a result, let's assume that public forums are outside the scope of your idea.
Within the realm of things that you can expect to keep private, I'm a big fan of encryption combined with physical and network security balanced against the need for performance. You use the mobile phone as an example. In that case, you almost certainly have at least three problems:
What encryption is used on the phone? Any?
Physical security risk is quite high - have you ever had an expensive portable electronic device stolen? There seems to be quite the stolen phone market out there....
The phone becomes a network hotspot - every service that needs your information would need to make an individual connection to your phone before it could satisfy a request. Your phone needs to be on, you need to have a sufficiently fat data pipeline, etc.
If you flip your idea around, however, it becomes clear that any organization that does require persistent storage of your sensitive private information (aka SPI) should meet some fundamental (and audit-able) requirements:
Demonstrated need to persist the information: many web services already ask "should I remember you?" or "do you want to create an account?" I think the default answer should always be "NO" unless I say otherwise explicitly.
No resale or sharing of SPI. If I didn't tell my bank or my bookstore that they can share my demographic information, they shouldn't be able to. Admittedly, my phone number and address are in the book, so I can't expect that I'll stay off of every mailing list but this would at least make things less convenient for the telemarketers.
Encryption all the time. My SPI should never be stored in the clear.
Physical security all the time. My SPI should never be on a laptop drive.
Given all of the above, it would be possible for you to partially achieve the goal of controlling the dissemination of your SPI. It wouldn't be perfect. The moment you type anything in, there is immediately a non-zero risk that someone somewhere has somehow figured out to monitor or capture it. Even so, you would have some control of where your information goes, some belief that it would only go where you tell it to go and that the probability of it being stolen is somewhat reduced.
Admittedly, that's a lot of weasel words in a row....
We are currently developing a platform to allow people exercise the right to access their personal data (habeas data) against any holder of such data.
Rather than following the approach you suggest, we actually pursue a different strategy: we take snapshots of the personal data as it is in the ddbb of the "data holder" whenever the individual wants to access her data.
Our objective is to give people freedom in the management of their own personal data, allowing them to share it with others based on their previous consent.
I would like to further discuss with you should you be interested.
Please read Architecture Astronauts.