I forgot to add another important use case for user access to "Unknown Sources": lots of people around the world use nearby file sharing apps like Share-It, Zapya, etc.  because the internet is unavailable, too expensive, or blocked.  None of those apps will work without "Unknown Sources"

I support this request.

It should absolutely be possible to enable unknown sources on devices when not in developer mode, this is vital to the openness of the system. Without this the OS can't be used in many situations where it is otherwise impossible to install apps.

Forcing users into developer mode is a big security risk.

We shouldn't have to use any Developer Mode to use open source app repositories like F-Droid, or discount app stores (where a 30%+ charge on a pay-what-you-can transaction with charity makes little sense) like Humble Bundle.

+xzhou FYI.

Work as intended for security reasons. 

APK sideloading weakens verified boot and allows unverified native code running on the device. The attacker could use sideloading apps to:
1. Persist their attacks.
2. Distribute malicious APK outside Play Store.
3. Exploit known vulnerabilities in sideloaded APKs. For example, Play Store will check for insecure uses of HTTP/HTTPS.

So, for now we only allow sideloading in dev mode.

There are valid security threat models where any singular source, such as the Google Play Store, would in itself constitute an availability threat during turmoil. For example: a national takeover of all Internet infrastructure allows a bad government actor to pretend to be Google Play services, including the sole source of all security and app updates. A user-selected alternative installation and update source like F-Droid could mitigate this threat by providing an alternative route to security updates whenever the primary source (Play Store) is compromised, particularly when it offers an alternative or competitive form of transit cryptography and trusted signature confirmation.

Lack of retail source competition is in itself an economic security threat.

It makes perfect sense to require developer mode to sideload chrome apps because a chrome app is a website, and anyone who can make a website can also just post the website to a webserver, and then any Chromebook would access it.  So there is only a tiny trade-off to restricting how chrome apps are installed.  Even if the internet is restricted or unavailable, local networks and servers will still work here.  With Android apps on Chromebooks, you're dead in the water.

Android APKs are a different story, and that's why Android itself has always supported user-controlled "Unknown Sources". If someone wants to run an Android app on a Chromebook that's not available in Google Play or the internet is not available, they are totally blocked.  

One use case that is quite important to me is using Chromebooks as a hardened travel laptop.  If I go to China, I cannot install Android apps on it since Google is blocked there.  Switching to developer mode for this scenario totally defeats the purpose.

In this case, we've decided to fall on the security side of the security-usability tradeoff.

Webpages and Chrome apps run in Chrome renderer processes that have little access to the rest of the system. The Chrome sandbox prevents most access to the file system, networks, and presents a heavily-restricted kernel attack surface.

Android apps, on the other hand, run in a significantly looser sandbox. They have access to almost all of the host kernel (at least in Android N, which is currently shipping on Chromebooks). Moreover, not only do Android apps have significantly more access to the host kernel, they're also not covered by Chrome OS's verified boot: apps are downloaded from the Play Store, but then they're compiled to native code on-device and therefore that code cannot currently be verified.

The combination of significantly higher exposed kernel attack surface + unverified code means that we need to rely more heavily on the scanning done by the Play Store to root out malicious apps. Therefore, we cannot realistically allow sideloading in Verified mode and still call it "Verified". Those apps could contain trivial bugs or vulnerabilities and would have extensive access to the host kernel. Hence the dev-mode requirement.

This is currently working as intended. We can consider changing this restriction when we make the Android app runtime as restricted as a Chrome renderer process.

We have been talking about how to enable unknown sources without dev mode for a while, and have a proposal.  Note: this is not as simple as just letting users turn it on through Android settings for the reasons mentioned by jorgelo@ and others above.  There will have to be some friction to enabling/disabling unknown sources to be able to reason about the security of the device, and it will take time to implement.  Optimistically targeting M-65 ATM.

That's great news! Given the perceived security tradeoffs above (which are not purely security vs. usability in that they completely ignored the known threat models I already indicated -- fraudulent Google certs have been created by powerful State actors before after all), maybe the proper framing of this problem isn't to simply duplicate the other Android releases' "Unknown Sources" option, but instead to add an "Alternative Trusted Repositories" option for users/admins to define one or more their own. If I'm not mistaken, they can already install multiple vulnerability scanners of their own, so the premise of forcing dependency on solely the Play Store scanner is already moot. This also seems to be a better match with the Android Oreo APK source permission model.

Based on my IT experiences, I'm sure there's plenty of businesses that would love to be able to deploy internal-only tools repository access to all employee devices in this fashion, without giving everyone a "developer" level of access to company-owned devices. This would also satisfy the open source users (like myself) who just want to define their own OSS repository sources based on tangential trust systems, not to give blanket APK access from all sources vs. just one. This would be so useful, in fact, that maybe it should go upstream into AOSP directly? Is the Android Oreo APK source permission model already effectively the same thing, and could it be ported back to Nugat?

I think what you describe is indeed, essentially, the new Oreo APK source permission model. I don't think it's feasible to backport that to Nougat though, but I agree that it is the right way to solve this problem.

I imagine that when Android on Chrome OS moves to O+, we can provide an APK source that's managed by Chrome OS and that allows more flexibility.

Does "targeting M-65" in #13 mean version 65 of Chrome OS? I see v65 is already available on the beta channel. Is there any update regarding this bug?

I don't think M-65 there is accurate anymore.

He did say "optimistically" tho. Is there a new estimation then?

I'll let Elijah comment on that since he's overseeing this process.

Any updates on a new target release?

The M-65 target was indeed far too optimistic. For security and other reasons, we're delaying this until M-69 at earliest to align with other ongoing work.

Would love to see this sooner than later, especially now with the support for Linux apps. I really look forward to be able to run Android Studio and deploy my apps directly to my Pixelbook without having to set it to developer mode. 

69.0.3464.0 on dev channel has been released. Still cannot find the option. Any updates?

A technical question:
   As explained by jorgelo, the major security concerns about sideloading APK are higher exposed kernel attack surface + unverified code. I wonder if the same applies to Crostini, which runs Linux in a container having access to most kernel interface and also runs unverified code. What is the key consideration that separates the security policy of Android from Crostini?

Crostini (including the container) is running in a virtual machine, while APKs are not. Therefore, in Crostini the kernel attack surface is that of the *guest* kernel, while for sideloaded APKs the kernel attack surface is that of the *host* kernel, which is shared with the rest of the Chrome OS system, and therefore significantly more critical than a guest kernel.

Thanks, jorgelo, that makes sense.

Maybe after accelerated graphics is supported in Termina, Android can be put in another container inside Termina. In this way, sideloading APK can be relaxed automatically.

Doesn't ARCWelder allow this, essentially?

I just tried it, and it worked fine with a random APK I had laying around.

ARCWelder is the older implementation that's based on NaCl (Native Client) if I'm not wrong, while what we use on our Chromebooks is ARC++ that's based on some form of containers. ARCWelder didn't use any form of VM, and was buggy for quite a few apks apparently (None of those that I tried long ago worked).
PS: Sorry for the OT @ the chromium guys and gals

Is this still expected to release in M-69? 

Posting to subscribe. This is mostly a semantic argument and I understand and agree with your decision making, but what you are doing isn't justified from a security standpoint, since you are forcing ordinary use case users into an insecure environment. Instead what justifies your decision is the Pareto principle; you are making ChromeOS more secure for 80% of the users and less secure for 20%.

Please keep up the good work. While a third mode that retains most of the security built in to ChromeOS but allows sideloading apps is sorely needed, this is definitely the sort of thing that needs to be done correctly and needs to be well thought out, and I am more than happy to wait a few years for a good compromise feature.

Until then I'd also like to commend you for the thought you put into Chronos, and the robustness you already added to developer mode's security. It is nice to be able to "roll my own" mode between developer mode and standard mode until you get this sorted. I'll admit I've groaned about powerwash before, but honestly resetting to factory is something I frequently do with any OS anyway and encrypting and backing up sources is a habit I formed as a developer long before using my pixelbook.

I would really like to see this feature as well.  I'm a developer and would like to permit specific approved android applications run our our daughter's chromebook, but don't want to leave her using a less secure device by switching to developer mode.
I completely understand and agree with the need to protect the average user from violating the security of their device.  I think they key is to make it possible, but also so much of a pain for a non-developer that it passes the threshold of effort that the average user would be willing to do to install whatever scam they're being offered, but a developer still could due to being more comfortable working in the shell / setting up servers etc.

Maybe something like:
1) You have to wipe your device to get in to developer mode ONCE to access a special serial number from the terminal that you're only allowed to read in developer mode, maybe by typing in a command like "thisCanBeUsedToHackMe".  This should already deter a lot of people due to the need to wipe everything, but if an organization or individual wants to, they can record this number when first setting up the machines.
2) On a different machine, you spin up an apk server that's initialized with the machine-specific serial number(s).  Most developers will be much more comfortable spinning up a server than an inexperienced user, and it's limited to specific machines, so can't be used to target lots of uncooperative users.
3) After switching back to non-developer mode on the chromebook, you can only sideload an APK from the local network and from a apk server setup with the machine's serial.  This prevents drive-by downloads from shady adverts outside the network, nor running a service for everyone regardless of serial.

If you were worried about 3rd party apps being made to make it too easy/user friendly to run the server, you could do things like custom challenge/responses that have to be typed in crosh that a guide can't know the answers for in advance while doing a download, or require the server be run from the chromebook itself with a long series of terminal commands that aren't copy & paste / script friendly.  This is one of the very rare times we're actively trying to make usability worse for non-developer users.

The above are just some straw man ideas, but the bottom-line is that I believe it's important we allow individual developers to add content to the devices that they administer (and not only in a corporate managed environment), WITHOUT giving up the normal security model for the device's regular users.

Thanks everyone for your patience while we work on this.

To set expectations, we do have a design and large part of the implementation done and ready to go, but we're waiting on some significant changes on our Android implementation before being able to land and turn this on.  Retargeting to M-72 for now as the dependent changes are expected to land in M-71 and then we can start landing "unknown sources" support.

72 is out in the wild now. Any updates?

Chrome OS security team is working on a design that can better secure side loading. 

This is much needed.

It seems like we still don't have it in M72. Maybe it's been pushed off to M73?

Can a developer please comment. This has been pushed back a few versions
already.

Ahmed Chandab

On Wed, Nov 28, 2018, 8:52 AM hexin… via monorail <
monorail+v2.1710676136@chromium.org wrote:

+1 this should be possible without developer mode.

Hi folks,

Thanks for being patient while we sort this feature out.  I can give some details, but don't want to commit to an exact milestone given that this has been punted a few times already.

We're still working on this, and would like to be able to deliver in the next couple milestones (M-74/M-75 timeframe hopefully).  Unfortunately it's been pre-empted a couple of times due to higher priority issues; for instance, you may have seen we've recently launched Android Pie on Pixel Slate and have been starting to roll it out to more devices.

We'll provide more details on this bug when we can, hopefully in the form of landed code reviews as we get further into the development of this.