💾 Archived View for rawtext.club › ~sloum › geminilist › 005385.gmi captured on 2024-02-05 at 11:11:28. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
ew.gemini ew.gemini at nassur.net
Sun Feb 21 07:28:23 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 userasked. Thus no favicons.
Data parsimony is something which affects metadata at least asmuch as data. Only (meta)data, which is not available to beginwith, is good data. Yes, yes, I know, that would mean I shoulddisconnect my notebook and shut up. :) If I do not speak, Iaccept 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.ascType: application/pgp-signatureSize: 861 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/8abe3820/attachment.sig>