4 ms·

Privacy Update: Third-party Tracking

175 points by busymom0 5y ago

ccmcarey 5y ago
HN thread about the original issue: https://news.ycombinator.com/item?id=26536019 https://news.ycombinator.com/item?id=26536019
- dang 5y ago
  Also Backblaze Privacy Update: Third-Party Tracking - https://news.ycombinator.com/item?id=26550506 https://news.ycombinator.com/item?id=26550506 - March 2021 (69 comments)
vineyardmike 5y ago
Its refreshing to the BB actually continue the investigation and share data with the public regarding the incident. I hope to see a blog post on HN sharing what they've done and concluded from their review of 3rd party JS. Hopefully the conclusion is that its best to just purge FB from the site entirely.
anitil 5y ago
It's a bit embarrassing to have this happen, but I can't throw stones about configuration causing issues like this. Addressing it publicly like this (identifying exactly what was shared, who was impacted etc) builds a lot of trust. No denial or fobbing off, just clear communication.
- magicalhippo 5y ago
  > I can't throw stones about configuration causing issues like this. True, such misconfigurations are bound to happen. That's why it's so worrying that they thought it was OK to have a third-party script injector on the signed-in pages to begin with. I see now that they've removed Google Tag Manager from those pages, however they're still fairly opaque about preventing such a glaring security and privacy issue from happening again. Not a customer, however I was seriously considering switching to B2 for my backups before this happened. This post does very little to make me want to pursue that further.
tgsovlerkhgsel 5y ago
I think this is a great example of how to handle such a mistake, and it makes me trust Backblaze more (yes, I am aware of https://en.wikipedia.org/wiki/Service_recovery_paradox https://en.wikipedia.org/wiki/Service_recovery_paradox - I'm more likely to trust a company that admits mistakes, because it makes it less likely that they are hiding other, potentially worse mistakes and I'm more likely to be transparently informed when something that affects me goes wrong). I was a bit surprised that I didn't see something like "we're working with Facebook to delete any copies of the data Facebook may be storing".
- stevefolta 5y ago
  > I was a bit surprised that I didn't see something like "we're working with Facebook to delete any copies of the data Facebook may be storing". The email they sent to affected users says this: > Facebook is obligated to only process information based on our instructions and we have instructed them to not further process this data and to delete it. I still think it's sketchy that they used the Google code at all, and I think they should have immediately deleted that from all their pages.
  - eli 5y ago
    It’s sketchy that they used google tag manager? It’s a useful and extremely common tool on marketing sites. Putting it on user pages was a mistake.
    - protomyth 5y ago
      It's sketchy they do not have separate repositories for user pages vs marketing pages. With the obvious sensitivity of user data, mixing very different applications seems unwise.
      - lamontcg 5y ago
        "Additionally, we’re continuing to evaluate steps to help ensure that such an issue does not occur again" most likely covers stuff like that.
okdjnfweonfe 5y ago
unexpected but very appreciated. Also appreciated that GTM is being removed from private pages all-together.
dannyw 5y ago
I was one of the critics and I definitely trust backblaze more after the transparency, communication, and seriousness shown here. Will check out B2 for our backups sometime :)
drexlspivey 5y ago
I suggest blocking all facebook domains via DNS/hosts etc. Even if you don't use FB they collect data about you from crap like this.
- sen 5y ago
  I’ve done this for years and can’t remember a time a website hasn’t worked (other than FB of course, no loss there).
pentagrama 5y ago
If you use Google Tag Manager on a page, but don't add any Google tracking codes on it (eg Google Analytics), the page sends data to Google? Any OSS self-hosted Google Tag Manager alternative to recommend?
- lmkg 5y ago
  If a GTM container loads on a page but is not configured to fire any tags on that page, then the only request that will be made to Google servers is the one that loads the (empty) Container. While this request might end up in a logfile, the "interesting" data is limited. In particular, GTM is served from a different domain than any other Google properties so even third-party cookies couldn't be used to tie the request to your identity. Not sure about OSS alternatives. I know of a few competitors (Adobe Launch, Ensighten, Tealium), but they're all commercial. I don't expect there's a large market, the key value proposition of tag management platforms is cutting down coordination overhead between the marketing and IT teams, and self-hosting is the opposite of that. However the trend towards first-party tracking may open a market for it.
  - Nextgrid 5y ago
    > even third-party cookies couldn't be used to tie the request to your identity Google has enough visibility on the internet to be able to correlate mere IP addresses with high accuracy. IP addresses are also still considered PII under the GDPR.
