Hacker News new | past | comments | ask | show | jobs | submit login

This is good info, but Backblaze shouldn't even be using FB pixels to begin with.



I don't necessarily disagree with you, and whether a pixel should be there at all is definitely a discussion in itself.

But for those who are implementing FB Pixels, I wanted to put out some potentially useful information that can help protect against unintended data disclosure, after mentioning the auto-listener behavior in a reply to another comment and being met with surprise[1].

[1] https://news.ycombinator.com/item?id=26537078


Seems like it's designed to make it easy to accidentally send more of your users'/customers' data back to FB than intended. Oopsie!


Given their (paying) customer base, which skews more towards content producers, I suspect it's more likely intended to ease setup for less-technically-savvy users.

ie they don't really want your truly-security-critical customer data. But if they can boost their conversion rate with sites like dogfoodreviews.com by 5%, and the price is sending backblaze.com's fantastically-sensitive paid customer data into an unsecured data path, they will absolutely do it.

Comparable to the absolute havoc that Zoom wreaked on browser security to save one click on starting a call.


> I suspect it's more likely intended to ease setup for less-technically-savvy users.

> ie they don't really want your truly-security-critical customer data.

It's both. It eases implementation with a one-and-done snippet, and then slaps a user-friendly GUI on the other side for marketers to sort through the firehose and use what they want.

While making it also trivially easy for marketers to toggle a button that OKs the turbo-boost mode that siphons up (hashed) sensitive customer information, which can then be used to claim credit for additional conversions by cross-referencing the (hashed) PII siphoned up against what Facebook has for those exposed to your ads.


Literally every external privacy setting of fb across its entire business is designed that way.


Exactly. When the most important thing for a backup provider is the trust people put in you, don't do anything that risks that trust.


Edit: my biases against Facebook keep me from making cogent points.


This feels like an almost intentional misunderstanding.


Pixel tracking on an internal customer page... scanning and uploading metadata about users backups? How much am I misunderstanding?


> I guess they can’t afford to cover costs given current prices so they sell customer metadata to Facebook

This sentence, your thesis, is absurd. Where does it say they make money from selling data?

Furthermore, "I guess they can’t afford to cover costs given current prices" is a really strange foundation to leap from. Do you have any facts? Or are you just speculating on BackBlaze and making wild assumptions?

> now that other like-minded crazies can find each other faster than ever

You are right, there is nowhere else online where "crazies" gather - not 4chan, not reddit, not voat, not twitter, just Facebook?


Where does it say they make money from selling data?

What would be their motivation for just giving their customers data to Facebook for free?


Apparently it's incompetence, if they're unaware that they could have been making money on the deal.


The last point I’ll admit exposes my bias against Facebook.

But the previous two points make no difference on why tracking is baked into an internal portal so I speculated as to the reasoning as anyone would do — it’s not a stretch to think that data owners could sell customer data to an aggregator like Facebook for an additional line item of revenue.


Facebook does not, and never will, pay for data like this.


Which raises the question - why would anyone ever include a Facebook tracking pixel in their web page, if it provides no benefits, and has a cost?


> "if it provides no benefits"

Because it does? There are valid reasons for using the pixel in advertising.


> I guess they can’t afford to cover costs given current prices

This is plain wrong. One of the reasons I was a fan of B2 was their tech and how they achieved such low costs:

https://www.backblaze.com/blog/design-thinking-b2-apis-the-h...

https://www.backblaze.com/blog/backblaze-and-cloudflare-part...

While this FB pixel debacle is obviously a very big screw up, it's pretty much a "screw up" and unintentional from what I understand so far. And they have fixed it already which is a positive step towards redemption.

From my speculation - the screw up seems to have happened from including the googletagmanager. They probably only wanted it to stay on the home page of B2 (for ad conversion tracking if I were to guess), not on the dashboard itself after login. The screw up caused it to be on the dashboard too.


Why is that? Perhaps they get business value out of it?


If that business value destroys trust in their main business, that's a problem.


This is the thing that a lot of executives don’t ever seem to understand.


It looks like they’re about to lose a bunch of business value because of it.


Won't somebody please think of the business value???


That's how businesses make decisions.


> Backblaze shouldn't even be using FB pixels to begin with.

> Why is that? Perhaps they get business value out of it?

Oh, they get value out of invading my privacy? Carry on then!


Running and measuring ads is one of many things that delivers value to a business, yes. The privacy issue in this case is clearly an implementation mistake and seems to have been resolved.

Ignoring the situation and context to make a comical statement doesn't really add anything to the discussion.


The overwhelmingly mentality on HN is that All Ads are bad.

And all targeting Ads is bad. Because by their definition, All ads are tracking ads.

This mentality also fits the current Internet and Twitter narrative. Especially true when it is from Facebook. Which happens to be pure evil on HN, twitter sphere and MainStream Media.


> The overwhelmingly mentality on HN is that All Ads are bad.

Ads will at best waste my time/bandwidth/processing power and at worst compromise my privacy and/or convince me to make a bad financial decision.

I don't see why this mentality is wrong?


Ads are micropayments that work. I don’t like them per se and run an ad blocker and PiHole, but the fact that others don’t allows me to micropay for a lot of content with my time.


> Ads are micropayments that work.

One thing if those micro-payments end up enriching the creators, but another when blackholed into the coffers of a few tech cos.


Surely you meant to say:

