Greasy Fork

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:

1. Do nothing. It's not a terrible problem - more like "slightly concerning".
2. Ban all remote images, make users upload their images to Greasy Fork. Breaks a lot of existing images, prevents the use the of badge-like things (showing build status or last commit or whatever).
3. Ban remote images generally, but with a domain allow list. Breaks less things, but now we'd have to decide what can be used and what can't. GitHub's probably trustworthy, but is Imgur or any other rando image hosting site?
4. Proxy the image requests. Stops per-user tracking, but probably breaks badges.
5. Combination of 3 and 4 - allow direct requests to trusted servers, but proxy everything else.

Any thoughts?

GitHub issue: https://github.com/greasyfork-org/greasyfork/issues/1494

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:

1. What criteria is applied to determine if servers are trusted?
2. 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.