Stealing From Google

Posted3 months agoActive3 months ago

dominikdoesdev

65 points

29 comments

taqib.devTechstory

controversialmixed

Debate

80/100

CachingProxyingGdprWeb Development

Key topics

Caching

Proxying

Gdpr

Web Development

The post discusses a technique for 'stealing' assets from Google by caching and proxying them, sparking debate about the ethics and technical implications of such an approach.

Snapshot generated from the HN discussion

Discussion Activity

Active discussion

First comment

Peak period

84-96h

Avg / period

5.8

Comment distribution29 data points

Loading chart...

Based on 29 loaded comments

Key moments

01Story posted
Sep 29, 2025 at 5:27 AM EDT
3 months ago
Step 01
02First comment
Sep 29, 2025 at 6:55 AM EDT
1h after posting
Step 02
03Peak activity
15 comments in 84-96h
Hottest window of the conversation
Step 03
04Latest activity
Oct 3, 2025 at 6:24 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (29 comments)

Showing 29 comments

DashAnimal

3 months ago

2 replies

This seems problematic to me. Beyond just caching issues, did you ever get permission from users to store their personal data? They gave google permission, but not you.

abraham

3 months ago

1 reply

The users are going through an OAuth flow and creating an account. Presumably they are agreeing to a ToS as part of that.

mattmanser

3 months ago

It even says in the OAuth flow that the company is requesting your profile image.

arcfour

3 months ago

1 reply

It's a public photo. What's wrong with downloading it?

yallpendantools

3 months ago

1 reply

Folks, read yourself some GDPR for the greater good. Even just https://gdpr-info.eu/art-4-gdpr/

Public data can be personal data and anyone doing the same as TFA is making itself a liable processor. But, aren't you a processor by using OAuth in the first place? Yes but with what TFA is doing you have a greater liability surface.

(IANAL but I cite GDPR because the broad concepts apply to data privacy laws in other jurisdictions. See also: https://en.wikipedia.org/wiki/Brussels_effect)

arcfour

3 months ago

I don't live in Europe, I will never travel to Europe, I don't plan to ever do business with Europe. I don't care if Europe sentences me to be shot into the sun for GDPR violations, it's not like I'm going to be extradited for it.

And I'm not aware of any law anywhere here that says I can't download a public photo. The use case is clearly valid and benign, the photo is public, there's no way a judge would go for that no matter how you twist the law.

mimsee

3 months ago

2 replies

If I wanted to achieve the same result, that is to serve assets of others from my own domain, I'd just create a custom endpoint like /api/user-avatar/:userId and an action proxies the actual image from google, maybe keep a cached copy for some time to not have to redownload the image on every request.

arcfour

3 months ago

Especially since, if you were doing this on CloudFlare—which you can with OpenNext—it's incredibly simple to work with CloudFlare's caches in Workers. For example: https://developers.cloudflare.com/workers/examples/cache-usi...

Plus there's their Images service which could come in handy to transform them a bit, too, if you wanted.

skylurk

3 months ago

This. Only needs a couple lines of nginx config.

dakiol

3 months ago

2 replies

I really didn't get what the post was about. I'm getting old or? And I thought I was clever because I work with distributed databases...

zaik

3 months ago

1 reply

The post assumes the reader is familiar with where things are happening and who is involved. Guess I'm not part of the target audience.

lozenge

3 months ago

Loading an img tag doesn't involve trusting a domain. Especially using crossorigin and refererpolicy attributes.

devmor

3 months ago

2 replies

The post seems to be written by a developer that has never heard of caching and thinks they have invented some illicit solution by implementing it.

It makes very little sense - They don't want to ask users to trust Google's domain despite... integrating the user's google account? What?

valiant55

3 months ago

1 reply

And in what way is this stealing? Caching a publicly available asset? Sounds like you are saving Google bandwidth/money.

devmor

3 months ago

Yes, quite the opposite. It did remind me of the old days though, when you could do the opposite and "hotlink" pictures from most websites and save yourself bandwidth costs!

vmenon401

3 months ago

1 reply

I think the point is that they’re avoiding whitelisting Google and Github domains which is necessary to preprocess images from and use urls to images to their domain in an Image tag. That allows malicious users to send urls such urls to his _next image preprocess endpoint and get “free compute”. (Not sure why someone would do that other than to just screw with somebody).

He’s using BetterAuth hooks to fetch those images and upload to his trusted url to avoid such a scenario.

devmor

3 months ago

That does make sense, but I'm not sure why it was worth sharing.

reaperducer

3 months ago

1 reply

Irony: Claim you're stealing from Google, then post it on a .dev domain, of which Google is the operator.

rjmorris

3 months ago

1 reply

They sold .dev to Squarespace a couple years ago.

reaperducer

3 months ago

Interesting. No mention of that on Wikipedia.

stephenlf

3 months ago

2 replies

> But there’s a catch: anyone can abuse your app to optimize their own images, which costs you compute.

Could anyone explain this?

samtheprogram

3 months ago

1 reply

The components work by requesting the image URL from your own server/API, at a route like `/_next/image`. The actual image URL that's passed as a prop to the component is passed to that API endpoint as a URL parameter.

So, the endpoint is essentially a proxy that does additional image processing, like compression and width/height resizing (again, a URL parameter that the Image component or any other client can change based on the device / screen size in use).

This means that without a domain whitelist, theoretically any image URL can be passed to the endpoint, which will then be processed and cached by your infra.

This has been used in the wild, e.g. racking up charges on someone else's Vercel bill by requesting a bunch of images through this endpoint.

DylanSp

3 months ago

Thanks for the explanation - I was deeply confused by this article's premise. I've never worked with Next.js or Astro, so I didn't have the background.

cantalopes

3 months ago

Imagine your app uses that Image tag to process image for some specific resolution/quality - just any processing done on your server for any imagw resource loaded via this tag.

Not sure how exactly it works, never used the framework, but i assume that when the frontend app detects this image tag it makes a server call to orocess it and rerurn optimized version.

Now, if someone were to insert such tag onto the frontend of your app and put in source of their own image, your server would do the processing of their image.

I have absolutely no idea in what universe would this be a practical attack of benefiting anyone at all

Edit: oh i see the coment by samtheprogram. I would think that the framework would use some form of csrf, this is a really weird implementation

efitz

3 months ago

Please post again when you get the cease and desist letter!

lelandbatey

3 months ago

Note to the developer: you may want to consider simplifying the CSS you're using to display the "clever" dot in the background of your page. On my computer, opening viewing your site in Firefox, scrolling the page has a nearly 2000ms delay caused by whatever is going on. This is improved but not fixed by disabling the `.bg-dot::before` background CSS property.

russianGuy83829

3 months ago

bitpush

3 months ago

Isn't this just passthrough caching with some persistence?

gryfft

3 months ago

Nice, but doesn't automatically update when the Google avatar changes. Cache invalidation strikes again.

View full discussion on Hacker News

ID: 45411799Type: storyLast synced: 11/20/2025, 12:32:34 PM

Want the full context?