5 ms·

There's still zero day exploits found in chromium, wouldn't using using this put you at a huge risk of running into malware in the wild that this browser can't

There's still zero day exploits found in chromium, wouldn't using using this put you at a huge risk of running into malware in the wild that this browser can't protect against?

38 2y ago
I agree, no one should ever bother writing a new browser again, too risky. We should just use chrome forever
- hanniabu 2y ago
  Why not just fork chromium with all the Google analytics/tracking removed?
  - devsda 2y ago
    There's ungoogled chromium for that. Also doing that doesn't solve the standards problem we currently have. Google is able to push through any "standard". And those standards "unwittingly" help them maintain their search/ad dominance or prevent competitors. For example see manifest v3 or FloC (a.k.a Topics API). Once they gain enough traction and become indispensible, you either implement them or risk losing users.
    - hanniabu 2y ago
      But why would this change with a new browser written from scratch?
      - 38 2y ago
        are you being intentionally ignorant? the more browsers in popular use, the less control each has. currently Chrome has more usage than the other browsers combined: https://gs.statcounter.com/browser-market-share https://gs.statcounter.com/browser-market-share which means Google has significant control over web standards
        hanniabu 2y ago
        A chromium fork is not chrome. Why assume a fork has to accept upsteam changes?
        38 2y ago
        why fork chrome rather than another browser, or starting from scratch?
        phil294 2y ago
        Because it's infinitely less work than starting from scratch. It's a valid argument.
        38 2y ago
        infinitely doesn't mean what you think it means
        hanniabu 2y ago
        Less work, more features, proven, security lindy
        38 2y ago
        good point about the lindy
        devsda 2y ago
        They don't have to. But we have seen how Google can play this game of open core & official versions with AOSP and blessed Android versions with playstore. There will be two classes of products one officially sanctioned version and the others that are used by enthusiasts. Apps or sites in this case may chose to work on one and not on others. Imagine the new wave of "works best on IE" with "best viewed on chrome variations a,b,c". Its not farfetched as some sites already do this. As much as it is easy to maintain a fork, it is that much easy to give up or change path and accept upstream changes.
swiftcoder 2y ago
Maybe if Chromium was written in a memory-safe language there would be fewer zero-days?
- fabrice_d 2y ago
  Yes, and that's why Chromium moved to allow Rust code (pretty much like they did for Android).
  - mrkramer 2y ago
    They said some of the code can be rewritten in Rust but majority of the code cannot. Therefore they are stuck with C++ forever. Scary thing to think about.
    - happyweasel 2y ago
      Also scary for Rust.
      - mrkramer 2y ago
        But Rust has a lot of momentum and positive energy and C++ is becoming something like C, the language everybody is scared and depressed to use.
        niutech 2y ago
        Tell it to GTK folks.
        deleted 2y ago
        [deleted]
    - mdaniel 2y ago
      > but majority of the code cannot Do you have a citation for "cannot"? Maybe "prefer not because of non-functional requirements" but if it's a choice between a ~~webpage~~ ad vector loading 10 seconds slower versus the goddamn plague of RCEs coming out of Chrome, I know which one I'd take
bee_rider 2y ago
I somewhat wonder—Firefox and Chrome are in a constant race to have the best JavaScript performance. In general, the sites I want to browse use minimal JavaScript, prudently, if at all, just where it is strictly necessary to add little dynamic features. So, I don’t really care about JavaScript performance at all. Optimization sometimes introduces additional complexity, which might open up the possibility of security holes (at least it seems to be the case to me, as a not-security-related programmer. I don’t know anything about security on a technical level, so I’m interested in other perspectives on this from people that actually work in those sorts of fields). I wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety. Rendering documents ought to not be computationally intensive, right? Advertisements of blazing fast JavaScript performance make me worry what corners have been cut.
- hanniabu 2y ago
  > wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?
  - bee_rider 2y ago
    Haha, well that’s what I use now. I think it is the opposite though. I’d like a JavaScript implementation that doesn’t break any sites, but which makes absolutely no security compromises, even if that means they have to give up a lot of performance. Sometimes, I just have to load a site that has JavaScript running. Or is unfortunate, but some work sites don’t work without it, etc. I’m fine with those sites being slow (I’ll minimize my use of them naturally), but totally blocking them is slightly inconvenient.
    - sfink 2y ago
      Disabling (all of) the JITs is a decent approximation of this. It's very site-dependent as to how much of a performance impact it makes, but for many sites it'll be fine. Obviously this isn't the same as making "absolutely no security compromises", but in practice most JS-related security exploits go through the JIT iiuc. Your JS will be executed with a safe interpreter, where by "safe" I mean the dispatching and basic value manipulation are going to be simple enough to be bulletproof, and also slow enough to prevent most timing attacks. The underlying implementation of all of the built-in methods is still going to be more vulnerable, but those tend to be relatively safe as compared to JIT-optimized versions of them. They also don't change much, so have been tested for much longer as compared to the JITs that tend to get refactored and rewritten relatively frequently.
