On Mon, 07 Dec 2020 18:13:17 GMT "Adnan Maolood" <me at adnano.co> wrote: > I don't think that using unicode in addresses would decrease security > because of the way that Gemini handles client authentication. Since > client certificates are limited to certain domains and paths, the > certificate will never be applied to the wrong domain, even if it looks > the same to the user. Security might also mean knowing that I'm not unintendedly divulging any details of my browsing habits to some unknown third party, or knowing that no one can impersonate your server and pages to mislead your readers. Neither of those necessarily involve client certificates at all but are a real possibility when multiple code points can represent similar or identical glyphs. I can see how IRI and IDN may be a good idea in terms of including languages with bigger or altogether different alphabets or non-alphabets, but from the perspective of an implementer, it does add a lot of complexity and opens up to homograph attacks in an area where ASCII transliteration is already the norm. Some browsers deal with homograph attacks by displaying punycode directly based on some basic heuristic (e.g. when a hostname contains both cyrillic and latin codes). I don't know much about IRI. Web browsers for example sort of skipped on this standard in favor of the WHATWG URL spec. Personally, I think some concessions need to be made to maintain the simplicity of the protocol. The currently mandated standard is (relatively) short and simple to implement, and transliteration is already pervasive in the area of internet names and URIs. Octet encoded ASCII does have the nice property that there are no homographs, there's no normalization, there's nobidirectional text etc. and there is no database of rules that have to be applied to handle these things. That said, I think a lot can be improved on the client side without changing the standard. Clients can optionally do the ToASCII/ToUnicode dance and correspondingly automatically percent encode input and display "un-percented" paths in some circumstances. The standard only specifies what needs to be sent to the server to request a resource, and what text/gemini documents need to contain to produce a link. This opens up a lot of quality of life improvements on the user interface level. RFC 4690 is a good read on the topic of IDNs. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201208/55da d39f/attachment.sig>
---
Previous in thread (52 of 68): 🗣️ Sean Conner (sean (a) conman.org)