惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Blog — PlanetScale
Blog — PlanetScale
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Vercel News
Vercel News
B
Blog
腾讯CDC
P
Proofpoint News Feed
Google DeepMind News
Google DeepMind News
N
Netflix TechBlog - Medium
L
LangChain Blog
F
Fortinet All Blogs
T
The Blog of Author Tim Ferriss
人人都是产品经理
人人都是产品经理
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
I
InfoQ
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
D
DataBreaches.Net
Stack Overflow Blog
Stack Overflow Blog
The Cloudflare Blog
Last Week in AI
Last Week in AI
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 三生石上(FineUI控件)
T
Tailwind CSS Blog

Feed of "schmarty/gem-diamond"

issue when using indieauth[dot]com? gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond gem-diamond
proxy for profile images
schmarty · 2024-10-14 · via Feed of "schmarty/gem-diamond"

Thanks to https://riv.ar/ for reaching out and the following nice pro/con list!

If you visit the directory at https://xn--sr8hvo.ws/directory, pictures are hot-linked to wherever the hCard points to. I think it'd be an improvement to serve them from a first-party origin, for these reasons:

  1. Privacy: Anyone viewing the directory is making requests to 187 different origins. While I'd hope most of the sites that participate are privacy-conscious, this is an opportunity for tracking.
  2. Performance: The relevance of this point depends on how it's implemented, but basically I could have a profile picture that's way oversized for the directory (say, 2048px×2048px). Resizing pictures down to a reasonable size could improve load times. The other performance benefit (albeit a weaker point) is that if the pictures are cached, the performance loading pictures would be consistent, instead of depending on each individual host.
  3. Hotlinking protection: Many sites don't allow hotlinking for different reasons. While one could set up an exception for specific sites, it's an extra configuration step that may not always be easy. This also has the effect on visitors of showing a broken image.

Now, for points against this:

  1. Work needed: The obvious one, making changes requires putting up work.
  2. Bandwidth: I realise this suggestion could increase your bandwidth / traffic use.
  3. Ongoing complexity: A simple solution would be just a proxy to load the image, which isn't too complex. However, implementing a cache with resizing adds more moving pieces that need to be maintained and cared for.

And one more consideration:

One thing I though of (more of a con) is that some images are animated, and I'm not sure how good the PHP libraries are for handling those (e.g., if you were to resize them), but in the worst case they can be left untouched.

I'll add: One extra "pro" reason - some folks link to an http:// URL for their image, which browsers refuse to load because it would mix https/http content.

I don't want to rely on a third-party service for this, so I need to think about what shape an implementation would take.

Thanks to https://riv.ar/ for reaching out and the following nice pro/con list! > If you visit the directory at <https://xn--sr8hvo.ws/directory>, pictures are hot-linked to wherever the hCard points to. I think it'd be an improvement to serve them from a first-party origin, for these reasons: > > 1. Privacy: Anyone viewing the directory is making requests to 187 different origins. While I'd hope most of the sites that participate are privacy-conscious, this is an opportunity for tracking. > 2. Performance: The relevance of this point depends on how it's implemented, but basically I could have a profile picture that's way oversized for the directory (say, 2048px×2048px). Resizing pictures down to a reasonable size could improve load times. The other performance benefit (albeit a weaker point) is that if the pictures are cached, the performance loading pictures would be consistent, instead of depending on each individual host. > 3. Hotlinking protection: Many sites don't allow hotlinking for different reasons. While one could set up an exception for specific sites, it's an extra configuration step that may not always be easy. This also has the effect on visitors of showing a broken image. > > Now, for points against this: > > 1. Work needed: The obvious one, making changes requires putting up work. > 2. Bandwidth: I realise this suggestion could increase your bandwidth / traffic use. > 3. Ongoing complexity: A simple solution would be just a proxy to load the image, which isn't too complex. However, implementing a cache with resizing adds more moving pieces that need to be maintained and cared for. And one more consideration: > One thing I though of (more of a con) is that some images are animated, and I'm not sure how good the PHP libraries are for handling those (e.g., if you were to resize them), but in the worst case they can be left untouched. I'll add: One extra "pro" reason - some folks link to an `http://` URL for their image, which browsers refuse to load because it would mix `https`/`http` content. I don't want to rely on a third-party service for this, so I need to think about what shape an implementation would take.