4 ms·

The title of this article is needlessly inflammatory. Can some mod change it? ChromeOS is not dropping support ext* at all; its files application that is meant

by DCKing 12y ago

The title of this article is needlessly inflammatory. Can some mod change it? ChromeOS is not dropping support ext* at all; its files application that is meant to be used with external drives is. That's a pretty huge difference. I actually think the rationale for this is pretty good: > Re #19, we understand that this was an undesirable decision for some users, but we sometimes need to make a product decision like this. Chrome and Chrome OS strive for simplicity. Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits (as mentioned in #12). We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason. It's a shame for the people who were actually using this. But lots of people are overlooking that this is just about the ChromeOS files application: ChromeOS can still mount and access ext* drives in general through its Linux kernel and utilities, Crouton and the likes can still use it, and people who specifically need to use the files app for whatever reason have plenty of choices for a file system.

lotsofmangos 12y ago
If the worry is that ext* support widens the attack surface, how does removing support from the files app but not the OS, actually help much? The security argument sounds like excuses being made on the fly if a feature is left in and just hidden from userland.
- DCKing 12y ago
  > If the worry is that ext* support widens the attack surface Clearly, security is not the worry. The worry is that they have to lose time, effort and code simplicity on making te files app work with ext* systems. Additional code complexity has many downsides [1], only one of which is the security concern. Security is a concern that the ChromeOS developers and end users share, so that is why it is mentioned. Maintaining code dealing with ext* in the file manager app has many small disadvantages, of which the security risk is also one. This is not about the risks of "having ext exist in the system in general", this is about the disadvantages [2] of maintaining "your own additional code to handle ext systems". [1]: I feel this issue is waved away so many times, while HN especially should know better. [2]: I'm aware that these things appear to be really small disadvantages, but the ChromeOS developers argue that the advantage of supporting it in the context of a program meant for external storage are even smaller, which I think is understandable.
  - lotsofmangos 12y ago
    The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Removing it from UI tools just means that it will be tested less, so while it may reduce complexity and increase security in one app, it actually could make things worse for the OS in general. It feels that mentioning security as part of the reason was just trying to justify the decision after the fact.
    - DCKing 12y ago
      > The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Could you explain why? Especially 'thoroughly'. > It feels that mentioning security as part of the reason was just trying to justify the decision after the fact. No doubt. The actual reason is "we don't want to maintain this piece of code anymore because of the added complexity". Security concerns are merely a consequence of this added complexity. That does not mean it is false to say it, though.
      - lotsofmangos 12y ago
        Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. edit- the way I look at code security is that trying to write good code in the first place is not as important as the testing regime to find bad code, so while there is a risk of introducing new bugs by supporting ext* in the files app, this is counterbalanced by the risk that the underlying ext* implementation will not be included in as many tests.
        DCKing 12y ago
        > Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think. In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.

by DCKing 12y ago

lotsofmangos 12y ago

If the worry is that ext* support widens the attack surface, how does removing support from the files app but not the OS, actually help much? The security argument sounds like excuses being made on the fly if a feature is left in and just hidden from userland.

DCKing 12y ago
> If the worry is that ext* support widens the attack surface Clearly, security is not the worry. The worry is that they have to lose time, effort and code simplicity on making te files app work with ext* systems. Additional code complexity has many downsides [1], only one of which is the security concern. Security is a concern that the ChromeOS developers and end users share, so that is why it is mentioned. Maintaining code dealing with ext* in the file manager app has many small disadvantages, of which the security risk is also one. This is not about the risks of "having ext exist in the system in general", this is about the disadvantages [2] of maintaining "your own additional code to handle ext systems". [1]: I feel this issue is waved away so many times, while HN especially should know better. [2]: I'm aware that these things appear to be really small disadvantages, but the ChromeOS developers argue that the advantage of supporting it in the context of a program meant for external storage are even smaller, which I think is understandable.
- lotsofmangos 12y ago
  The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Removing it from UI tools just means that it will be tested less, so while it may reduce complexity and increase security in one app, it actually could make things worse for the OS in general. It feels that mentioning security as part of the reason was just trying to justify the decision after the fact.
  - DCKing 12y ago
    > The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Could you explain why? Especially 'thoroughly'. > It feels that mentioning security as part of the reason was just trying to justify the decision after the fact. No doubt. The actual reason is "we don't want to maintain this piece of code anymore because of the added complexity". Security concerns are merely a consequence of this added complexity. That does not mean it is false to say it, though.
    - lotsofmangos 12y ago
      Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. edit- the way I look at code security is that trying to write good code in the first place is not as important as the testing regime to find bad code, so while there is a risk of introducing new bugs by supporting ext* in the files app, this is counterbalanced by the risk that the underlying ext* implementation will not be included in as many tests.
      - DCKing 12y ago
        > Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered. If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think. In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.