Discussions » Greasy Fork Feedback
Remote images on Greasy Fork
Yeah, Imgur and random ones are trustworthy for the most part.
We shouldn't do 2 or 3.
4 is ok if you are talking about letting users use whatever, then GF caches it, and serves the cached version, so tracking etc is automatically pointless in that case, and bad people doing that will stop. It breaks badges, but only if GF doesn't update the cached images/videos at least 1 time a day.
I personally don't care, but a lot of people already dislike the GF old interface. If it looks old and if now we push an update to break most of its images, GF will lose even more credibility, even though it's the only one and good userscript listing website.
If 4 is too hard or pointless to do, what we should do is create a new report option for those who care about it, so once they find a bad domain or user doing that, they report it. Then, if a domain is reported many times by different users, ban the image hosting domain. That way, I'm sure that trustworthy, popular sites like Imgur will never be banned.
3 is ok if the list initially covers most of the popular servers and there's a page linked nearby that lists all of them.
4 is ok if you are talking about letting users use whatever, then GF caches it, and serves the cached version
Yes.
create a new report option for those who care about it, so once they find a bad domain or user doing that, they report it.
There was a recent case where the script explicitly said their IP was logged by the image, but outside of that, I'm not sure how anyone would know.
Thank you for your reply.
Cool
Got it
I don't think that this topic and solutions really matter...
It's not like GF isn't already logging IP address anyway.
If someone brought this topic up to you, I think that the person is very concerned about privacy, while forgetting that GF needs some information too, and so does GitHub.
The image host I am using is na.cx.
Since it does not have a public interface to let you justify whether it is trustworthy or not, I am worried that all the images I used in GreasyFork will get disappear. (Images in UserScript Description, Images in Discussions, etc)
But anyway, this is the decision of GreasyFork.
Apart from the use of non-well-known image hosting services,
What do you want to do for those remote imaging is intentionally for dynamic content / tracking?
https://greasyfork.org/en/scripts/529453-twitter-x-media-downloader
What do you want to do for those remote imaging is intentionally for dynamic content / tracking?
This would be the "badge-like things" I refer to in my first comment. It's a consideration.
I am leaning towards option #5 - allow direct requests to trusted servers, but proxy everything else. Two questions I have with that:
- What criteria is applied to determine if servers are trusted?
- If an image is proxied, on what timeframe does it need to be refreshed?
The lifetime can be extracted from the image's HTTP caching headers. I wonder if your server can do transparent proxying so the users don't have to change anything i.e. your server replaces any foreign image link in the html of the script's description page with a link to your server's endpoint that makes the request to the original image using a cache on your server according to the original image's caching rules as indicated in its server response headers.
Regarding Option #5, I’m concerned about the size limit for proxied content.
There is currently a 400KB limit for images hosted directly on Greasy Fork, but external images are frequently larger. If the server begins to proxy and cache these, will they be subject to the same size constraints or undergo compression? If the goal is to move away from third-party hosts for privacy, we might need a better way to handle high-quality images natively.
I’m concerned about the size limit for proxied content.
Haven't thought about that yet. I'll have to run some numbers to see what size of images are being used.
I've set this live.
There is a short list of domains that are still allowed remote images. Proxied images are refreshed based on the cache headers in the request, or for one day, whichever is greater. Size limit is 5MB.
I've set this live.
There is a short list of domains that are still allowed remote images. Proxied images are refreshed based on the cache headers in the request, or for one day, whichever is greater. Size limit is 5MB.
Why is imgur blocked?
Well, first off, it's not "blocked", it's proxied. But basically I only put domains on the allowed list if I had a reason to, and I haven't seen a reason for imgur yet. Specifically, with imgur, I'm unsure about tracking and privacy.
Since proxied images can now be up to 5MB (compared to the 400KB limit for direct uploads), would it be possible to also increase the upload limit on Greasy Fork to 5MB? This would provide a more stable way to host larger images without relying on third-party services.
imgur usually does not allow direct image link. It wants you to access their webpage to view the image.
I think for imgur, you need to convert it to web page link instead of proxy it.
https://i.imgur.com/EgAVHxy.jpeg
should convert to
That's not true. I always use the direct image links they provide and they work and load fine, much better than GitHub that only tries to download stuff. Imgur should totally be in the approved image sites list. Currently it feels like only GitHub is approved, which is just sad.
Now gf should alert when an unapproved website is in a script description or any post in gf, and also if the external image is over 5mb.
It's very hard to know about this gf change unless a site wide notification is issued.
Also, it will just be harder now to figure out and remember to do it every single time (check the image size) for embeds in gf.
Embedded images are mostly used here only to bypass the super small limitation that gf has, but now even external GitHub images have their size limited...
Life got twice harder now.
Life got twice harder now.
You can still use imgur images; they will just be transparently proxied. Can you explain what exactly is harder?
even external GitHub images have their size limited
They don't. GitHub is on the allow list.
It's very hard to know about this gf change unless a site wide notification is issued.
I intend to document this, and perhaps add some notifications if you go over the limit, but I want to finalize the behaviour before doing so.
My imgur images don't load in my script descriptions anymore.
What's the 5mb limit for then?
I thought that it applied only to external images in the approved list.
Oh that sounds perfect then! I'll be waiting and excited for it then!
For images on the domains in the approved list, there is no restriction, just like before.
For things on other domains, they are proxied, and there is a 5MB limit. If they pass the limit, they will not be included on the page. When I ran the numbers, there were only 20 uses across the whole site of images larger than 5MB.
If there are pages where an image was loading and now isn't, please let me know, and I'll take a look at the cause.
Good to know.
Look at my AI everywhere script description.
Link? I tried to Ctrl-F it in your user page but I don't see anything called "AI Everywhere".
just use https://tinypng.com/ to compress the images
> 5MB is not user-friendly. People with low bandwidth (slow network) will suffer.
Link? I tried to Ctrl-F it in your user page but I don't see anything called "AI Everywhere".
I think he is referring to https://greasyfork.org/en/scripts/419825-aigpt-everywhere
5MB is not user-friendly. People with low bandwidth (slow network) will suffer.
There's a balance to be made here between people with slow connections and authors who want high-quality images. I just chose 5MB because I need to put some limit, and very few existing images went over 5MB. It may be adjusted in the future.
BTW, I increased the image upload size limit to 1MB. I didn't want to go all the way to 5MB because again, that limit on external images may be adjusted. We'll see how it goes.
The link was shared previously.
Let me know what the issue is.
BTW, I increased the image upload size limit to 1MB. I didn't want to go all the way to 5MB because again, that limit on external images may be adjusted. We'll see how it goes.
Thanks for the update. Increasing the native limit to 1MB is a significant improvement over the previous 400KB.
I agree that a higher limit encourages native uploads, which is much better for long-term stability. However, I’ve found that in common scenarios—such as uploading full-screen screenshots or recording GIFs to demonstrate script features and reproduction steps—my files often exceed 1MB quite easily. This is usually why I turned to external hosts in the first place.
I’m curious, do you have any data on what percentage of existing external images are currently under 1MB? It might be interesting to see how many users would be able to fully migrate to native uploads with the new limit.
Anyway, I understand the need to monitor the server impact first and see how it goes. Thanks for being open to these adjustments.
I've set this live
Now every script that had such images as part of the description has those images hidden, without any notification to the script authors. What a mess
You can still use imgur images; they will just be transparently proxied. Can you explain what exactly is harder?
How do I do that? This string in my descriptions doesn't seems to be working: 
If there are pages where an image was loading and now isn't, please let me know, and I'll take a look at the cause
The link was shared previously.
Let me know what the issue is.
https://greasyfork.org/en/scripts/419825-aigpt-everywhere
- https://github.com/cyber-sec0/cyber-sec0.github.io/blob/main/UserScripts/Imgs/AIGPT%20Everywhere/1%204.gif?raw=true - allowlisted
- https://github.com/cyber-sec0/cyber-sec0.github.io/blob/main/UserScripts/Imgs/AIGPT%20Everywhere/2.png?raw=true - allowlisted
- https://www-static-sites.operacdn.com/wp-content/uploads/sites/2/2018/02/previous.gif - proxied, loads fine for me
- (All other images under "Mouse Gestures" - same as above)
- https://github.com/cyber-sec0/cyber-sec0.github.io/blob/main/UserScripts/Imgs/AIGPT%20Everywhere/3.png?raw=true - missing!
- https://github.com/cyber-sec0/cyber-sec0.github.io/blob/main/UserScripts/Imgs/AIGPT%20Everywhere/1%204.gif?raw=true - missing!
What does missing mean?
How come https://github.com/cyber-sec0/cyber-sec0.github.io/blob/main/UserScripts/Imgs/AIGPT%20Everywhere/1%204.gif?raw=true is allowlisted and missing at the same time?
I see these now. I'm not sure if there's some flakiness happening or what.
Oh...
Yes, there's something happening...
When I used Imgur, nothing loaded, so I was having the same issue as Konf.
Looks like nearly all imgur images are failing with 429 - likely imgur's rate limiting. I'll see if there's anything I can do about that.
It seems to work by IP address so having Greasy Fork pull those images isn't going to work. I've added imgur.com to the allow list.
This was by far the domain that had the most failures at ~4000. The next highest one is ~300 failures, and it looks like a site that is legitimately down. Checking a few more, it seems like they're sites that are down or other kinds of errors like 404.
I've added imgur.com to the allow list.
GF server failed to fetch the image because it tracks users' IP, then you just whitelist it lol
So doing this on almost everything ends up being more costly than I can allow, so what I'm doing for now is adding popular image hosting sites to the allow list so they are not proxied. This is a compromise from my original intention, but still maintains the benefit of avoiding tracking from most servers.
The list of allowed domains can be seen at https://github.com/greasyfork-org/greasyfork/blob/main/app/models/proxied_image.rb
Since the servers being allowed are the most widely used and popular ones, the vast majority of tracking activity is actually being permitted. The "most servers" whose tracking is blocked account for only a small fraction in reality.
Furthermore, less popular image hosting servers that go through the proxy still suffer from reduced availability due to errors such as 429 — these issues do not disappear simply because the sites are not popular.
This approach improves privacy only marginally, yet comes at the cost of a slight reduction in usability. In my opinion, aside from increasing code complexity and server load on Greasy Fork, it is almost equivalent to doing nothing at all. Is this really the outcome we intended to achieve?
In reality, this issue has long existed across all forums, discussion boards — any platform that allows the use of externally linked images. Take email as an example: senders or service providers insert an <img> tag pointing to a specific server endpoint in the HTML to track when a user opens and reads the email, how many times it is opened, and the user’s IP address — this is egregious tracking that clearly violates privacy, yet it is universally prevalent. However, some privacy-focused email clients offer an option to block image loading by default, unless the user actively clicks to load them. To view the images, the user must accept being tracked, but the final decision to view them rests with the user — not the sender or the email client.
Likewise, I believe this same design principle could be applied to images on forums or discussion boards. Using externally linked images is a legitimate user need and should be permitted; however, whether and how to load these images should be decided by the user viewing them. An option could be added to account preferences, allowing users to select from:
- Do not load externally linked images (or only load those from trusted domains such as GitHub)
- Attempt to load images via the Greasy Fork server proxy (and accept the risk of loading failures)
- Load images directly from the browser (and accept tracking by third-party servers)
Providing a proxy to prevent tracking is a sound idea, but I believe it should be a service offered to privacy-conscious users — not a policy mandatorily enforced for certain built-in domains.
The original trigger for all of this was an author who put an image in their description that dynamically showed the user's IP address. It's not the fact that it was showing the IP address back to the user that was the problem, but the realization that someone could find out individual users' IPs especially in low-traffic scripts. The idea to stop this then expanded to the idea of preventing the kind of corporate tracking that image hosting sites do.
The original implementation was to prevent both the highly targeted tracking and the corporate tracking. The first compromise came from the realization that imgur put in technical blocks to prevent proxying images. The second compromise came from the fact that financial cost of the bandwidth was too great.
So right now we're still stopping the highly targeted tracking and most of the corporate tracking ("most" meaning most domains and not most traffic). It remains to be seen if the compromises reduce the costs to still make it worth it. So maybe it'll stay how it is, or maybe I'll toss it all.
I'm not going to be adding settings to the site to control this. It seems much more suited to a browser-based setting or an extension so that it could be applied to all sites.
Having a short allow list of domains that didn't need to be proxied didn't really help with the bandwidth aspect of this. I've had to turn off proxying unless I can come up with a better solution.
I thought the bandwidth cost of proxying remote images would be comparable to that of images hosted by Greasy Fork, but it turns out it was ~30x higher.
@JasonBarnabe, whitelist the most used image host servers that don't provide client tracking to the uploader and add a button/link to the script upload form to request allowing a new server (it can be a link to the forum).
The bandwidth requirements barely went down when I added the top ten most used image hosts. It's a long tail.
And as discussed previously, I don't know which image hosts don't track users.
My idea was that tracking capability can be verified by making an account on that site and checking if it provides an API or UI to view the incoming requests.
@woxxom Maybe they (the company/administrator behind that image server) just do tracking silently, and does not provide tracking data to image posters.
Any server analyses access but this isn't the problem that greasyfork is trying to solve, which is a script author's ability to track users via images.
Any server analyses access but this isn't the problem that greasyfork is trying to solve
Europeans always think about GDPR
JasonBarnabe [Mod]:
I've set this live.
There is a short list of domains that are still allowed remote images. Proxied images are refreshed based on the cache headers in the request, or for one day, whichever is greater.
{I've never done this before: tagged a developer to a discussion. If s/he wants to ignore the discussion, I fully respect that. Also, if s/he wants this post removed, I give my agreement right here.}
@Owyn : I know this is a most-unusual request - do you want to comment on which hosting services might meet JB's design requirements? I thought of you as a potential expert on the topic, given your multi-year(decade?) Handy Image project. (Plus this shoutout is my totally sincere praise of your work!)
Currently, Greasy Fork allows remote images in script descriptions, forum comments, user profiles, etc. to be loaded over HTTPS. Doing this actually allows for a level of tracking of Greasy Fork users on the server that hosts the images. It can track normal HTTP things like IP address, user agent, etc.
A few options for dealing with this:
Any thoughts?
GitHub issue: https://github.com/greasyfork-org/greasyfork/issues/1494