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

推荐订阅源

Spread Privacy
Spread Privacy
P
Palo Alto Networks Blog
P
Proofpoint News Feed
AI
AI
Help Net Security
Help Net Security
S
Securelist
T
Troy Hunt's Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
C
Cisco Blogs
Scott Helme
Scott Helme
Hacker News - Newest:
Hacker News - Newest: "LLM"
Vercel News
Vercel News
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
B
Blog
GbyAI
GbyAI
Recent Commits to openclaw:main
Recent Commits to openclaw:main
D
Darknet – Hacking Tools, Hacker News & Cyber Security
P
Proofpoint News Feed
S
Security Affairs
Cisco Talos Blog
Cisco Talos Blog
AWS News Blog
AWS News Blog
T
Tenable Blog
H
Help Net Security
NISL@THU
NISL@THU
F
Fortinet All Blogs
博客园_首页
G
GRAHAM CLULEY
L
LINUX DO - 最新话题
P
Privacy International News Feed
G
Google Developers Blog
博客园 - Franky
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Security Archives - TechRepublic
Security Archives - TechRepublic
The Register - Security
The Register - Security
L
LangChain Blog
aimingoo的专栏
aimingoo的专栏
T
Tor Project blog
P
Privacy & Cybersecurity Law Blog
量子位
C
Cyber Attacks, Cyber Crime and Cyber Security
Forbes - Security
Forbes - Security
S
Secure Thoughts
Simon Willison's Weblog
Simon Willison's Weblog
D
Docker
Recorded Future
Recorded Future
博客园 - 三生石上(FineUI控件)
L
Lohrmann on Cybersecurity
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.