4 ms·

It still feels to me like you are maybe too worried to be using Lynx (in all its open source glory) for all your web browsing because of the possibility that on

It still feels to me like you are maybe too worried to be using Lynx (in all its open source glory) for all your web browsing because of the possibility that one or two websites may block the User Agent for Lynx because they don't want to support text browsers. User Agent strings are part of many HTTP specs. Enforcing User Agent strings isn't a part of the specs and is a huge mess that is wild and chaotic and varies from webserver to webserver. You are far more at risk of a webserver serving a website to Lynx that is simply broken by accident than outright "banning" it intentionally, and the "bans" are distributed and handled in different ways by a million different webservers, some of which are themselves open source, such as Apache or nginx. I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. There are open source Relying Parties. I've written an open source Relying Party. I've used an open source provider. This part of the spec is complicated and there's some fights over it, but part of the reason we're even seeing some of the fights is because open source cares on every side of this debate.

coldpie 1y ago
I don't think that's a fair analogy. Unlike Lynx, which lacks a ton of modern browser features, KeepassXC is a fully functional Passkey client. There is no technical reason to reject KeepassXC logins, while there are legitimate reasons to reject a browser that doesn't support graphics or javascript. Yet the Passkey spec authors are making threats about KeepassXC being banned and listing it on their non-compliant client page, because it allows users to handle their own data in a way the spec authors dislike. A better analogy would be a website blocking Firefox users because Firefox stores cookies in a way the website owner dislikes. A website intended for use by anybody, that chooses not to serve content based on the user's browser client, would be correctly considered broken. On the other hand, the Passkey spec authors are explicitly saying RPs should make rejection decisions based solely on the client. I agree implementations can be all over the map here, but what's giving me pause is the explicit endorsement of banning clients by the authors of the spec. > I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. The incompatibility is that the spec requires the client software to behave in a certain way, or RPs may choose to reject logins from it. Open source software simply cannot make those guarantees. I have the freedom to make my implementation non-compliant. If an RP wants strict compliance from the providers they accept (which is a position explicitly endorsed by the spec authors), then they must only accept closed-source software.

coldpie 1y ago

I don't think that's a fair analogy. Unlike Lynx, which lacks a ton of modern browser features, KeepassXC is a fully functional Passkey client. There is no technical reason to reject KeepassXC logins, while there are legitimate reasons to reject a browser that doesn't support graphics or javascript. Yet the Passkey spec authors are making threats about KeepassXC being banned and listing it on their non-compliant client page, because it allows users to handle their own data in a way the spec authors dislike. A better analogy would be a website blocking Firefox users because Firefox stores cookies in a way the website owner dislikes. A website intended for use by anybody, that chooses not to serve content based on the user's browser client, would be correctly considered broken. On the other hand, the Passkey spec authors are explicitly saying RPs should make rejection decisions based solely on the client. I agree implementations can be all over the map here, but what's giving me pause is the explicit endorsement of banning clients by the authors of the spec. > I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. The incompatibility is that the spec requires the client software to behave in a certain way, or RPs may choose to reject logins from it. Open source software simply cannot make those guarantees. I have the freedom to make my implementation non-compliant. If an RP wants strict compliance from the providers they accept (which is a position explicitly endorsed by the spec authors), then they must only accept closed-source software.