Q1)(Need) Why tightly couple the browser update to full OS update on #Chrome OS?
Even thou you (#Google) do provide better and long term support (from feature and security perspectives) to Chrome OS devices in general compared to many other product types out there, but because you many a times take atleast a month or so before the latest OS update gets perculated to some of the slow-support devices, aren’t they more exposed to the evils of the internetworked world for the duration between a updated OS+Browser gets released to the world and when the slow-support-devices get the update.
Or is it that security patchs are back ported to older versions for the slow-support-devices (I can see OP1 devices are in this category, among others)???
Q2)(Need) Why Not support encrypted removable storage devices by default in ChromeOS????
I understand that you are coming out with USB passthrough to the Crostini’s VM and inturn the containers. Not sure if a normal enduser will be able to use this path to work with encrypted removable storage devices, as containers don’t allow module loading flexibility. So unless you provide some direct end-user friendly access to the Crostini’s VM (currently they get dumped to the maya of maya) and or directly support encrypted storage, this wont work.
Also rather irrespective of whether one wants to work with Crostini or not, shouldn’t a ChromeOS user have access to encrypted removable storage from the OS itself. Sure with this mechanism one may not be able to use such devices with other OS’s like Windows or Mac to a great extent (Linux users can be relatively more lucky in many such cases), but atleast the end user as the flexibility to have secured removable storage atleast to themselves and a closed group of systems/users (if they so chose).
Q3)(Need/Want/… – go full hog) Why not provide a end-user controlled mechanism to selectively pass throu a network port from the ChromeOS environment to the Crostini Penguina???
Maybe you have some mechanism throu chrome://inspect. Have to cross check this yet. But otherwise, isn’t it something which would be useful, if you want to provide pretty good flexibility to the Crostini usage scenarios (which is either way for people with some experience with the way things work at one level, compared to a simple end-user), while still not compromising much because, You could link this port plumbing to user login. And on top eitherway the crostini and its children won’t start on its own by default, when a user logs in either.
Also support multicast both ways, when you are at it (if not already).