Hacker News Reader

Comment by cosmie | Hacker News Reader

Read the privacy policy[1].

Think of Giphy images as a giant, organically shared version of web tracking software. Which complements the coverage of the FB Pixel[2] well, as it worms its way into privacy-conscious areas they might not have FB Pixel coverage such as private communications and security/privacy-minded apps. And without implementing something like a proxy server to pre-cache/sanitize images and strip tracking identifiers in both directions, it's a tracking vector that's hard to keep out of your app without introducing user friction.

Given that cynical viewpoint, the valuation makes a ton of sense.

[1] https://support.giphy.com/hc/en-us/articles/360032872931-GIP...

[2] https://www.facebook.com/business/help/742478679120153?id=12...

View on HN

Woah, that's a great point. Imagine sharing a gif in Signal and still being tracked by Facebook because every person that loads it needs to first download it from FB servers.

It really is getting to the point that if you want privacy, don't touch anything owned by the top 5 tech companies. Better yet, only use Open Source. I never used to be a OSS only person, but the past few months I've started to go that way.

>Imagine sharing a gif in Signal and still being tracked by Facebook because every person that loads it needs to first download it from FB servers.

Signal's integration is specifically engineered to _not_ do this: https://signal.org/blog/signal-and-giphy-update/

From Giphy's end they can still so useful traffic analysis by generating a unique URL for the search result obtained by User A and subsequently sent to his chat cohort. Each cohort app retrieving the same URL could then be enumerated. It's not user-identifying but it would generate a sort of contact graph.

Also the Signal service could do a transparent TLS MitM between the app and Giphy instead of a passthrough TLS tunnel and the user apps would be unaware. In fact from that page I'm not sure they're even doing a tunnel anyway.

nice try, but this wouldn't work

> Given that cynical viewpoint

I wouldn't even call that cynical. It's just the state of things.

It absolutely is cynical. Just another "If you're not paying for it, you're not the customer; you're the product being sold."

What you're describing with that quote isn't cynicism. Especially as far as FB is concerned. That is absolutely business as usual for them and has been for years.

While you aren't wrong, in this day and age it's not enough to simply pay. Even if you pay for something, you are still the product being sold. Why would a company leave money on the table, when violating people's privacy is profitable and there is no backlash?

Ethics?

In a society which doesn't care enough and a legal system that doesn't punish unethical behaviour any company tapping unethical revenue streams in addition to the ethical ones will have a competitive advantage and given otherwise similar conditions eventually outperform ethical companies. Once a sole actor goes down that path it puts a lot of pressure on all other actors to throw ethics overboard as well as otherwise their company's survival and in extension their livelihood will be threatened. This is why we can't just rely on market forces sorting everything out, consumers making decision, etc. but have to actively legislate to protect our privacy and personal rights.

It's not this day and age. Analytics and data mining of customers data is as old as business. 2000 years ago merchants were also tracking who's buying what, in what city, what time of the year, etc.

It's waaaaay more efficient nowadays and way more creepy, but it's not a new invention.

Just because you've heard it before doesn't make it false. I hope your naivete represents a minority perspective.

"Cynical" usually implies an element of assuming the worst when such an assumption is far from certain. In this case I think the assumption is spot-on and not at all surprising.

Does the fact that it is integrated into iOS keyboard have any implications? WlWhat kind of data does this have access to when I send gifs from iOS keyboard?

Google messenger (the default texting app) has a gif search that includes giphy, and Discord and slack also use giphy. What I don't see is what data FB is getting when the gif loads. OK, so they can see I am using giphy in Discord. Now what?

edit: apparently wrong/outdated information.

I'm fairly sure this is False. GBoard uses Tenor (the next largest Giphy competitor), which Google also happens to have bought 2 years ago (undisclosed amount of money). I also just tested Messages and can confirm that the results look like Tenor too.

For Discord, while they initially used Giphy and has a /giphy command, it now uses Tenor too in the GIF picker.