> but the fact that others don’t allows them to micropay for a lot of content with their time.

I'm not objecting. I do the same. But in what sense are you paying? I'm sure I'm not.


When I read a 5 minute Medium article, I'm paying with 5 minutes of my time. If I decide to bail out 1 minute into the article, I have still lost 1 minute of my time.

The creator isn't getting any benefit from it, but I'm still paying.


> Because by their definition, All ads are tracking ads.

John Gruber has an ad at daringfireball.net, currently for a company called Simris. IIRC the ad is pure text, not loaded by a script, and does not track you. Other blogs (usually security professionals ime) have text-based ads that are probably part of the theme in a static site generator.


I should have put /s at the end of that sentence.

I know all of what you said, but somehow HN still thinks Ads are bad.


I assume they get business value by retargeting site visitors - to do this, just run the FB pixel (properly configured!) on a marketing pages of the website. Not in the logged-in part!


Why? Using ads to increase business is completely valid. This issue is data leakage due to an implementation error and has nothing to do with using advertising services from Facebook or other companies.


By this reasoning, using guns to shoot people is completely valid; the issue is stray shots due to inadequate aim and has nothing to do with being a criminal engaged in a drug war.

I'll resist the temptation to draw a parallel between "advertising services from Facebook or other companies" and a crime syndicate.


No, that's not the same reasoning at all. It's an irrelevant and outrageous strawman where you compared the use of advertising to "using guns ... as a criminal engaged in a drug war". Ridiculous at best and I'm not sure what temptation you resisted.

If you have a real rebuttal against advertising then reply with that instead and we can discuss how technical implementations can be fraught with security mistakes and errors, regardless of industry or product.


The point is that "technical implementations", such as how to shoot properly, shouldn't be discussed "regardless of industry or product", such as being a gangster: sharing PII with Facebook is something most web sites should avoid, not something they should do properly.


> "shouldn't be discussed"

Why not? Technical implementations can always be discussed separately from the context they're used in, and even your extreme example of guns has perfectly valid uses in the police and military. Yet you're making the strange comparison to being "a gangster". Why? What's the point of this convoluted analogy?

> "sharing PII with Facebook is something most web sites should avoid, not something they should do properly"

Again, why? You seem to claim a lot without any basis. Data has valid uses, and being used properly is foundational to providing privacy.


It shouldn't be controversial that not sharing sensitive data with Facebook is "foundational to providing privacy" and therefore using a Facebook tracker to fuck users needs a solid, extraordinary justification like "valid" gun use by the police and military.

You seem to believe that this particular breach is accidental, but reckless incompetence on Backblaze's part isn't much better than deliberate disregard for user privacy: any online service from Facebook should raise a red flag.


If you agree that the sensitive part was in error, then you're just against sharing data with Facebook for ads? That's certainly not some unanimous global perspective as I'm sure you know, since that's their actual business used by millions of other companies.


There are ways to use ads without violating privacy nor breaking the law (remember that this practice is illegal under the GDPR).

Either way, if you must do ad tracking, do so on your homepage. Once the user is logged in and has paid you money for a service there shouldn’t be any ads nor tracking.


> "without violating privacy"

Yes, that's covered by this being a mistake in implementation as I said.

> "there shouldn’t be any ads nor tracking"

Again, based on what exactly? Finding new users that are similar to your existing customers is a completely valid strategy.

Most people in this thread are making wild statements from the typical emotional/outrage driven pile-on when anything happens.


> Finding new users that are similar to your existing customers is a completely valid strategy.

What on earth does “valid” mean here? It’s certainly not acceptable (to me as a customer) if it involves exposing your existing customers to these risks. Those ends can not justify those means.


Valid as in it's a common, reliable and efficient way to gain new customers.

Customers weren't intentionally exposed to that risk nor was it part of a trade-off, it was an implementation mistake for many reasons, something I've repeated 3 times now. What is so complicated to understand here?


Customers were intentionally exposed to the risk, because they intentionally added this third-party code. If they’re not thinking in terms of risk management when they add third-party trackers to their site they do not have an adequate security process. There is a trade-off to security whenever you allow code like that in your product. They can’t just wave it off as a mistake, because it’s a mistake that is very telling about their priorities.


The mistake was allowing code into that specific part of the product.

Under your definition, there can never be mistakes at all; which is impossible.


It’s very simple: if you include un-vettable third-party code in your system, and system also handles sensitive data, you are dealing with a huge risk. You need to make sure that the code is unable to touch the sensitive data. As it turns out, it’s a lot harder than not having untrusted code and sensitive data in the same system in the first place. The direct mistake was probably that the wrong code was included on the wrong page, but if the risks involved had been taken seriously, such a small mistake would not have been able to have such a catastrophic effect.


Based on respect, common sense and the GDPR?

> Finding new users that are similar to your existing customers is a completely valid strategy.

But this can be achieved with tracking in the homepage without embedding trackers in the actual product right next to sensitive data?

> Most people in this thread are making wild statements from the typical emotional/outrage driven pile-on when anything happens.

This doesn't make these statements any less valid though? Most people are indeed outraged that a paid professional product is ratting them out to Facebook which makes total sense as nobody would've expected that.


> "But this can be achieved ... without embedding trackers in the actual product right next to sensitive data?"

Yes, it was an implementation mistake. How many times do I have to repeat that? See, this is the outrage that doesn't even read the actual comment.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: