4 ms·

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 e

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.

giancarlostoro 4y ago
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.
- nordsieck 4y ago
  > 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.
  - grishka 4y ago
    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.
    - nordsieck 4y ago
      > 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.
      - derefr 4y ago
        “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.
        grishka 4y ago
        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.
        GoblinSlayer 4y ago
        Don't they already use freetype to parse webfonts?
        derefr 4y ago
        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.
- grishka 4y ago
  > 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.

giancarlostoro 4y ago

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.

nordsieck 4y ago
> 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.
- grishka 4y ago
  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.
  - nordsieck 4y ago
    > 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.
    - derefr 4y ago
      “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.
      - grishka 4y ago
        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.
      - GoblinSlayer 4y ago
        Don't they already use freetype to parse webfonts?
        derefr 4y ago
        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.
grishka 4y ago
> 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.