Isn't this just passthrough caching with some persistence?
Stealing from Google
11–20 of 31 posts
Re: Stealing from Google
#12This 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.
The users are going through an OAuth flow and creating an account. Presumably they are agreeing to a ToS as part of that.
It even says in the OAuth flow that the company is requesting your profile image.
Re: Stealing from Google
#13I 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...
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?
Re: Stealing from Google
#14I 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...
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?
And in what way is this stealing? Caching a publicly available asset? Sounds like you are saving Google bandwidth/money.
Re: Stealing from Google
#15Irony: Claim you're stealing from Google, then post it on a .dev domain, of which Google is the operator.
Re: Stealing from Google
#16Note 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.
Re: Stealing from Google
#17> But there’s a catch: anyone can abuse your app to optimize their own images, which costs you compute.
Could anyone explain this?
Re: Stealing from Google
#18> But there’s a catch: anyone can abuse your app to optimize their own images, which costs you compute. Could anyone explain this?
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.
Re: Stealing from Google
#19I 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...
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?
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.
Re: Stealing from Google
#20> But there’s a catch: anyone can abuse your app to optimize their own images, which costs you compute. Could anyone explain this?
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