deleted 5y ago
[deleted]
kevingrahl 5y ago
I’m not happy with how Backblaze handled informing affected users at all. They were aware of it on March 21 and said that they “were preparing a communication with affected users at that time”. I received an email about that only yesterday. That’s 52 days it took them to write me an email which imo just isn’t good enough and afaik does not conform with the GDPR requirements for data breaches.
- bastawhiz 5y ago
  It sounds like the data leaked was not PII, which is outside the scope of GDPR personal data breach guidelines.
  - magicalhippo 5y ago
    Filenames were leaked, which could very well contain PII.
  - Nextgrid 5y ago
    Something as simple as an IP address (which you're implicitly leaking by just loading any resource from the third-party domain) is considered PII under the GDPR.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

175 points by busymom0 5y ago

HN thread about the original issue: https://news.ycombinator.com/item?id=26536019 https://news.ycombinator.com/item?id=26536019

dang 5y ago
Also Backblaze Privacy Update: Third-Party Tracking - https://news.ycombinator.com/item?id=26550506 https://news.ycombinator.com/item?id=26550506 - March 2021 (69 comments)

vineyardmike 5y ago

Its refreshing to the BB actually continue the investigation and share data with the public regarding the incident. I hope to see a blog post on HN sharing what they've done and concluded from their review of 3rd party JS. Hopefully the conclusion is that its best to just purge FB from the site entirely.

anitil 5y ago

It's a bit embarrassing to have this happen, but I can't throw stones about configuration causing issues like this. Addressing it publicly like this (identifying exactly what was shared, who was impacted etc) builds a lot of trust. No denial or fobbing off, just clear communication.

magicalhippo 5y ago
> I can't throw stones about configuration causing issues like this. True, such misconfigurations are bound to happen. That's why it's so worrying that they thought it was OK to have a third-party script injector on the signed-in pages to begin with. I see now that they've removed Google Tag Manager from those pages, however they're still fairly opaque about preventing such a glaring security and privacy issue from happening again. Not a customer, however I was seriously considering switching to B2 for my backups before this happened. This post does very little to make me want to pursue that further.

tgsovlerkhgsel 5y ago

I think this is a great example of how to handle such a mistake, and it makes me trust Backblaze more (yes, I am aware of https://en.wikipedia.org/wiki/Service_recovery_paradox https://en.wikipedia.org/wiki/Service_recovery_paradox - I'm more likely to trust a company that admits mistakes, because it makes it less likely that they are hiding other, potentially worse mistakes and I'm more likely to be transparently informed when something that affects me goes wrong). I was a bit surprised that I didn't see something like "we're working with Facebook to delete any copies of the data Facebook may be storing".

stevefolta 5y ago
> I was a bit surprised that I didn't see something like "we're working with Facebook to delete any copies of the data Facebook may be storing". The email they sent to affected users says this: > Facebook is obligated to only process information based on our instructions and we have instructed them to not further process this data and to delete it. I still think it's sketchy that they used the Google code at all, and I think they should have immediately deleted that from all their pages.
- eli 5y ago
  It’s sketchy that they used google tag manager? It’s a useful and extremely common tool on marketing sites. Putting it on user pages was a mistake.
  - protomyth 5y ago
    It's sketchy they do not have separate repositories for user pages vs marketing pages. With the obvious sensitivity of user data, mixing very different applications seems unwise.
    - lamontcg 5y ago
      "Additionally, we’re continuing to evaluate steps to help ensure that such an issue does not occur again" most likely covers stuff like that.

okdjnfweonfe 5y ago

unexpected but very appreciated. Also appreciated that GTM is being removed from private pages all-together.

dannyw 5y ago

I was one of the critics and I definitely trust backblaze more after the transparency, communication, and seriousness shown here. Will check out B2 for our backups sometime :)

drexlspivey 5y ago

I suggest blocking all facebook domains via DNS/hosts etc. Even if you don't use FB they collect data about you from crap like this.

sen 5y ago
I’ve done this for years and can’t remember a time a website hasn’t worked (other than FB of course, no loss there).

pentagrama 5y ago

If you use Google Tag Manager on a page, but don't add any Google tracking codes on it (eg Google Analytics), the page sends data to Google? Any OSS self-hosted Google Tag Manager alternative to recommend?

lmkg 5y ago
If a GTM container loads on a page but is not configured to fire any tags on that page, then the only request that will be made to Google servers is the one that loads the (empty) Container. While this request might end up in a logfile, the "interesting" data is limited. In particular, GTM is served from a different domain than any other Google properties so even third-party cookies couldn't be used to tie the request to your identity. Not sure about OSS alternatives. I know of a few competitors (Adobe Launch, Ensighten, Tealium), but they're all commercial. I don't expect there's a large market, the key value proposition of tag management platforms is cutting down coordination overhead between the marketing and IT teams, and self-hosting is the opposite of that. However the trend towards first-party tracking may open a market for it.
- Nextgrid 5y ago
  > even third-party cookies couldn't be used to tie the request to your identity Google has enough visibility on the internet to be able to correlate mere IP addresses with high accuracy. IP addresses are also still considered PII under the GDPR.

deleted 5y ago

[deleted]

kevingrahl 5y ago

I’m not happy with how Backblaze handled informing affected users at all. They were aware of it on March 21 and said that they “were preparing a communication with affected users at that time”. I received an email about that only yesterday. That’s 52 days it took them to write me an email which imo just isn’t good enough and afaik does not conform with the GDPR requirements for data breaches.

bastawhiz 5y ago
It sounds like the data leaked was not PII, which is outside the scope of GDPR personal data breach guidelines.
- magicalhippo 5y ago
  Filenames were leaked, which could very well contain PII.
- Nextgrid 5y ago
  Something as simple as an IP address (which you're implicitly leaking by just loading any resource from the third-party domain) is considered PII under the GDPR.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]