
ChromeOS will no longer support ext2/3/4 on external drives/SD cards - doublextremevil
https://code.google.com/p/chromium/issues/detail?id=315401
======
sah88
First you have to void your warranty to properly dual boot now this? They want
to drop support for a file format so they can make renaming drives easier?

I'm actually in the market for a new laptop/netbook. I was very close to
purchasing a ChromeOS device as I work primarily on a desktop and have a
laptop for travel but its pretty old, heavy and battery unfriendly. Then I
found out I had to void the warranty to properly dual boot.

Seems like a giant fuck you to the Linux community given how much Google has
benefited from Linux(ChromeOS even runs on the Linux kernel) and they put out
laptops that are more locked down than your average windows laptops? Pretty
disappointing.

I am assuming the write protect screws are there at the behest of Google.

~~~
JohnTHaller
It makes sense if you think of what the purpose of Chrome OS is. The point is
not to make inexpensive hardware to run any OS on. The point is not to create
a new general-purpose open OS that people can build on. The point is to get
people to put there stuff in the Google Cloud to become bigger Google
customers. Period.

That's why they make it difficult to dual boot and allow all your files to be
wiped with a single key. That's also why anything you do on the Chromebook
before you login to Google for the first time isn't saved. The point is to
make everything on the laptop appear impermanent and to get you to think of
the cloud as the place your digital stuff is actually stored.

~~~
moonchrome
I'm actually wondering why would people spend money on a chromebook - the
hardware is crap and the price isn't that great. If I was looking for a cheap
portable web browsing device I'd get something like : [http://www.onda-
tablet.com/onda-v975w-quad-core-win-8-tablet...](http://www.onda-
tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-
wifi-32gb.html) \- that's a 10 inch Windows 8.1 tablet with 2048*1536
resolution, quad core atom and 2 GB ram for 220$. Throw in 20$ and you can
find a USB case with keyboard.

Portable, better performance, better screen, can be used as a "internet
machine" with Win 8.

~~~
jadeddrag
But is it locked to Win 8? Can you easily install ubuntu on it, or is all the
hardware drivers closed source?

~~~
checkm33
No, it's not locked. But you can't install Ubuntu there (at least not easily).
Google for "32-bit UEFI" if you need any more details about the sorry state of
affairs with booting Linux on latest crop of Atom Bay Trail hardware. The only
out-of-the-box working distro for it is "fedlet" \- some obscure fedora
21-alpha fork.

~~~
hollerith
>Google for "32-bit UEFI" if you need any more details about the sorry state
of affairs with booting Linux on latest crop of Atom Bay Trail hardware.