vlovich123 2y ago
Malware generally can't just "hijack" any arbitrary browser. You have to have exploits for a specific browser / browser family / JS engine. Chromium has defense in depth techniques to try to raise the difficulty bar and to try to limit the fallout of an exploit in various parts of the tech stack, but that still requires a Chrome-specific attack in the first place. Attacks for Safari / WebKit / JavascriptCore would similarly require a different vector for the exploit (even if some techniques are common, the specific details should be quite different). There is a newer class of generic malware that exploits CPU bugs (e.g. Spectre) - are you perhaps referring to that? If so, that's a fair concern but unlikely to matter much in practice. For Spectre itself, I believe the mitigations were applied within the major JS engines directly (or at least for v8 they were). Anyway, security issues are best compared when there's a lot more attention to your browser. But given that there's a huge amount of exploits that depend on buffer overflows that are simply impossible in the first place with Rust, it's likely that the browser's likely to mostly suffer only from architectural issues & fewer implementation issues whereas other browsers will still have architectural issues and implementation issues to boot that prevent them from addressing it. Yes, newer browser = likely more immature architecture, but at the same time there's fewer implementation issues to worry about in terms of exploiting architectural issues in the first place.

There's still zero day exploits found in chromium, wouldn't using using this put you at a huge risk of running into malware in the wild that this browser can't protect against?

38 2y ago

I agree, no one should ever bother writing a new browser again, too risky. We should just use chrome forever

hanniabu 2y ago
Why not just fork chromium with all the Google analytics/tracking removed?
- devsda 2y ago
  There's ungoogled chromium for that. Also doing that doesn't solve the standards problem we currently have. Google is able to push through any "standard". And those standards "unwittingly" help them maintain their search/ad dominance or prevent competitors. For example see manifest v3 or FloC (a.k.a Topics API). Once they gain enough traction and become indispensible, you either implement them or risk losing users.
  - hanniabu 2y ago
    But why would this change with a new browser written from scratch?
    - 38 2y ago
      are you being intentionally ignorant? the more browsers in popular use, the less control each has. currently Chrome has more usage than the other browsers combined: https://gs.statcounter.com/browser-market-share https://gs.statcounter.com/browser-market-share which means Google has significant control over web standards
      - hanniabu 2y ago
        A chromium fork is not chrome. Why assume a fork has to accept upsteam changes?
        38 2y ago
        why fork chrome rather than another browser, or starting from scratch?
        phil294 2y ago
        Because it's infinitely less work than starting from scratch. It's a valid argument.
        38 2y ago
        infinitely doesn't mean what you think it means
        hanniabu 2y ago
        Less work, more features, proven, security lindy
        38 2y ago
        good point about the lindy
        devsda 2y ago
        They don't have to. But we have seen how Google can play this game of open core & official versions with AOSP and blessed Android versions with playstore. There will be two classes of products one officially sanctioned version and the others that are used by enthusiasts. Apps or sites in this case may chose to work on one and not on others. Imagine the new wave of "works best on IE" with "best viewed on chrome variations a,b,c". Its not farfetched as some sites already do this. As much as it is easy to maintain a fork, it is that much easy to give up or change path and accept upstream changes.

