very cool. this is why i hate the modern web.

@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.

@lina @whitequark agreed, but also why do websites need to know i have a fucking threadripper
@lina @whitequark like that is my point here, i cannot think of any reason why a website needs to know i have 128 threads

@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

Glasgow Interface Explorer

Use Glasgow Interface Explorer from your browser!

@ariadne @lina 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
@whitequark @ariadne @lina a problem is we use the web browser for two totally separate purposes: as a way of looking at transient text/image/video content; and as the only surviving application platform. we want two totally opposite things out of these two different platforms ("control the computer" vs "touch nothing"), but insist on not delineating the two website metacategories. and microsoft/apple/android are only gonna keep making it harder to offload applications back onto "computers"
@whitequark @ariadne @lina The era where Flash was the "escalated privilege" layer of the web, and click-to-flash plugins were common, was the only time either the developer or user permissions model here made sense

@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)

@mcc @whitequark @ariadne @lina I haven't really paid attention to what android and apple are doing these days, but i think a lot of this would be solvable by having some permissions be aggregates. e.g. "The web page wants to get the video calling and streaming permissions (fine print: which expand to blah blah blah and blah)". You unfortunately can't really let the application control the aggregate, but I think you could do a good job of simplifying the common use-cases for both apps and users.
@whitequark @mcc @ariadne @lina Flatpak has a bunch of permissions one can grant, just saying ...
@hruske @whitequark @mcc @ariadne @lina
yeah and everything just gets full read write access to your home directory making because devs are lazy and body cares
@tthbaltazar @hruske @whitequark @mcc @ariadne @lina regarding fingerprint metrics imma just throw in https://amiunique.org/fingerprint
My Fingerprint- Am I Unique ?

Check if your browser has a unique fingerprint, how identifiable you are on the Internet

@hruske @whitequark great, now you can ship your app to… desktop Linux users (but NOT to Ubuntu systems which are the most common ones)
@mcc @hruske @whitequark > (but NOT to Ubuntu systems which are the most common ones)

Which is terrifying given how Canonical has lost the plot since several years.

@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'.

@whitequark @mcc @ariadne @lina

@mcc @whitequark @ariadne @lina I want to know if anybody is working on separating the web into those two things. It can only make things better for everyone. We can get hypertext documents that load fast and look better than ever, and network-sourced applications with runtimes that are performant on a potato.
@sabrina @mcc @whitequark @ariadne @lina I mean for all intents and purposes #geminiprotocol is a great attempt at having a "markdown only web". We can debate how much regular folks actually want two webs, one for documents and one for runtimes
@iyashikei_kris @mcc @whitequark @ariadne @lina I think the problem with Gemini isn’t that nobody wants two webs, but that most people don’t want a second web that is only a minimalist plain text web. I think a hyperdoc web should still have all the styling features anybody could want. It can shed (most of) the scripting and the features in CSS that only exist for apps.

@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.

How to Show/Hide Div on Click with CSS Only (No JavaScript Needed for Accessibility)

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.

codegenes
@lina @sabrina @iyashikei_kris @mcc @whitequark @ariadne apologies for piling into a thread, but: I don't know how the author wrote this post and didn't include a reference to the summary element, which is standardized and accessible and has been around for years at this point: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/summary
<summary>: The Disclosure Summary element - HTML | MDN

The <summary> HTML element specifies a summary, caption, or legend for a <details> element's disclosure box. Clicking the <summary> element toggles the state of the parent <details> element open and closed.

MDN Web Docs

@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...

@whitequark @ariadne @lina This seems like a reasoning I've seen in the late 90s, where some browser would send your OS login password along to literally every web request. Sure, there *could* be some where it's useful, but they can ask for it explicitly, and I can give them permission. The default should always be not to send those things.
@whitequark @ariadne @lina Uh - cool, but it tells me "web assembly JSPI is not enabled". After enabling it in Firefox' about:config, it still says it's not enabled. Any ideas?
@whitequark @ariadne @lina It could also just ask the user. Especially given the further consideration noted here.
✧✦Catherine✦✧ (@[email protected])

@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

Treehouse Mastodon
@ariadne @lina @whitequark ah. it's a spam signal. like it cuts into their profits if they treat data-center hardware as likely to have a human sitting in front of it using it as a personal device, so they try to not do that.
@ariadne @lina @whitequark apologies for using a vague "they" there; specifically it cuts into the revenue of ad networks and the various participants in ad ecosystems
@ariadne @lina @whitequark Indeed. Even native applications, except for certain system-level things you intentionally privilege, should not be trying to inspect (and arguably should not be able to inspect) the total system resources, then try to consume them all.