There is at least one product with a Bay Trail CPU in it that runs Linux:
[http://www.phoronix.com/vr.php?view=19836](http://www.phoronix.com/vr.php?view=19836).

Unlike most Atom CPUs, the graphics driver for Linux on Bay Trail CPUs is
completely open (like it is on Intel Core CPUs), which I guess makes it doubly
sad that some manufacturers of products with Bay Trail CPUs in them are
screwing up with the boot loader.

------
DCKing
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
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
> 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
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
> 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
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
> 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.

~~~
lotsofmangos
That sounds like the same approach that everyone used with openSSL. The fact
that code is open source is not a sane reason not to test it.

~~~
DCKing
I sympathize with the general sentiment, but it misses the point.

Linux + ext kernel modules + e2fsprogs is tested daily by developers of many
Linux distributions. There's really no problem with verifying that some module
works. Furthermore, Google tests this system implicitly by haveing ChromeOS
use ext4 as its root file system. So everyone is right to be confident it
works correctly.

However, testing whether or not something _works_ is totally different from
testing whether it is _secure_. Many people testing whether OpenSSL works
correctly (which happens every single day) would not have shown Heartbleed at
all.

------
microcolonel
ChromiumOS developers can't even implement a script to relabel EXT volumes? No
wonder their kernel tree is such a mess, they must barely know what they're
doing.

Also, I'd say you can safely assume that those 1-2% of users that use EXT
volumes externally(which by the way, is a LOT of people, several million at
least) are developers, and this will surely piss them off.

~~~
cnvogel
Obviously no one can defend this decision with the labeling non-issue while
keeping a straight face, so time to guess:

What they are probably bitten by is the issue of ext4 actually keeping proper
uid/gid associations with files. The other FS they seem to support [exFAT,
FAT, UDF, NTFS] all are (as far as I know, and under Linux) completely
agnostic to permissions and user-IDs: everything gets squashed to one uid/gid
and fixed permissions.

Probably _that_ is the actual problem they want to get rid of and which causes
pains? They only mentioned the labeling as "features such as...", so there
might be more bugreports/requests...

Android (at least the Cyanogenmod variety on my phone) works around it with a
small fuse-shim that fixes user-visible permissions on the fly, for all FS,
including ext4. And ext4 makes for a very nice and well-performing fs on my
phone.

~~~
asveikau
> FS they seem to support [... NTFS] all are (as far as I know, and under
> Linux) completely agnostic to permissions and user-IDs

Uhhh... On Windows this definitely not true. The NT security descriptiors are
kind of complex and I could imagine nobody wanting to sit down and map them to
a Unixy system. But they are definitely there.

~~~
cnvogel
That's why I added: ...and under Linux.

I'm well aware of NTFS permissions, and use them daily, both in UI and
programmatically. Under Windows, though.

------
nkuttler
> On a related note, we may want to re-evaluate whether we'd like to continue
> supporting ext2/3/4 filesystems (~2% of users, and the majority is probably
> Chrome OS developers) in File.app.

Yes, please, drop support for something the developers use, what could go
wrong?

The title seems misleading though, it seems that only the built in file
manager will drop support for ext, and even then, maybe only for a specific
feature?

~~~
logicallee
>~2% of users

2% seems pretty high! If you make 50-70 kinds of these project management
feature-drop decisions, then if the groups are mostly distinct, you'll have
dropped 100% of your users (2% * 50 or 1.42% * 70 = 100%.)

Think of it this way. If only two percent of your users have a first name that
isn't in the top hundred first names in America, would you drop support for
first names that aren't on your whitelist, in some form field? (because you
want it to contain real data.)

I think it's better to think through the rationale for dropping support (for
example: If the people using this feature have a clear alternative, that is
also better, and that they know about and will try and like. Then it might be
acceptable In the first name example, the only rationale would be if this were
some kind of game or something and people weren't expected to use their actual
first name, and you also present them the list. Then it might work.)

The rationale presented here is very weak. "Only highly-paid people
(developers) trying to get work done use this, about 2% of our sales."
Marketing win?

~~~
cnvogel
It's not that bad in practice ;-)... Let's assume random distribution of used
features among your customers.

If you shoot randomly at your users with a 2% hit rate [alienate them by
dropping a feature], your user will stay with your product with 98%
probability. Do it 50 times, any user will have a 0.98^50 = 36% chance of not
having been hit [having at least one important feature taken away from him
that makes him stop using your product...], so only (100%-36%) 64% of users
will drop your product and go elsewhere.

~~~
nitrogen
Someone should have explained this to the GNOME team.

