February 9, 2021 8:06 PM, nervuri wrote: > Displaying inline images at all goes somewhat against the vision for Gemini (see the FAQ [1]), but as long as it's constrained to the same host, and to a reasonable file size, I don't see anything wrong with it. Come to think of it, I do. 1. Increased browser complexity and attack surface. Think of buffer overflows in graphics libraries. 2. Inline GIFs... Distracting ads aside, I remember that time when a bunch of imbeciles targeted an epilepsy website with flashing animations in order to provoke seizures. Let's not allow for any of that. At the very least, inline GIFs should not auto-play. 3. Size bombs, the solution to which can lead to browser fingerprinting. A gemtext page may link to enormous images. Downloading them without the user's consent would be wrong, at least on limited mobile data connections. So a responsible browser developer might limit the total size of inline images on each page. But if each browser has a different size limit, servers can identify the user agent by checking how much of the payload was downloaded. And if the size limit is user-configurable, those who change the setting can be fingerprinted... and we're back to the web. February 10, 2021 8:23 AM, Stephane Bortzmeyer wrote: > Pre-fetching images THAT ARE ON THE SAME CAPSULE could be good for privacy, because it would deprive the capsule's admin of some knowledge (no way to know if the user really clicked). I don't think this information is sensitive enough to warrant the complications outlined above. So my recommendation to all Gemini browsers is to *follow the spec* and not display inline images: > clients MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol (e.g. links beginning with gemini://, gopher://, https://, ftp:// , etc.). gemini://gemini.circumlunar.space/docs/specification.gmi The one exception I find acceptable regards web proxies, like https://proxy.vulpes.one/ . This is because they can block or resize huge images server-side, to avoid #3. They can also block GIFs or put them behind static images, to tackle #2. And #1 is already present in web browsers.
---
Previous in thread (9 of 14): 🗣️ Stephane Bortzmeyer (stephane (a) sources.org)
Next in thread (11 of 14): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)