Yes: it would be great if a site could use something like CSP to ensure that if they've only gotten consent for vendors A and B that vendor B doesn't go violate their contract by bringing in unconsented vendor C.
(Though in this case B and C are both Google, and in a slightly different world both Google Pay and Google Analytics could be hosted on the same domain.)
I don’t understand the issue. If you’re already using google pay, then google is a data processor for you and you should have already received consent.
This isn’t stripe doing this, rather it’s google doing it.
Google Analytics doesn't "track" users unless explicitly configured to do so. Google Pay actually needs PII, meanwhile the worst that Google Analytics collects (but doesn't share with site owners) is IP, which Google Pay probably also collects as part of KYC regulations.
You’re right, but also wrong. Not all collection is equal. Placing your payment data in a database that is strictly for legal purposes is different than placing in a connected database built to track users around the web.
Privacy laws allow you to keep the data only for as long as legally necessary and required. Google Analytics may keep this data indefinitely.
This is exactly what GDPR is for, right? Arguing "you've already given some data to one bit of Google, so all bets are off and they can collect and store whatever they like" is the kind of logic we want to put a stop to.
> [...] the Italian [Data Protection Agency GPDP] reiterated that an IP address is personal data and would not be anonymised even if it were shortened – given Google’s capabilities to enrich such data through additional information it holds.
> [...] DSB issued a second decision, declaring the use of Google’s IP anonymisation a useless protection measure for data transfers between the EU and the United States.
Their servers still get your IP tho and by default nothing in USA is GDPR compatible because US government can enforce leaking any info they want from company
Alas there are no payment processors that don't do tracking. As I understand it, VISA and Mastercard were some of the originators of this business model.
The issue is that GA is outlawed, or soon to be outlawed, in some places. Bundling GA into Google Pay + Stripe likely puts some companies at legal risk without them knowing it
My tech stack is built on various products, including no-code site building tools, and I believe these tools employ JavaScript/cookies at layers which are inaccessible to me. Some of these may cavort with GA.
Under GDPR, if you use a third-party tools, and those tools process user data (including just being loaded onto the page from a third-party server, because that requires processing IP Address), then your arrangement with that third party must describe the processing that they are going to perform. The description of processing is often a separate document from other contract stuff, called the Data Processing Agreement (DPA), but that's a convention and not a requirement.
Your responsibility is making sure that data processed under the terms of that agreement conforms to GDPR. Your primary responsibilities are the articles in Chapter 3 "Rights of the Data Subject" under GDPR, and making sure you can do that for data sent to the third-party.
Their responsibility is making sure that data is only processed how they describe it in the DPA. If they surreptitiously add Google Analytics, that's their violation.
If the contract is too vague to tell what processing is going on, then that is your violation for choosing to engage with them as a processor. In practice this might be your biggest risk.
Under GDPR you are the data controller of you decide what data is collected and for what purposes.
I would expect this to cover you as the operator of the website (or other service). Your agreements with your tool
providers probably specify that they are data processors for you.
If data was being collected and accessed without lawful basis (by eg GA embedded somewhere in your stack), this would count as a data breach. You would have to inform your data regulator (eg ICO in the UK) within 72 hours of becoming aware of it, and tell them among other things what remedial action you are taking. You could also be fined for failing to do due diligence.
Under GDPR, you have to ensure you gather consent properly. If your tools are not equipped to deal with that, that's your problem, not the tool's author's.
You seem to imply that consent is required. Consent is not required if you are not gathering data that needs to be consented to.
If my tools are gathering data behind my back and not telling me, that is troubling. I should not be liable for this, as it is an abuse of trust that would result in me no longer using the tool had I known prior.
If you can't ensure the tools you use are not fucking your customers over, you shouldn't be using those tools.
Sure if you did the due diligence, and they actually hid that they use cookies[0], both in their documentation and technically while you were developing, then enabled them in production, where you missed them, sure. But most don't hide they use cookies, not in documentation and not while developing.
[0] By cookies I mean anything that would require consent
Yes, using 3rd party tools that you don't fuly understand should not be a plausible deniability shield. Otherwise, everyone with intent would be hiding behind it.
> If my tools are gathering data behind my back and not telling me, that is troubling. I should not be liable for this, as it is an abuse of trust that would result in me no longer using the tool had I known prior.
Well, you can sue tool makers if they lied to you.
But ability to just say "but I didn't know" would be catastrophic to any accountability, as nobody would even read a manual to be able to plausibly claim that they didn't knew.
In similar way you can't go shoplifting then claim you didn't know that was a crime.
(Edwin from Stripe here.) This is correct. I can only speak to how Stripe.js works but if a business chooses to accept Google Pay, we've limited it to loading in an iframe. (We don't load Google scripts on the business's domain.)
If website A embeds website B in an iframe and website B loads Google Analytics, does website A have to show a cookie consent form? Or does website B have to show a cookie consent form inside of the iframe? Does stripe display such a consent form in the iframe?
My understanding of GDPR and e-Privacy as it applies to a payment iframe like we're talking about here is that site A would get consent for B as a payment processing vendor, and then B would have a contract with A ("DPA") that ensures it doesn't do things outside of what A will be getting agreement for. In this case, I don't see how B running analytics JS is beyond what A already needs to be getting consent for.
(I used to work in this general area, but don't anymore.)
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...