5 ms·

Chromium is open source, the extension is open source and it runs on nativeclient which itself is open source and was designed and audited to be secure and sand

Chromium is open source, the extension is open source and it runs on nativeclient which itself is open source and was designed and audited to be secure and sandboxed. Making it secure and sandboxed was part of the initial goal of both Chromium and nativeclient, and again, they and the extension are all open source and audited daily by Google engineers and tons of security companies.

dsr_ 14y ago
Chromium is open source. Chrome is not. It is perfectly possible that Google is doing all sorts of Evil Stuff (TM) in the binaries that they ship out. I don't think it's likely, because a fair few people will be examining the packets it sends -- but it is possible.
- EricBurnett 14y ago
  The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.
  - mcpherrinm 14y ago
    Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. With Chrome, that isn't possible. It is based on Chromium, but includes non-open source code, and so you cannot immediately build it. However, in the end, they're just executables. Looking at assembly isn't quite the same as looking at source code, but we could examine the additional components and try to identify any malicious parts. At least in theory -- the work involved would be quite big.
    - tonfa 14y ago
      > But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
      - mcpherrinm 14y ago
        That's true. I know profile-guided-optimization is used for Windows builds; unsure on other platforms. Actually, this sounds like a fairly interesting project to me: Given a tool chain and a source code base, can we prove this was a possible compilation? In the case of deterministic compilers this is trivial, but as you highlight, not all optimizers are.
        LukeShu 14y ago
        I'm fairly certain that PGO is used for all of the official binaries. I do know that Arch Linux's package (which is from source, not official binaries) is compiled with PGO, so the support is definitely there.
        Hello71 14y ago
        The scripts used to automate PGO are in the official repository.
    - DannyBee 14y ago
      All non-open source code in chrome should be in plugins (or otherwise separate DLL's), not chrome's main binary. If you know of a case where this isn't true, please let me know. You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
    - groby_b 14y ago
      Theoretically, you should be able to compile a bit-identical release. Practically, you won't. (Or at least, I'd be very surprised) Re-creating bit-identical copies is hard when you _try_ to make it happen for your project, and I can't see any active efforts for that in most OSS projects. Timestamps in .o/.lib files, use of system libraries, optimization heuristics, exact versions of the entire toolchain, and many more "fun" issues prevent that from happening, usually.
taligent 14y ago
Do you really think open source and security audits actually means much ? You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them.
- BitMastro 14y ago
  >You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them. Yes, and your point is? Security audits do mean much, that's why they are done. Open source means a lot as well, it means that if I don't trust a software, I can check it if I want to, rather than accepting what a company is telling me. There's a reason why cryptographic stuff is almost exclusively open source, it's because security through obscurity doesn't work. That said, the amount of exploits for open and closed source software is more of less equivalent, but the time to fix is usually shorter for open source code.

dsr_ 14y ago

Chromium is open source. Chrome is not. It is perfectly possible that Google is doing all sorts of Evil Stuff (TM) in the binaries that they ship out. I don't think it's likely, because a fair few people will be examining the packets it sends -- but it is possible.

EricBurnett 14y ago
The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.
- mcpherrinm 14y ago
  Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. With Chrome, that isn't possible. It is based on Chromium, but includes non-open source code, and so you cannot immediately build it. However, in the end, they're just executables. Looking at assembly isn't quite the same as looking at source code, but we could examine the additional components and try to identify any malicious parts. At least in theory -- the work involved would be quite big.
  - tonfa 14y ago
    > But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
    - mcpherrinm 14y ago
      That's true. I know profile-guided-optimization is used for Windows builds; unsure on other platforms. Actually, this sounds like a fairly interesting project to me: Given a tool chain and a source code base, can we prove this was a possible compilation? In the case of deterministic compilers this is trivial, but as you highlight, not all optimizers are.
      - LukeShu 14y ago
        I'm fairly certain that PGO is used for all of the official binaries. I do know that Arch Linux's package (which is from source, not official binaries) is compiled with PGO, so the support is definitely there.
        Hello71 14y ago
        The scripts used to automate PGO are in the official repository.
  - DannyBee 14y ago
    All non-open source code in chrome should be in plugins (or otherwise separate DLL's), not chrome's main binary. If you know of a case where this isn't true, please let me know. You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
  - groby_b 14y ago
    Theoretically, you should be able to compile a bit-identical release. Practically, you won't. (Or at least, I'd be very surprised) Re-creating bit-identical copies is hard when you _try_ to make it happen for your project, and I can't see any active efforts for that in most OSS projects. Timestamps in .o/.lib files, use of system libraries, optimization heuristics, exact versions of the entire toolchain, and many more "fun" issues prevent that from happening, usually.

taligent 14y ago

Do you really think open source and security audits actually means much ? You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them.

BitMastro 14y ago
>You only to have to look at Java and Windows to know that security exploits can exist for years sometimes decades without anyone noticing them. Yes, and your point is? Security audits do mean much, that's why they are done. Open source means a lot as well, it means that if I don't trust a software, I can check it if I want to, rather than accepting what a company is telling me. There's a reason why cryptographic stuff is almost exclusively open source, it's because security through obscurity doesn't work. That said, the amount of exploits for open and closed source software is more of less equivalent, but the time to fix is usually shorter for open source code.