Hacker News Reader

Comment by illiarian | Hacker News Reader

Note also: As the number of APIs increases, so does the fingerprinting. E.g. MIDI device enumeration (no prompt in Chrome, prompt in FF, not implemented in Safari): https://twitter.com/denschub/status/1582730985778556931?s=20

View on HN

We need 2 classes of web. One for document based that doesn't require JS to run (secure). Insecure, all the SPA and anything that require JS to see the full content.

Back in the day, we had a nice boundary between the document and the "app". Then for some reason we decided that Flash doesn't need to be a thing any more and erased that boundary by building the app functionality into browsers themselves, making the app and the document inseparable. We should have invested that effort into building an open source Flash player instead.

One of the nicest things about Flash was that you could set your browser to only load and run Flash content after you click it.

Java Applets were worse though, every time I got a virus of any sort from merely browsing generic sites, it always happened due to Java in the browser. I finally stopped installing Java for the web and my security problems went away.

Flash had some security nightmares all the time too if I remember correctly but I dont think it ever screwed me over like Java did.

I think unless we lock down new APIs that aide in fingerprinting to only be accessible to WebAssembly and let people block or enable WASM theres not too much else we can do. It would be nice to be able to block web APIs selectively to limit what a JS script can do.

> I think unless we lock down new APIs that aide in fingerprinting to only be accessible to WebAssembly and let people block or enable WASM theres not too much else we can do.

IMO, it should be enough if incognito mode presents an identical fingerprint on everyone's browser.

It's not that easy to "present a fingerprint" without compromising the user experience. Sure, you could remove all those PWA and pretend-OS APIs and hardly anyone would notice, but what about things like viewport size and font rendering? You can't exactly hide them from a website.

> It's not that easy to "present a fingerprint" without compromising the user experience.

And that's exactly what I'm talking about.

> what about things like viewport size and font rendering?

Not much can be done about viewport size, but a browser could easily ship with 2 fonts (one serif and one sans serif) and only allow access to those.

“Font rendering” is a different thing than “what fonts you have.” Font rendering is about how fonts are drawn to the screen. The trick is to draw some words to a <canvas> and then pixel-peep the result. Different OSes and browsers use different font renderers and font hinting logic; fonts will even render differently on a different-DPI screen.

Not just the <canvas>. The font rendering of the underlying platform also influences the width of strings. So if you create a <span> with some text, its width will differ several pixels depending on the host OS.

Don't they already use freetype to parse webfonts?

Is that a standard — that all browsers are forced to use the Freetype library, or to be bug-for-bug compatible with its glyph+hint parsing semantics? I've never heard of anything like that.

But also, even if they did, AFAIK browsers still mostly lean on OS text-drawing APIs for font rendering. Text in Chrome on Windows looks different than text in Chrome on macOS, etc. The same pile of beziers, and the same pile of hints, converts into a different set of hinted pixels (and sub-pixels!) when fed to each OS text-drawing API. Especially when those APIs are configured by user settings around subpixel hinting / "font smoothing", and when those APIs are aware of the device being rendered to and so render subpixels differently for high-DPI vs low-DPI screens, RGB vs BGR displays, etc.

Different browsersare always distinguishable but a single browser could choose to always use the same font rendering code and settings, at least for private browsing.

For viewport, you can limit the size presented to the page to a few sizes with different aspect ratios. Browsers can simply rescale the page to the actual window size for display on the screen. That also works for font rendering.

If users decide they want pixel-perfect display, they can either resize the window to one of the allowed sizes or disable this feature for a specific page.

You are describing the "compromising the user experience" alternative.

> what about things like viewport size and font rendering? You can't exactly hide them from a website.

Of course you can. Viewport? Just return fake viewport data containing the most statistically common display properties. Website renders incorrectly? They only have themselves to blame, shouldn't have abused that data for hostile purposes. Data is a privilege, we can and should take it away. Fonts? Just force everything to use Noto Sans or Noto Mono. Everything will render correctly. Maybe the designer's vision won't be fully realized but that's not a problem.

User and javascript can simply see different things, like adnauseam does. User experience is already shit.

> Flash had some security nightmares all the time too if I remember correctly but I dont think it ever screwed me over like Java did.

Those incessant RCEs were only due to the sloppy way the Adobe Flash player was written. There is nothing bad security-wise inherent to the SWF format itself.

Ruffle is an open source Flash player in Rust, currently under active development. I'm sure it won't have such problems because 1) it's open-source and 2) it's in Rust, and I was told that anything written in Rust can't possibly have any memory-related vulnerabilities; we'll wait and see if this would still hold true if/when they implement JIT compilation for AS3.

I think we will end up with something like permissions grants (including granular JS APIs available for the website, as we do for the location, camera APIs etc, at the moment) per website and convenient tools built-in browser that allow you create/re-use patterns so you don't actually interrupted by this strictness too much.

> per website and convenient tools built-in browser

Per-website, for dozens (if not hundreds) of APIs and convenient? These are contradictory :)

Yeah, sounds a bit overwhelming for users, but my point here us that we would need appropriate tooling to be offered to end users so they are not get lost (quickly lol).

