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

推荐订阅源

小众软件
小众软件
WordPress大学
WordPress大学
IT之家
IT之家
G
Google Developers Blog
Vercel News
Vercel News
阮一峰的网络日志
阮一峰的网络日志
博客园 - 三生石上(FineUI控件)
Engineering at Meta
Engineering at Meta
Martin Fowler
Martin Fowler
V
V2EX
爱范儿
爱范儿
Hugging Face - Blog
Hugging Face - Blog
Apple Machine Learning Research
Apple Machine Learning Research
B
Blog
V
Visual Studio Blog
有赞技术团队
有赞技术团队
I
InfoQ
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
月光博客
月光博客
J
Java Code Geeks
Stack Overflow Blog
Stack Overflow Blog
P
Proofpoint News Feed
云风的 BLOG
云风的 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.