8 ms·

Google Analytics is injected with Stripe.js when enabling Google Pay

118 points by davidbarker 4y ago

mrunkel 4y ago
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.
- tpxl 4y ago
  > you should have already received consent For payment processing. Not for tracking.
  - deleted 4y ago
    [deleted]
  - sofixa 4y ago
    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.
    - xani_ 4y ago
      IP is considered PII in certain circumstances.
      - sofixa 4y ago
        Yes, it is, but my point is that Google Pay collects more PII, including IP, so what Google Analytics does is moot.
        laundermaf 4y ago
        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.
        blowski 4y ago
        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.
      - dbbk 4y ago
        I'm sure Google always anonoymises the IP now though? They drop the last octet.
        cuu508 4y ago
        Can we verify that?
        Y-bar 4y ago
        > [...] 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. https://noyb.eu/en/update-further-eu-dpa-orders-stop-google-analytics https://noyb.eu/en/update-further-eu-dpa-orders-stop-google-...
        xani_ 4y ago
        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
  - nicoburns 4y ago
    > For payment processing. Not for tracking. 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.
  - collegeburner 4y ago
    is this any different from if another payment provider runs analytics on its own site?
- tootie 4y ago
  Right? It's technically first-party to them.
- frankfrank13 4y ago
  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
daoist_shaman 4y ago
I’ve been concerned about this. 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. How liable am I?
- tpxl 4y ago
  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.
  - daoist_shaman 4y ago
    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.
    - tpxl 4y ago
      > I should not be liable for this 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
      - dylan604 4y ago
        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.
    - xani_ 4y ago
abraham 4y ago
It looks like GA is being loaded in the Pay iframe.
- edwinwee 4y ago
  (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.)
- counttheforks 4y ago
  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?
  - jefftk 4y ago
    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.)
  - deleted 4y ago
    [deleted]
tagawa 4y ago
Looks like Paddle does this as well: https://twitter.com/MrMooky/status/1570480546287071234 https://twitter.com/MrMooky/status/1570480546287071234
deleted 4y ago
[deleted]
ezekg 4y ago
It sucks that even a good Content Security Policy [0] can't stop an iframe from making these types of requests. [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
- jefftk 4y ago
  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.)
Kiro 4y ago
This non-issue is HN's chance to show they won't just automatically pick up the pitchforks on any "Big Tech bad" post.
hairofadog 4y ago
I would argue for replacing the word "with" with "into" in the headline here, so it's clear what's being injected into what.

118 points by davidbarker 4y ago

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.

tpxl 4y ago
> you should have already received consent For payment processing. Not for tracking.
- deleted 4y ago
  [deleted]
- sofixa 4y ago
  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.
  - xani_ 4y ago
    IP is considered PII in certain circumstances.
    - sofixa 4y ago
      Yes, it is, but my point is that Google Pay collects more PII, including IP, so what Google Analytics does is moot.
      - laundermaf 4y ago
        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.
        blowski 4y ago
        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.
    - dbbk 4y ago
      I'm sure Google always anonoymises the IP now though? They drop the last octet.
      - cuu508 4y ago
        Can we verify that?
      - Y-bar 4y ago
        > [...] 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. https://noyb.eu/en/update-further-eu-dpa-orders-stop-google-analytics https://noyb.eu/en/update-further-eu-dpa-orders-stop-google-...
      - xani_ 4y ago
        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
- nicoburns 4y ago
  > For payment processing. Not for tracking. 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.
- collegeburner 4y ago
  is this any different from if another payment provider runs analytics on its own site?
tootie 4y ago
Right? It's technically first-party to them.
frankfrank13 4y ago
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

daoist_shaman 4y ago

I’ve been concerned about this. 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. How liable am I?

tpxl 4y ago
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.
- daoist_shaman 4y ago
  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.
  - tpxl 4y ago
    > I should not be liable for this 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
    - dylan604 4y ago
      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.
  - xani_ 4y ago

abraham 4y ago

It looks like GA is being loaded in the Pay iframe.

edwinwee 4y ago
(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.)
counttheforks 4y ago
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?
- jefftk 4y ago
  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.)
- deleted 4y ago
  [deleted]

tagawa 4y ago

Looks like Paddle does this as well: https://twitter.com/MrMooky/status/1570480546287071234 https://twitter.com/MrMooky/status/1570480546287071234

deleted 4y ago

[deleted]

ezekg 4y ago

It sucks that even a good Content Security Policy [0] can't stop an iframe from making these types of requests. [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

jefftk 4y ago
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.)

Kiro 4y ago

This non-issue is HN's chance to show they won't just automatically pick up the pitchforks on any "Big Tech bad" post.

hairofadog 4y ago

I would argue for replacing the word "with" with "into" in the headline here, so it's clear what's being injected into what.