The only difference with this acquisition and Discord is that Discord might now start proxying Giphy (they previously didn't to save bandwidth).

Again, Discord uses Tenor, not Giphy (unless you manually use /giphy instead of the GIF picker, which most people don't).

Hypothetically speaking, fb gets a request for an image for each person in a chat at roughly the same time. Now they know know what chat platform you're using and who is participating in the chat. I'd venture a guess those participant identities could be de-referenced with data collected from their various [other] trackers. Now they can extend their social graph to include communication patterns on 3rd party platforms.

They can also see that you use Discord, as well as how often and how heavily. And potentially other facets that can be derived from whatever metadata is provided to Facebook in the course of serving that image request.

There's also all kinds of shenanigans that they can play in the process of serving that request to harvest other meta data and help fingerprint you. Which Giphy's privacy policy mentions is already done to an extent, in the form of dropping cookies while servicing your request. Cookie abuse itself is a bit of a losing battle, as browser vendors increasingly layer on limitations and restrictions for cookies. But they're far from the only method of fingerprinting possible during the servicing of a web request.

iOS keyboards given “full access” in settings can see literally everything you type. That’s why I don’t use GBoard on my iPhone, also why I don’t enable “enhanced spellcheck” in Chrome.

Hmm, I guess I know why SwiftKey became free. Probably want to check on their privacy policy now

swiftykey (now owned by MSFT) is terrible as it is constantly trying to call back to microsoft services, even with all "personalization" disabled. I've got my phone locked down with multiple "blocks" I can see it constantly trying to phone home.

It's behavior is no different from Windows 10 telemetry. The keyboard does not even work if you disable one of the underlying telemetry services in the app (if you have a rooted device).

Not sure if the iOS keyboard uses Giphy. I get very different results searching for the same things in the keyboard and on the Giphy website.

proxy server to pre-cache/sanitize images and strip tracking identifiers in both directions

Developing such a tool might be valuable for privacy-conscious application developers.

Google already does it with Gmail[1][2], so it's not unheard of. But it adds another layer of complexity, plus is somewhat antithetical to the privacy viewpoint as it then exposes all of the images to the app developer now since it's routed through the proxy server instead of direct end-user -> image server requests.

[1] Can't find a page specifically detailing it, but [2] gives a basic synopsis on it in the context of allowing GSuite admins to whitelist internal domains from routing through the proxy.

[2] https://support.google.com/a/answer/3299041?hl=en

> it then exposes all of the images to the _app developer_

Not if the app developer proxies the encrypted traffic.

That way the app dev does not know the content and the third party does not know which original IP requested it.

This is akin to the Signal-Giphy implementation.

Keen analysis, thank you.

Paraphrasing: emojis serving as web bugs.

https://en.wikipedia.org/wiki/Web_beacon

I'm still dubious. Giphy hit it's peak of power 2-3 years ago and has plateaued or even tapered since then. It was all over reddit and Slack for a while and then the novelty wore off and competitors popped up.

... which might be what made it cheap enough to be snapped up by Facebook. Who knows, maybe the valuation of giphy would have been much larger 2 to 3 years ago.

Acquisitions often happen after some value is lost from the company being acquired, like when Microsoft bought Nokia or when Yahoo bought Tumblr.

Won't that tracking capability be going away pretty soon?

Cookie-based tracking, sure. But there are plenty of other avenues for fingerprinting. This[1] help doc from Adobe Analytics even makes reference to a Subscriber ID header you can get mobile carriers to give you, if you get onto the carrier's whitelist. Nothing the vendors do device/browser-side to restrict tracking will help if your mobile carrier is transparently appending an identifying header to your request after it leaves your phone.

[1] https://docs.adobe.com/content/help/en/analytics/technotes/v...

This doesn't work for SSL enabled websites, right?

I'm really not certain, as I've never seen an implementation that involved it. There was a lot of stink about it 5 years ago[1], which called out the exact argument of it not working for HTTPS traffic. Which, is a substantially larger portion of traffic now than it was at the time.

But you still see nondescript references to the capability in places like that that up-to-date Adobe Analytics doc, and the carriers aren't trying to use legal means (a la lobbying) to slow down the uptick in HTTPS traffic and preserve their revenue stream. Which leads me to presume they've developed technical solutions that are compatible with HTTPS traffic. They can't really use the spray-and-pay method[2] they were using. But all bets are off when they destination site and the carriers are coordinating with each other, as that coordination can involve technical modifications to facilitate it in addition to just the whitelisting itself.

[1] https://www.ghacks.net/2015/08/31/are-mobile-carrier-injecte...

[2] Some carriers would inject a header into all traffic, and any interested party could slurp them up. But you'd have to pay the carrier to access any of the other information the carrier had for that particular identifier.

I don't know enough about TLS < 1.3. In TLS 1.3, the whole handshake on both sides is covered by the handshake completion --- if the client handshake was modified in the middle, the client will not accept the server handshake completion.

However, that doesn't stop carriers from inserting something at the start of the stream that the client doesn't see. It would need to be coordinated with the origin server, but that's already true for HTTP header insertion. Sending a pre-handshake blob to a TLS server that isn't expecting such a blob would fail hard though, rather than going on its merry way like an extra header usually would.

Reply on news.ycombinator.com