Yeah that's never going to happen - javascript is a lost cause. There's no way any sort of conflict and backwards compitability will lose out to "a bit more privacy" especially when people in control benefit immensely from this.

> We need 2 classes of web. One for document based that doesn't require JS to run (secure).

I've wondered for a long time if a sort of posh gopher based on markdown with extensions would be able to make a comeback. Especially if it allowed for CSS.

You're sort of describing Gemini.

https://en.wikipedia.org/wiki/Gemini_(protocol)

Except that is too limited even for a document web.

As with most things, this isn't really a technical challenge, it's a social one. The protocols you're describing already exist, more or less. No one uses them.

But not current web CSS, please. It manages to be simultaneously overcomplicated (including enabling fingerprinting) and really bad at laying out text (e.g. still no baseline grid). A ‘markdown web’ style sheet should be more like document processor's character/paragraph styles. It also needs to be easily overridden for accessibility or alternate presentation, particularly around size and colour (a markdown-like format should already be fine for screen readers without styling). Aside: FFS, web people, if you're setting colours at all, respect @prefers-color-scheme and do not use the inverse for code blocks.

There's also the million-markdowns problem, and markdown's HTML embedding. This being Tuesday, I'd start with djot (without embedding), but Wednesday I might go for asciidoc.

Why not just good old web 1.0 or even HTML5 without javascript. There are alreay plenty of pages that conform to that, you just need the client enforcement (also already available via extensions) and marketing/lobbying so that big organizations switch to it.

Which class you're in will be in control of the developer and they'll always choose SPA even for the presentation of static text.

And to be fair it makes a lot of sense because writing HTML templates feels super jank once you've experienced not doing it. Even for a site with static content I would still prefer to deliver it as a static JS bundle and a data payload.

I really like https://docsify.js.org. Gotta be one of the lowest touch libs out there. The whole site from git repo to page one single completely static asset.

The dark web is the document-based web. Sites built for Tor Browser have to assume JavaScript is disabled. So they have to rely on server-side rendering, old-school HTML forms, HTML meta refresh, etc.

Surprisingly, one thing that seems to work just fine in this environment is (even modern versions of) phpBB. Lot of phpBB dark web forums.

Also surprisingly, this doesn’t preclude polish or some level of app-like stateful interactivity, because CSS still works. You just have to think differently about how you use it.

MIDI device enumeration is behind a permissions prompt, though? "The user must explicitly grant permission to use the API though a user-agent specific mechanism, or have previously granted permission." https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...

EDIT: nope, not as implemented in Chrome https://www.jefftk.com/test/webmidi

At the time of the tweet not in Chrome: https://twitter.com/denschub/status/1582730988118867968?s=20

And the tweet is correct, unfortunately: https://www.jefftk.com/test/webmidi

Looks like Chrome is trying to change this, and is slow as usual: https://groups.google.com/a/chromium.org/g/blink-api-owners-...

> is slow as usual:

It's funny because for anything Chrome deems beneficial to Google they are anything but slow, including shipping APIs that no other browser agreed on.

Having been someone at Google working on new browser APIs, that's slow too. But maybe it doesn't look as slow from the outside?

> But maybe it doesn't look as slow from the outside?

Google ships 400 new APIs per year. It readily ships API within a month after it spits out a half-prepared spec and asks other browsers for input.

Even benign changes like CSS headline balancing was sent to TAG three weeks ago, and will ship a month from now.

From the outside this is neck-breaking speed with utter disregard for anything. But when user privacy is concerned? Nah, must spend sweet time to do anything.

> Even benign changes like CSS headline balancing was sent to TAG three weeks ago

The "text-wrap: balance" proposal is not new, though? I see it in the 2019-11-13 draft spec: https://www.w3.org/TR/2019/WD-css-text-4-20191113/#valdef-te...

Perhaps, but it was sent for TAG review only three weeks ago, and already with an intent to ship in a month.

It looks like that was just because it was very uncontroversial, though? https://github.com/w3ctag/design-reviews/issues/822

Isn’t that the point of the RFC approach to standardization? “Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production; feel free to try our impl out, in order to better notice the design flaws in practice, so that we can talk out what changes could be made before it becomes a de-facto standard we’re all stuck with”? SPDY → HTTP2 was a great example of Google doing exactly this.

The opposite of the RFC approach is the “airy design document written by standards body in reference to nothing, never implemented by anyone” approach; and I know which of the two I prefer.

> Here’s what we think should be done, with the PoC being what we’re already doing ourselves in production

The problem with having anything in "production" on the web is that you can neither update it or change it because people will rely on it.

The idea behind web standards is that there should be at least two independent implementations, tested behind a flag, with iterations on design, before it becomes a full standard.

Chrome's approach for the past several years has been: spit out a half-completed spec, "ask" other browser for input.... and ship it in prod a month later.

Didn't Firefox also require the user to install an extension before enabling MIDI support?

Edit: I think MDN confirms this, with the asterisk next to Firefox: https://developer.mozilla.org/en-US/docs/Web/API/Web_MIDI_AP...

Edit 2: oh, the tweet shows two prompts, one of them to install the extension, so I suppose that is actually the prompt you're referring to.

Reply on news.ycombinator.com