------
lucb1e
And thus we returned to the stone ages of unjournaled FAT(-like) filesystems
or bad NTFS driver implementations (the only good one is Microsoft's, and I
doubt they'll be handing over the code for Chromium).

It's not even something consumers see, it's a driver for crying out loud. It
doesn't even make sense to remove it for "product simplicity" as they are
claiming now.

Edit: Left a comment with another argument about FAT being a bitmap filesystem
(versus ext4's binary trees) and that developers are the people that are going
to code for their OS. Ignoring the 1% is not the smartest move.
[https://code.google.com/p/chromium/issues/detail?id=315401#c...](https://code.google.com/p/chromium/issues/detail?id=315401#c45)

~~~
wutbrodo
>It's not even something consumers see, it's a driver for crying out loud. It
doesn't even make sense to remove it for "product simplicity" as they are
claiming now.

I may be confused, but isn't the discussion about removing support in the
files app UI (while actual ext support remains in the console)? That would
mean the exact opposite of what you're saying: it's a UI change, not a driver
change.

------
imrehg
Of course as per Comment #21 someone has to make project management decisions,
but decisions like "Chromium OS is for consumer devices which should not need
support for mounting external ext4 storage" is just so painful to read. It's
just a pile of assumptions that goes against the evidence of given my a lot of
comments.

~~~
VLM
"is for consumer"

Generally speaking whenever someone starts speaking for the "other" they're
doing something wrong and they know it and the othering is just CYA speech.

------
vxNsr
I'm disappointed to see Chrome dropping features but it's even more
disappointing to see the comments after this hit HN front page:

>#37 vitalifs...@gmail.com

>Are you idiots to remove ext support? Don't want to explain more than that.

>Today (5 hours ago) #38 StromCl...@gmail.com

>Sounds very very stupid (to remove Linux standard file systems)!

>#42 Shve...@gmail.com

>Sorry but you guys are mentally retarded at best.

~~~
wutbrodo
Seriously: I was reading through the whole bug and finding the conversation
(both complaints and responses) to be quite informative until I hit 100 posts
of angry lunatics with nothing to contribute and often a misunderstanding of
the issue in the first place.

~~~
ecspike
It probably correlates to when it made Slashdot.

------
dscrd
Given that this is the main filesystem in Linux, and is thereby automatically
well supported by anything that leverages Linux, this choice makes absolutely
no sense. Somebody in Google decided this; somebody in Google is a total
idiot.

~~~
Guillaume86
Looks like Google have a politic to drop support for external storage and push
the cloud (or force it on us depending of your PoV), same story on Android:
[https://code.google.com/p/android/issues/detail?id=65974](https://code.google.com/p/android/issues/detail?id=65974)

------
userbinator
Security. Simplicity. Convenience.

Does it seem like these words are being used as a generic reason to justify
almost anything these days? I think that and the continued trend of removing
"developer-only" features are really going to decrease the number of future
developers (because of all the hoops they have to jump through), so they're
basically shooting themselves in the foot.

~~~
Dewie
Yeah... the following (which I assume that you're referring to)

> > 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.

Sounds reasonable enough. But it could be used to justify pretty much
anything.

------
xg15
It looks like this ticket was opened a year ago, during which almost no
discussion took place. People only started to voice objections after the patch
was already written and submitted.

I think it would be useful if tickets with breaking changes could come to the
public's attention a bit earlier than this time.

I have no idea how to find such tickets of course. The search function of the
issue tracker doesn't seem very helpful...

~~~
Intermernet
Very good point. It seems that this was tagged "Type-Feature" which is meant
to mean "Request for new or improved features".

I'm not sure how _removing_ functionality is a "new or improved" feature,
except from the developers POV due to reduced complexity. This is probably not
how the users would define "new or improved".

They possibly need a new tag for "Type-FeatureRemoval" or similar.

------
dingaling
Thereby entrenching the FAT patent fee scheme.

This is a very odd decision that originated in the difficulty of renaming
external volumes ( why was this considerd important? ) and then became
conflated with 'security'.

I believe the kernel modules are still there, though, so you can mount ext _x_
from the command line in dev mode. But not much use for everyday users.

~~~
danmaz74
BTW, when will those patents expire? Shouldn't be long I guess..

~~~
techrat
The issue is exFAT and Fat32 long filenames. exFAT was introduced with Windows
Vista and is what 32GB+ flash media tends to be formatted in. It'll be a long
time before this one expires.

~~~
caf
Does anyone know exactly what innovation(s) in exFAT is/are newly patented?
Which patents read on it?

~~~
techrat
From wiki:

>exFAT is a proprietary file system. However exFAT is protected under US
patent law, and its initial application was issued on 10 July 2009 under the
application number US2008168029.[7] On 12 November 2013, the patent was
granted by the US patent office under US8583708.

Patent length is 20 years, so we're looking at least until 2033 before exFat
is expired and (safely) freely usable.

~~~
cowsandmilk
> Patent length is 20 years, so we're looking at least until 2033 before exFat
> is expired and (safely) freely usable.

Nope. For the dates this was filed, length goes from filing date. Depending on
how dangerous you want to be, you could argue it expires anywhere from
2024-2028.

------
shams93
Yeah I was wondering why I suddenly couldn't load my crouton on external 64
gig stick, really annoying google blew off my entire android development
environment.

~~~
redthrow
Is there any reason why you want to keep ChromeOS at all?

[https://www.distroshare.com/distros/get/14/](https://www.distroshare.com/distros/get/14/)

------
logicchains
I wonder how the cost of maintaining ext2/3/4 support compares to the revenue
loss from Linux developers abandoning your platform in droves...

------
mike-cardwell
Even if I didn't care about Ext support, there's no way I'm going to buy into
Chrome OS now. Who knows what other important features they'll remove in
future for the sake of "simplicity"

------
chris_wot
One of the comments said that there was some sort of security exploit because
of extra features. I really have to question what sort of reasoning this is,
and what sort of maintenance burden they expect from this?

~~~
kentonv
It is true that the ext4 filesystem driver is a large attack surface that is
probably not well-vetted for the possibility of a maliciously-crafted
filesystem (since the usual threat model comes from the opposite direction).
If it has vulnerabilities, this could allow someone to create a USB stick that
pwns the host system when inserted.

This is, of course, equally true of all the other filesystem drivers. But
fewer total drivers available clearly means less attack surface.

So, yeah, it's a legitimate concern.

~~~
danieldk
_It is true that the ext4 filesystem driver is a large attack surface_

The problem is that reasoning can be applied to any feature you want to get
rid of. A good reason would be, _we had N vulnerabilities in ext4 in the last
six months, which is more than the kernel FAT support, which had only M
vulnerabilities_.

Besides that, the attack vector seems fairly theoretical to me. Most users
will take a blank SD card and format it as ext4 themselves.

~~~
kentonv
> The problem is that reasoning can be applied to any feature you want to get
> rid of.

Well, of course it can. That's more or less the Chrome team's point: they want
to remove any feature that isn't widely used, because every feature is an
attack vector.

> A good reason would be, we had N vulnerabilities in ext4 in the last six
> months, which is more than the kernel FAT support, which had only M
> vulnerabilities.

Not really, no. The absence of reported vulnerabilities in a time period could
mean that there are none, but more likely it just means no one has looked,
like with Bash. The things you need to ask yourself when considering attack
surface reduction are:

* How complicated is this piece of code? (More complication = more bugs.)

* Is it likely that this code has been well-studied with respect to the proposed threat model? (For ext4, probably not -- it's designed to be used on your internal disk, which is not an attack vector.)

* How painful would it be for users to simply remove it? (Obviously, removing ext4 harms far fewer users than removing FAT, developers notwithstanding.)

> Besides that, the attack vector seems fairly theoretical to me. Most users
> will take a blank SD card and format it as ext4 themselves.

Theoretical? Flash drives loaded with malware are an actual, widely-used
attack vector, used by everyone from simple identity thieves to governments
(look up Stuxnet, which was used to damage Iran's nuclear infrastructure).

Things have gotten better since Windows stopped auto-running software on such
drives, but a filesystem exploit that kicks in on mount would be more
effective and harder to detect (no telltale files visible in the file
browser).

~~~
kentonv
OK, I actually asked a kernel dev friend about this because it affects my work
on sandstorm.io, and he says that defense against malicious filesystems is in
fact something Theodore Ts'o, the ext4 maintainer (and Googler), cares deeply
about. Awesome!

Now, that doesn't automatically mean it's safe, but given this new piece of
information, I'd say that the case for removing ext4 for attack surface
reasons is significantly weakened.

------
antman
Android KitKat and ChromeOS SDCard blunders pretty much show Google's policy.
They have me searching the forums for another unnecessary rooting procedure.

Simplicity should be optional and easily disabled through a checkbox in
settings. I am afraid FirefoxOS will make the same assumptions.

~~~
zanny
> I am afraid FirefoxOS will make the same assumptions.

I'll punch myself in the face the day Mozilla stops supporting patent
unencumbered free and technically better filesystems for patent encumbered
proprietary Microsoft specific crap.

------
mrmondo
I am actually left speechless. Who on earth thought this was a good idea?

------
nodata
Because they can't relabel an extX volume? How does that make any sense?

------
nickthemagicman
Is is possible to just wipe chromeOS off of a chromebook and install a full
Linux (with reasonable driver support)?

~~~
ewoodrich
Yes, you can. And Chrubuntu has great driver support for the c720 and other
popular models, but I still ran into some bugs with suspend and Wifi, so I
stick with a chroot.

~~~
nickthemagicman
Is chroot just using the built in command line?

~~~
ewoodrich
[https://github.com/dnschneid/crouton](https://github.com/dnschneid/crouton)

Crouton is a install script that uses a chroot to install Ubuntu through the
shell on ChromeOS. You still need to enable developer mode, and it uses the
ChromeOS kernel, but other than that it looks and feels like a "normal" Ubuntu
installation.

------
cpks
All I have to say is fuck Google. I would never use a Chromebook, for a
hundred reasons. However, sabotaging Linux support in this way is both
shortsighted, aggressive, and moronic.

Our kids need to learn to use computers. Not just use Word and Internet
Explorer, but learn to hack. Not just consume, but create. Computers 30 years
ago were tinkerable. Google is doing everything in its power to take away that
tinkerability, and worse, to undermine tinkerable systems.

------
kzahel
I'll be glad if ext* support is removed from Files.app. I once had it corrupt
my externally mounted ext3 hard disk and lost a ton of data. I never should
have been doing that kind of thing with Files.app in the first place. It's
really only designed to be used with your "Downloads" folder where there's a
warning that all your files might be auto-deleted anyway.

------
derpenxyne
A member of the team has just opened a potential solution to the problem
through the new chrome.fileSystemProvider API: crbug.com/422764

~~~
Vendan
And, as I already posted, it's a rather idiotic one. Does the project member
not understand the issue? Kernel support hasn't been removed yet, just the
userspace stuff. Last thing we need is to rewrite existing, solid code in JS.

------
riffraff
what is the root filesystem in ChromeOS?

~~~
shaurz
ext4

------
ghshephard
This issue was closed July 21st, 2014 - anybody care to comment what inspired
its discussion today?

~~~
cowsandmilk
pushed out in the last week as part of stable release version 38 of chromeOS?
There are hundreds of thousands of tickets, end users won't follow those, they
care once stuff lands on their systems.

------
higherpurpose
Does it support F2FS then? That would be for the best.

------
bert2002
luckily notices this before my trip... what the hell?

------
Dewie
I guess that chromebook laptops are cheap (?). Chrome OS seemed appealing to
me initially, because of the short start up time. But then, reasonably sized
SSDs became affordable[1], and any faster boot times than what Linux + SSD can
give me is kind of _meh_ , to me.

What are the advantages of ChromeOS over other operating systems?

[1] And if you are considering a Chrome OS laptop, chances are that you won't
be needing something like >500GB storage for it, I would presume.

------
mcguire
The important takeaway:

" _Chromium OS is for consumer devices which should not need support for
mounting external ext4 storage._ "

~~~
shaurz
Am I not a consumer then in their eyes? I use ext4 on all my external media
and I don't develop for Chrome OS.

