@ariadne anti-fingerprinting feels like a pyrrhic victory to the extent it can be achieved
sure, random webpages probably don't need to know how many cores you have (and thoughtful design could keep this available to those few which maybe do). but the thing that made me conclude this is Accept-Language:, a feature that is intentionally made worse for bilingual users in service of reducing fingerprintability. i think i'd rather have that than a (in practice) false promise about privacy
@whitequark @ariadne At some point we need to start legislating these things instead of trying to patch over them with technology.
Like, there is zero legitimate reason for fingerprinting to uniquely identify individual users at scale. It should simply be illegal. This does not preclude stuff like identifying bots. Ad stuff should just use cookies where allowed.
@ariadne @lina i ship an FPGA toolchain in the browser. it can* use multithreading. it needs to know how many threads to run to not contend on resources uselessly
* currently not built in that configuration for a variety of reasons that is not specifically tied to the web
@mcc @ariadne @lina i think this is a reasonable way to view the problem domain but i don't entirely agree—i think the web is about as close to "fully granular permission model, without vendor lock-in" as we ever got and perhaps will ever get, and that it's valuable that i can give a webpage access to a USB device while denying it everything else on the computer, like "filesystem"
unfortunately, i cannot in good faith say that the fully granular permission model works. technically it could be made to work, sure, but getting people to understand the exact consequences of granting X permission is probably a lost cause—it would take someone a lot smarter than me to figure out how to do it
unfortunately#2 the actual, real-world alternative to doing that is "download and run an .exe" or "curl | bash" which is strictly worse. so i just don't know
@whitequark @ariadne @lina well, but that's exactly the problem i think. we built a fully granular permissions model where we really actually wanted a bimodal permissions model. and because the granular permissions model is so *incredibly fucking complicated*, the browser vendors go way out of their way to hide it, so it's not very useful.
browser vendors snowed us with the useless notifications/locations requests, and now are terrified to add perm popups because they got bad feedback on that.
@whitequark @ariadne @lina why is webrtc locked behind the microphone permission. i know what the web browsers *claim* is the answer to this question but imo the real reason is that they set out to make a fully granular permissions model, immediately discovered that had downsides, and have been backpedaling ever since
(I acknowledge the fully granular model is what works best for your goal of shipping an FPGA programmer)
@hruske flatpak takes granular permissions but it does not make them usable. Unless you expect the user to understand what "uses a legacy window system" means in terms of permissions. Sandboxing isn't easy, nor is seamlessly injecting permission prompts into applications which weren't designed for it, but the actually hard part is the permissions model. It needs to somehow be comprehensible by ordinary folks, while not overly constricting for 'power users'.
@sabrina @iyashikei_kris @mcc @whitequark @ariadne I think CSS is getting there but although it can do most things people would want these days, some things would have to be upgraded from "horrible hack" to first class support. Like this stuff:
https://www.codegenes.net/blog/show-hide-div-on-click-with-css/
Basic toggleable UI elements should not require hacks like fake check boxes.
In web development, showing or hiding content dynamically is a common requirement—think collapsible menus, accordions, tabs, or toggleable sections. While JavaScript is often the go-to solution for interactivity, there are scenarios where a CSS-only approach is preferable: it’s lightweight, avoids JS dependencies, and works even in environments where JavaScript is disabled. But here’s the catch: many CSS-only "toggle" solutions sacrifice accessibility, leaving keyboard users or screen reader users unable to interact with the content. The goal of this guide is to teach you **how to create accessible, CSS-only div toggles** that work for everyone, without a single line of JavaScript.
@saikou @sabrina @iyashikei_kris @mcc @whitequark @ariadne
I think the problem with that one is the mandatory parent/child/sibling relationship... and it also doesn't work for the mutually exclusive case.
There's also a use case for "deselect on focus loss" which that doesn't do...
@iyashikei_kris @mcc @whitequark @lina @sabrina the problem is Gemini doesn't have any content except for personal sites. I can't read news, for example from CNN, on Gemini.
Until it has content that people want to consume it just isn't worth it to me to be interested...
@ariadne @[email protected] it's not a reason to expose information useful to, like, 1 site you might maybe use, to every of them, and frankly i am not aware of any material benefit from running more than 4 of p&r threads in parallel so it could probably be capped to that. but i think this is a legitimate reason