Hacker News new | ask | show | jobs
by matheusmoreira 1022 days ago
I don't think web developers should be able to detect stuff like that either. Their ability to detect stuff provides identifying bits for fingerprinting. As far as I'm concerned, all the browsers should normalize the return values of those typeofs and all related functions so that Javascript can figure out exactly zero bits of information about the environment it's running on. Just like browsers will lie to Javascript when it tries to figure out your browsing history by checking the color of links.

The web platform gave web developers way too much freedom and they're abusing it. God giveth and god taketh away.

2 comments

There's simply no way that can ever be built though. "Browser v2 provides X which will call argument 1 in 2 seconds" -> how would browser v1 possibly hide that it is not v2? Anyone can build a thing that checks for that behavior, and now you have a piece of information.

Or for more useful stuff, "X gets you data from URL Y". Either you get that data or you don't. Voila, data about the browser.

The only alternative is that you never ever release any new features or fix any bugs.

How does cryptography software avoid such side channels? Normalize the performance somehow.

If I remember correctly, Firefox's fingerprinting resistance will actually slow down functionality to achieve that. Reduces the precision of performance timers or something. Makes CAPTCHAs exponentially more obnoxious.

It hides that by being incredibly restricted in what you can do with it, lest you leak side channel information. To the point that you can't do much of anything useful, much less general computation. They're finely crafted Faberge eggs that break if you sneeze near them now or discover a new way of sneezing in the next few decades, not broad tools.

So... yes, you could build a "browser" like that. It would effectively have no scripting at all though, nor could it ever introduce new semantics that send data to another site, directly or transitively. You can do some stuff with that kind of system, but it's limited enough that most people don't choose it.

Gopher exists I guess? Lynx too, though lynx supports css, and that largely can't be allowed either.

Sounds good to me. Javascript is too powerful and should be limited. I shouldn't have to worry that my browser is executing remotely downloaded code that could exfiltrate an unbounded amount of information about me. They should either they get it right by doing it in a way that doesn't harm us, or they shouldn't get to do it at all.

The web should be fully declarative and permissions/capabilities based. If they can't do something that way, they shouldn't get to do it at all.

In that case, you might like the Gemini protocol? https://gemini.circumlunar.space/

I'm not deeply familiar with it, but it's a similar "extremely minimal is best" approach, also in part for privacy reasons.

> Feature detection is too much power for developers

- People on HN.

Yes, it is too much power for them. Power which they abuse by fingerprinting us. Browser vendors agree with me: they reduced the power of developers by lying to Javascript when they tried to check link styles.

Do you think otherwise?

A. Test for window.fetch.

B. Check if a link is visited.

Whether these two even remotely fall into the same category is left as an exercise for readers.

A. Provides bits of identifying information.

B. Provides bits of identifying information.

To me it seems they're in the exact same category.

Knowing which key the user pressed? Provides bits of identifying information.

Knowing the user's mouse position? Provides bits of identifying information.

Knowing which subdomain the user is visiting? Provides bits of identifying information.

Reading URL query string? Provides bits of identifying information.

If this is a category, it's a quite big one!

Huh. Now I'm not sure Javascript should be able to do any of those things either. Now that you mentioned it, I remember reading about how sites fingerprint users by timing keystrokes and mouse movements and numberless other things.

Maybe the ultimate conclusion is Javascript should not actually exist at all. The web should be declarative, not executable. Developers tell the browser what they want and the browser does it. If it can't be done that way, it isn't done.

Just like Chrome's Manifest V3 making extensions more declarative and limited. My only problem with it is the fact it cripples uBlock Origin. I actually do want those restrictions applied to 100% of all the other extensions, it's just that uBlock Origin is too important and trusted and should be an exception. Honestly, uBlock Origin should be literally built into the browsers at this point. The only reason we can't have that is the massive conflicts of interest involved: can't trust an advertising company to maintain an adblocker.

Using an Abortcontroller with fetch for example is only recently supported. I like to use it where I can, but I don't want to crash on a slightly older browser. Feature detection is absolutely practically useful.
I have no doubt that it's useful. My point is it enables abuse towards us and that the potential for abuse overrides the utility.

Road to hell is paved with good intentions. When you propose a law, you must also think about the numberless ways it could be abused and misused to cause harm. Same principle applies here. The code shouldn't just fail, it should fail in ways that prevent the developer from even knowing it failed much less why. Simply because that would leak information.