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

推荐订阅源

F
Fortinet All Blogs
云风的 BLOG
云风的 BLOG
M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
T
Tailwind CSS Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
S
Secure Thoughts
博客园 - 【当耐特】
Know Your Adversary
Know Your Adversary
NISL@THU
NISL@THU
博客园 - 司徒正美
Last Week in AI
Last Week in AI
C
Cybersecurity and Infrastructure Security Agency CISA
P
Privacy & Cybersecurity Law Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
B
Blog
The GitHub Blog
The GitHub Blog
小众软件
小众软件
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Spread Privacy
Spread Privacy
Martin Fowler
Martin Fowler
博客园 - 叶小钗
Security Archives - TechRepublic
Security Archives - TechRepublic
T
Tenable Blog
S
Securelist
博客园 - 三生石上(FineUI控件)
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Microsoft Security Blog
Microsoft Security Blog
Apple Machine Learning Research
Apple Machine Learning Research
罗磊的独立博客
T
Threat Research - Cisco Blogs
Application and Cybersecurity Blog
Application and Cybersecurity Blog
F
Full Disclosure
Cloudbric
Cloudbric
The Cloudflare Blog
Y
Y Combinator Blog
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
H
Hacker News: Front Page
腾讯CDC
L
Lohrmann on Cybersecurity
C
CERT Recently Published Vulnerability Notes
V2EX - 技术
V2EX - 技术
GbyAI
GbyAI
TaoSecurity Blog
TaoSecurity Blog
I
Intezer
The Last Watchdog
The Last Watchdog
G
GRAHAM CLULEY
Google Online Security Blog
Google Online Security Blog
T
The Blog of Author Tim Ferriss

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.