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

推荐订阅源

Google Online Security Blog
Google Online Security Blog
S
Security @ Cisco Blogs
Recent Commits to openclaw:main
Recent Commits to openclaw:main
人人都是产品经理
人人都是产品经理
The Hacker News
The Hacker News
W
WeLiveSecurity
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
博客园 - 司徒正美
雷峰网
雷峰网
L
LINUX DO - 最新话题
博客园 - 叶小钗
云风的 BLOG
云风的 BLOG
The Last Watchdog
The Last Watchdog
V2EX - 技术
V2EX - 技术
S
Security Affairs
有赞技术团队
有赞技术团队
月光博客
月光博客
T
Threatpost
T
Tor Project blog
O
OpenAI News
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
V
V2EX
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
博客园 - 三生石上(FineUI控件)
D
Docker
AWS News Blog
AWS News Blog
AI
AI
P
Proofpoint News Feed
K
Kaspersky official blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
D
Darknet – Hacking Tools, Hacker News & Cyber Security
www.infosecurity-magazine.com
www.infosecurity-magazine.com
S
Securelist
F
Fortinet All Blogs
F
Full Disclosure
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
量子位
Hacker News - Newest:
Hacker News - Newest: "LLM"
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
P
Palo Alto Networks Blog
Cyberwarzone
Cyberwarzone
Cisco Talos Blog
Cisco Talos Blog
美团技术团队
N
News | PayPal Newsroom
T
The Blog of Author Tim Ferriss
MyScale Blog
MyScale 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.