+alex, bartfab
do you know what these are?

It looks like CloudDPC is installing a MitM CA cert.

I think this notification is intended? I saw this warning in non-ARC Android as well.

Yup. It's working as intended if any additional certificate authorities have been installed.

How it is intended to work should be changed. That is the point of my bug report.

I could understand where the installed root CA's have changed - you could notify the end user.

The pushed root CA's are NOT changing. Why does the system inform me every single time that root CA's have been installed?

The certs in question are Corporate root CA's. Informing the user of these is unnecessary and confusing.

On Windows PC's when corp root CA's are installed via Group Policy - there are no warnings to the end user.

Corporate issued root CA's are part of the required policy - we dont need to or want to have our users bothered with POINTLESS ERRORS.

How can we educate our users to be "security aware" when their Chromebook is needlessly peppering them with "null" security warnings!???

This is consistent behaviour with Android.

Installing corporate issued root CAs undermines the security of the users, and is not limited to their corporate activity. For example, users interacting with services using their personal accounts may have their usernames and passwords intercepted or the content modified.

Users sign an acceptance policy when they are on-boarded.

Acceptance policy includes verbiage: "you agree to be monitored".

Quite frankly, something with the user's personal accounts while on company managed devices - is NOT our problem. And users have already agreed to that practice.

Your missing the boat here on corporate reality.

Not only that, but the pop-up does not tell the user their personal passwords are being intercepted!

Someone would have to be a ChromeOS/Android infrastructure engineer to understand the implications of this "security feature"/warning.

Our users would see this error only as pure confusion.

Note: These policies are consistent with and implemented by the Android platform and the standard behaviour of Android devices. The notification is derived from and part of the Android platform, which the ARC++ runtime allows you to experience on your ChromeOS device.

A Chromebook is not an Android device.

Users are NOT warned at the ChromeOS level that root CA's are being installed. (the warning is coming from ARC++)

ARC++ should inherit the behavior of ChromeOS and how it treats root CA's.

As you are integrating the ability to run Android Apps on ChromeOS you should recognize that certain things MUST be changed - to "align" with ChromeOS.

Not everything is "drop in" without zero modification.

If you slap them together and do not align things as they should be - then Android apps on ChromeOS will NOT be all it is hyped to be. Users will reject it because inconsistent experience.

dskaram: I believe this is WontFix, but I'll let you close it. I'm moving it out of our untriaged >Certificate queue.

Note there's some additional feedback from the Security UX team in  Issue 802215  regarding surfacing additional administrative warnings when root CAs are installed on ChromeOS, to better inform users.

Is my understanding correct in that:
Are these additional trust anchors delivered through Chrome OS' OpenNetworkConfiguration policy, then sent over to ARC's CloudDpc using arc_policy_bridge, then installed there with the notification, and the notification is surfaced on the Chrome OS Shell?

If yes, then it's indeed slightly weird that whether the user gets a notification about this or not depends on whether they run ARC++ or not.
On the other hand, if a policy-provided is used in server certificate verification in Chrome, the Enterprise icon will be displayed in the URL bar. If the certificate is used in <random ARC app>, there will likely be no other feedback, so one can argue this notification is useful.

Just imagining: Maybe the nicest thing would be to be able to dismiss a notification with an "ok and don't tell me again" button, then the user is aware but can decide to ignore this notification for the future. Not sure if anything like that is planned on the notification UI side of things though.

+Drew, Ivan

BTW, Drew+Ivan, I remember there was an effort to give better/more concise information the user about management/situation (maybe including additional trust anchors?), somewhere in the context of the Managed Sessions project.

What is the status of that? If it still exists, would this give information about the policy-provided trust anchors and what they mean in a clear enough way that we could suppress this notification? (this would be a product question, let's not discuss how we'd actually suppress such a notification until we decide it is a good idea, which I'm not sure about).

 Issue 923489  has been merged into this issue.

 Issue 923099  has been merged into this issue.

The additional two reports (duped into this) - see above - suggest that more users are gettng confused by this.

Pavol, thx for bringing this up. Trust anchors are indeed part of the transparency view (coming in M73). Design here: https://docs.google.com/presentation/d/1bR6m842mkx8UVvuo3wqR64ON4wS8gowbuspA8hWoBbI/edit#slide=id.g42814dd1d4_0_1

Remaining question: How often do we see similar setups. +aghuie to provide info

+tnagel - What's your take from a privacy perspective? Would it be OK to move the warning into the transparency view?

The CrOS notification is a passive icon today, while it's an active notification for ARC++. 

We should make the end user experience the same since a user isn't likely to differentiate between CrOS vs. ARC++ and a passive approach has already been implemented prior to ARC++. I see no reason why that approach should be any different in ARC++.

Many customers deploy with certificates today and this will likely become a bigger and bigger issue as ARC++ applications are adopted more widely.

re Comment #22: The current UI difference is the result of CTS requirements, which require active display. Probably worth checking w/ the team responsible for compliance with those.