Mattias, would that work for you?

FWIW, the proposed wording SGTM.

That's very confusing to users who definitely don't know what Active Directory is and almost absolutely not what a realm means :-)

I don't fully understand the concern here. To get into a user session, the user has to have credentials on that domain (we don't support GAIA users on those devices). Are we thinking that an evil admin somehow convinces unaffiliated users to login with their credentials into the evil admin's own domain?

David, this is for the case where the *device* is managed by AD, but the user may be not (e.g. a gmail account or guest session). If such a device said "This device is managed by google.com" on a device that happens to be joined to an AD domain called "google.com", chances are not even you or me would notice that this is not a google.com cloud-managed device.

Understood, but for v1 all non-AD user modes are off. Allowing Guest and GAIA sessions on the device has many other implications than just what we show in the tray which is why we simply scoped it out for V1 till we see the use case and want to start building for it.

So let's solve this when it starts being a problem i.e. when we introduce non-AD modes into Chrome.

Can we please still change the string to call out the difference? This is not about allowing other user sessions, this is about being transparent that a device is AD-managed, not cloud-managed.

> Understood, but for v1 all non-AD user modes are off.

I don't remember any discussion about disabling guest mode.  Right now, it is *not* disabled, and I would prefer to keep it that way since it's an indispensable tool to debug login failures.

To address your realm concern, how about "This device is managed by Microsoft® Active Directory® domain 'example.com'."?

Discussed further with Thiemo offline. For the average user, saying either "by google.com' or "by MSFT AD domain 'google.com'" will make them think this is indeed google.com managing the device since they don't really understand what an AD domain is. So changing the message won't necessarily change the risk of being spoofed.

The best we can do is "This device is enterprise managed". Today clicking on that is taking the user to a page talking about device management. We can take beef up the page to explain to the user the risk involved.

+atwilson for any other ideas.



Overall, I would love if we can get a clear statement around when we consider "Game Over" to have happened, beyond which extra mitigations from our side aren't really enhancing the user's security but just making us feel good about things. If a user accepts using a device they don't trust the owner of, that device could contain any modified flavor of Chrome OS (including a one that says on the tray 'managed by google.com'). So we need to make sure extra work or in this case extra confusion for the 99.99% legitimate use cases is worth the security hedge for the 0.01% attack.

+atwilson for real

Point is, we don't let the device admin do anything damaging to the user, so I don't think it matters what we put there - it's just informative anyway. "Your device is administered by 'foo.com'" is about as useful/actionable as "Your device was built in Guangdong, China".

So I don't care one way or the other, and I don't understand why users should care either. It might be useful at the signin screen if someone wants to understand who to complain to when they aren't able to sign in using their Gaia credentials or open a guest session, but that's about it.

Mattias, can you confirm what the actual attack is with an AD realm with a misleading name (overlapping a Dasher domain)? What does this let the admin do?

We originally put the message on the login screen and the tray menu to allow the user to (1) discover that there's a 3rd party controlling the device and to (2) get an idea who that entity is.

Regarding why the message is useful to some users: I might trust one org (i.e. google.com), but not a random AD administrator well enough to use my personal account on their device. Also, agreed we try and prevent device admins to mess with user accounts. That's best effort though - *there are* certain decisions made by the device admin that affect privacy and security (e.g. the UMA settings is still OS-wide on Chrome OS, and the ability to inhibit auto-updating does have security implications).

I don't feel strongly about the wording of the string, but let's please make sure the string we show can't be used to actively mislead users (e.g. for the AD case don't pretend we know the domain in the sense of DNS domain). Reducing the message to "this device is managed" and placing the gory details in chrome://policy is fine with me, at least for the tray bubble (but chrome://policy doesn't work for the login screen).

OK sounds good. Let's go with "This device is enterprise managed".

In chrome://policy we can put "This device is joined to the XXX domain". Though this is really a P2 since the most crucial piece is the one in the tray.

What is the conclusion? When to use what?

"This device is enterprise managed" when in AD mode.
"This device is managed by company.com" when in cloud-managed mode.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/73e62576ba72a91bbd365870f1d720310b5e5647

commit 73e62576ba72a91bbd365870f1d720310b5e5647
Author: rsorokin <rsorokin@chromium.org>
Date: Fri Dec 23 09:43:18 2016

Chromad: Use different enterprise messaging in tray bubble.

Message is "This device is enterprise managed"

BUG= 665445 
TEST=manual
TBR=grt@chromium.org

Review-Url: https://codereview.chromium.org/2587453002
Cr-Commit-Position: refs/heads/master@{#440608}

[modify] https://crrev.com/73e62576ba72a91bbd365870f1d720310b5e5647/chrome/app/chromeos_strings.grdp
[modify] https://crrev.com/73e62576ba72a91bbd365870f1d720310b5e5647/chrome/browser/ui/ash/system_tray_delegate_chromeos.cc
[modify] https://crrev.com/73e62576ba72a91bbd365870f1d720310b5e5647/chrome/browser/ui/ash/system_tray_delegate_chromeos.h

FYI: There is some code in chrome/browser/ui/webui/ntp/ntp_resource_cache.cc that shows a string for enterprise devices in the new tab page for guest sessions. It doesn't do the Active Directory check, so I don't think it shows the string for AD devices. Is that intended?

Thanks for the heads-up!
We have a bug for that ( crbug.com/693508 ). Should we change its priority?

bulk Verify of Chromad V1 bugs