swiftcoder 2y ago

Maybe if Chromium was written in a memory-safe language there would be fewer zero-days?

fabrice_d 2y ago
Yes, and that's why Chromium moved to allow Rust code (pretty much like they did for Android).
- mrkramer 2y ago
  They said some of the code can be rewritten in Rust but majority of the code cannot. Therefore they are stuck with C++ forever. Scary thing to think about.
  - happyweasel 2y ago
    Also scary for Rust.
    - mrkramer 2y ago
      But Rust has a lot of momentum and positive energy and C++ is becoming something like C, the language everybody is scared and depressed to use.
      - niutech 2y ago
        Tell it to GTK folks.
      - deleted 2y ago
        [deleted]
  - mdaniel 2y ago
    > but majority of the code cannot Do you have a citation for "cannot"? Maybe "prefer not because of non-functional requirements" but if it's a choice between a ~~webpage~~ ad vector loading 10 seconds slower versus the goddamn plague of RCEs coming out of Chrome, I know which one I'd take

bee_rider 2y ago

I somewhat wonder—Firefox and Chrome are in a constant race to have the best JavaScript performance. In general, the sites I want to browse use minimal JavaScript, prudently, if at all, just where it is strictly necessary to add little dynamic features. So, I don’t really care about JavaScript performance at all. Optimization sometimes introduces additional complexity, which might open up the possibility of security holes (at least it seems to be the case to me, as a not-security-related programmer. I don’t know anything about security on a technical level, so I’m interested in other perspectives on this from people that actually work in those sorts of fields). I wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety. Rendering documents ought to not be computationally intensive, right? Advertisements of blazing fast JavaScript performance make me worry what corners have been cut.

hanniabu 2y ago
> wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?
- bee_rider 2y ago
  Haha, well that’s what I use now. I think it is the opposite though. I’d like a JavaScript implementation that doesn’t break any sites, but which makes absolutely no security compromises, even if that means they have to give up a lot of performance. Sometimes, I just have to load a site that has JavaScript running. Or is unfortunate, but some work sites don’t work without it, etc. I’m fine with those sites being slow (I’ll minimize my use of them naturally), but totally blocking them is slightly inconvenient.
  - sfink 2y ago
    Disabling (all of) the JITs is a decent approximation of this. It's very site-dependent as to how much of a performance impact it makes, but for many sites it'll be fine. Obviously this isn't the same as making "absolutely no security compromises", but in practice most JS-related security exploits go through the JIT iiuc. Your JS will be executed with a safe interpreter, where by "safe" I mean the dispatching and basic value manipulation are going to be simple enough to be bulletproof, and also slow enough to prevent most timing attacks. The underlying implementation of all of the built-in methods is still going to be more vulnerable, but those tend to be relatively safe as compared to JIT-optimized versions of them. They also don't change much, so have been tested for much longer as compared to the JITs that tend to get refactored and rewritten relatively frequently.

vlovich123 2y ago

Malware generally can't just "hijack" any arbitrary browser. You have to have exploits for a specific browser / browser family / JS engine. Chromium has defense in depth techniques to try to raise the difficulty bar and to try to limit the fallout of an exploit in various parts of the tech stack, but that still requires a Chrome-specific attack in the first place. Attacks for Safari / WebKit / JavascriptCore would similarly require a different vector for the exploit (even if some techniques are common, the specific details should be quite different). There is a newer class of generic malware that exploits CPU bugs (e.g. Spectre) - are you perhaps referring to that? If so, that's a fair concern but unlikely to matter much in practice. For Spectre itself, I believe the mitigations were applied within the major JS engines directly (or at least for v8 they were). Anyway, security issues are best compared when there's a lot more attention to your browser. But given that there's a huge amount of exploits that depend on buffer overflows that are simply impossible in the first place with Rust, it's likely that the browser's likely to mostly suffer only from architectural issues & fewer implementation issues whereas other browsers will still have architectural issues and implementation issues to boot that prevent them from addressing it. Yes, newer browser = likely more immature architecture, but at the same time there's fewer implementation issues to worry about in terms of exploiting architectural issues in the first place.