💾 Archived View for gemi.dev › gemini-mailing-list › 000730.gmi captured on 2024-08-19 at 01:51:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi, It doesn't seem that the specification is clear that requesting a page shouldn't download other resources. This raises concerns and questions about inline data, currently in-line pictures are supported by Lagrange browser (not a default though). Some people noticed /favicon.txt errors in their logs, it turned out the Amphora client implemented an Emoji favicon support (disabled by default)[1] which already help tracking Amphora users. Someone made a ticket to ask removing this feature [2] but per the spec, it is not allowed or forbidden. I propose to add in the current specification in "1.1 Gemini transactions" something like "Every request should match an unique user action" or "Users actions must correspond to an unique request"? The point is that when an user load a new page or follow a link (document or gemini page) only ONE request must be made. This would mean inline pre-loading is forbidden per the specification or that metadata like favicons are forbidden too. In regards to privacy and security, it is important for users to feel confident that their client is not doing more than what they ask. ?I click on this link, my client request and display the content.? and nothing more behind the scenes. 1: gemini://mozz.us/files/rfc_gemini_favicon.gmi 2: https://github.com/makeworld-the-better-one/amfora/issues/199
On Sat, 20 Feb 2021, Solene Rapenne wrote: > Hi, > > It doesn't seem that the specification is clear that requesting > a page shouldn't download other resources. > > This raises concerns and questions about inline data, currently > in-line pictures are supported by Lagrange browser (not a default > though). > > Some people noticed /favicon.txt errors in their logs, it turned out > the Amphora client implemented an Emoji favicon support (disabled by > default)[1] which already help tracking Amphora users. Someone made > a ticket to ask removing this feature [2] but per the spec, it is > not allowed or forbidden. "Gemini interprets extensibility as a side-channel attack, and routes around it." I support Solene's proposal (though I have not read the exact proposed wording). If the proposal is accepted into the spec, I'd also suggest that clients that violate it on this point be removed from the list of Gemini clients on the main webpages. This feels uncharacteristically heavy-handed by my standards, but there appears no other way to stop Gemini being forcibly evolved in a way that damages its value to many users. Mk -- Martin Keegan, @mk270, https://mk.ucant.org/
Hello, Solene Rapenne writes: > Hi, > > It doesn't seem that the specification is clear that requesting > a page shouldn't download other resources. > > This raises concerns and questions about inline data, currently > in-line pictures are supported by Lagrange browser (not a default > though). > > Some people noticed /favicon.txt errors in their logs, it turned out > the Amphora client implemented an Emoji favicon support (disabled by > default)[1] which already help tracking Amphora users. Someone made > a ticket to ask removing this feature [2] but per the spec, it is > not allowed or forbidden. I support the idea of not loading anything beyond what the user asked. Thus no favicons. Data parsimony is something which affects metadata at least as much as data. Only (meta)data, which is not available to begin with, is good data. Yes, yes, I know, that would mean I should disconnect my notebook and shut up. :) If I do not speak, I accept whatever comes up. So my vote: keep it minimal, please. > > I propose to add in the current specification in "1.1 Gemini > transactions" something like "Every request should match an unique > user action" or "Users actions must correspond to an unique request"? > The point is that when an user load a new page or follow a link > (document or gemini page) only ONE request must be made. This would > mean inline pre-loading is forbidden per the specification or that > metadata like favicons are forbidden too. > > In regards to privacy and security, it is important for users to feel > confident that their client is not doing more than what they ask. > ?I click on this link, my client request and display the content.? > and nothing more behind the scenes. > > > 1: gemini://mozz.us/files/rfc_gemini_favicon.gmi > 2: https://github.com/makeworld-the-better-one/amfora/issues/199 Thanks Solene, for attempting to decide on this ambiguity. Cheers, Erich -- Keep it simple! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/8abe 3820/attachment.sig>
Le dimanche 21 f?vrier 2021, 08:28:23 CET ew.gemini a ?crit : > I support the idea of not loading anything beyond what the user > asked. Thus no favicons. But what if the user does ask for favicons? I do not like the favicon specifications personaly, so I would not activate it if my browser adds support for it. But I did add icons to most of my capsules for people who use it, and I feel forbidding such thing by specification is a strong overstepping of the specification. I see Gemini as a protocol specification and feel like it should not overstep too much on how the protocol is used. Conventions and specifications based upon Gemini will happen even if you don?t want it. I even host a list of such specifications here: gemini://gemlog.lanterne.chilliet.eu/specifications.en.gmi (Do not hesitate to send me missing ones) C?me
Hello C?me, C?me Chilliet writes: > Le dimanche 21 f?vrier 2021, 08:28:23 CET ew.gemini a ?crit : >> I support the idea of not loading anything beyond what the user >> asked. Thus no favicons. > > But what if the user does ask for favicons? I obviously wasn't clear enough. :) IFF the user asks for them, all is fine, imho. IFF the browser just does this behind my neck without my explicit consent, then no thanks. The /automatic/ thing is, what bothers me. > I do not like the favicon specifications personaly, so I would not activate it if my browser adds support for it. > But I did add icons to most of my capsules for people who use it, and I feel forbidding such thing by specification is a strong overstepping of the specification. > > I see Gemini as a protocol specification and feel like it should not overstep too much on how the protocol is used. Conventions and specifications based upon Gemini will happen even if you don?t want it. > > I even host a list of such specifications here: gemini://gemlog.lanterne.chilliet.eu/specifications.en.gmi (Do not hesitate to send me missing ones) > > C?me I'm well aware that monitoring the sizes and/or times of downloads leads to metadata useable for fingerprinting. Getting rid of this kind of meta data (connection between A and B occured Date-Time) is difficult. Cheers, ~ew -- Keep it simple! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/6889 96dc/attachment.sig>
On Sat, Feb 20, 2021 at 11:42:25PM +0100, Solene Rapenne wrote: > Hi, > > It doesn't seem that the specification is clear that requesting > a page shouldn't download other resources. > > This raises concerns and questions about inline data, currently > in-line pictures are supported by Lagrange browser (not a default > though). > > Some people noticed /favicon.txt errors in their logs, it turned out > the Amphora client implemented an Emoji favicon support (disabled by > default)[1] which already help tracking Amphora users. Someone made > a ticket to ask removing this feature [2] but per the spec, it is > not allowed or forbidden. I like a lot the favicon.txt but i can see the point, i made this feature opt-in in my client. Bye! C.
> IFF the user asks for them, all is fine, imho. > IFF the browser just does this behind my neck without my explicit > consent, then no thanks. > The /automatic/ thing is, what bothers me. Just to be clear: The user has to explicitly enable the feature in Amfora. The requests will happen automatically once it is enable, however. makeworld
---
Previous Thread: [ANN] Sourcehut pages: Gemini capsule hosting