Max to evaluate FR, Cyrus FYI

Hi Krishna, what's going on with this one? 

FYI.

Thanks for cc'ing me. I'll chime in.

We already offer such a feature on Android - when deleting browsing data, the user can choose up to 10 "Important sites" that will be protected from deletion. The same backend can be reused, it's just a question of piping it to policies.

More specifically, BrowsingDataRemover can be used with BLACKLIST OriginFilterBuilder/RegistrableDomainFilterBuilder to delete data from all sites except a given set of origins/eTLD+1. Note that this currently only works for cookies, site data, and cache.

Hi there,

Thanks for the update. I'm not sure that I'm understanding how I can actually enforce that policy set and then define what sites have the removal blocked or not.

Can you elaborate more?

andy.rogers@, I was just commenting on the technical complexity of adding the policy you suggest. We don't have it (yet).

As I mentioned, it's already possible to protect some cookies from deletion on Android, but there it's a user choice - not the admin's.

Oh ok, I misunderstood that.
It's definitely a feature that would be useful, even if it was for up to a maximum of ten URLS.
For any site that uses any kind of SSO, many organisations would be wanting to prevent getting out of that environment. I used YouTube as an example here, but it would help with lots of sites.

I wanted to follow up and see if any plans, or progress, has been made on this feature? We would also love to keep users from using personal Google accounts instead of the given domain account we assign them and force them to use to initially log into the chromebook.

bulk-edit of Unconfirmed feature requests

I'd really like to see this feature added in the Google Admin console.

I would like to second this feature request. I am seeing students who are supposed to be locked into their Google Education accounts deleting session cookies to use private accounts with Gmail, Hangouts, and Youtube. Deleting session cookies has mainly been an issue with investigating students using Google Hangouts to bully others.

Word is starting to get around ...
https://www.youtube.com/watch?v=3o24mlUPjsc
https://www.youtube.com/watch?v=FakKsQglSrM&t=188s

owner->assigned

+atwilson@

A few things:

1) We're rolling out a change that will prevent signing in to secondary Google Accounts, so blocking cookie deletion will not be needed to address this use case.
2) In general, relying on Google Accounts settings to configure things like YouTube restrictions is dangerous, because users can often change their password or other account settings to revoke their account credentials, allowing them to revert to a non-signed-in state. So, for example, if you want to configure YouTube, you will likely want to set the "Restricted mode for YouTube" policy in CPanel rather than relying on the user to remain signed in.
3) There are lots of ways to clear cookies, including using a javascript bookmarklet like (https://ostermiller.org/bookmarklets/cookies.html), and sometimes the Google Accounts backend itself will decide to invalidate its own cookies. So any management solution relying on cookies is likely to be relatively fragile, and we should attempt to address these use cases through other means.

Max: no objections to adding some kind of admin controls for "clear browsing data", but it probably won't actually solve the problems that admins are hoping it will solve. We should isolate their use cases and solve them directly (for example, by blocking secondary account signin).

#14 - in order for schools to use the whitelist within YouTube, YouTube accounts need to be enabled.  In the recent past (haven't checked in the last month) if a user creates a Branded account, they are bypassed on Network based restrictions, and able to view all content.

Though I agree that relying on cookies to keep users on task is less than ideal - until the AllowedDomainsForApps policy is available for Chromebooks, it's the best solution schools have.

Many schools have been waiting for the AllowedDOmainsForApps policy since v51 when it was introduced.  Where it's a mostly functional feature, you can understand the frustration which schools are experiencing having to wait for such a delay to get it right when so many other things have shown up to break the other workarounds that are in place to stop users (read students) from straying.

@atwilson

Thanks for the continued followup, even after a fair while with no action.

I've got a couple of questions and points regarding our specific situation. Primarily I'm interested in making YouTube restrictions more reliable and less trivial to bypass.

"1) We're rolling out a change that will prevent signing in to secondary Google Accounts, so blocking cookie deletion will not be needed to address this use case."
 - Is this referring to new Admin Console for the YouTube App specifically? If YouTube requires a user to be logged in on a Chrome Device AND we can whitelist login domains, that would be great!

Otherwise, yes. I agree with the rest of your points. The CPanel options really wouldn't help our use case as we want Strict Restrictions regardless of location and network on our Chromebook devices. So that's fine for on campus with the networks that we control, not so much when a student goes to a friend's house or uses free wifi somewhere.

Re #16 - great question, what my team is building is the ability to block the UI to sign out of the primary google account as well as the UI to sign in to an additional account. Max/Kushagra, we should test this with YouTube to make sure this also blocks YouTube signin/signout.

Re: the cpanel options, are you saying the cpanel-enforced restrictions aren't restrictive enough? Because when applied via policy, they should set a header on all youtube requests from the device which should tell the youtube service to enforce the relevant restrictions no matter what network the device is connected to.

@atwilson@chromium.org

Blocking the Login/Logout UI for Google Services will definitely help. 
As long as students cannot switch to a personal account for Google Hangouts/Youtube, I am indifferent to how this is achieved.  

Re #17 - Ah ok, yes that would definitely be useful. Particularly for GMail. I know that students clear their browsing data, then reload GMail and log in to get access to Hangouts, GMail, etc. For YouTube though it's not quite enough. Because the service is available without log in, we need some method to restrict the logged out content or force the service to only be used while logged in to a domain user.

Unless I'm misunderstanding, the CPanel restrictions will only take effect on the college campus networks. The Chromebooks are used extensively by the students offsite, so the ability to enforce strict restrictions on our devices needs to be extended beyond the campus.

Re: #19
CPanel policies are applied regardless of the network.  If the user logs in as the primary account first, the policy will be applied.  To prevent them logging in as a secondary account first, you can enable blocking of Multiple sign-in access or Restrict Login to the device as a device setting.

Count me in as someone who would like to see this changed. I'm interested in what the possible solution is.

Still awaiting a solution.

Is there an update on when the feature that will prevent signing in to secondary Google Accounts? It is becoming a big enough problem that we may have to completely block Google Hangouts in my environment.

Please follow along at  crbug.com/547933  for that.  If no one objects, I will just close this as a duplicate of that, since it seems like most people commenting here are most concerned about account controls rather than cookies generally.

maxkirsch, I agree this issue can be closed, as  crbug.com/547933  fulfills this need.

I disagree.  
Clearing the cookies will result in the user being not logged in.  This would allow users to access pages (like YouTube) as a guest user instead of the signed in user.

Stephen, you're right... I didn't read this carefully enough.  My mistake.   crbug.com/547933  does not fulfill the need for Issue 658620.  Please disregard my previous comment. 

We are planning to address the clear-cookies-to-sign-out use case specifically.  Aside from sign in/out, are there other reasons to block cookie clearing generally?

@Max - With the new policy to prevent secondary accounts (https://www.chromium.org/administrators/policy-list-3#SecondaryGoogleAccountSigninAllowed) there is a note about cookies:

"Note that users will be able to access Google services in an unauthenticated state by blocking their cookies."

I'm pretty sure that we're wanting to disallow this for Schools (especially students).  The main Google Service that has been a consistent concern is YouTube since it behaves unlike any other service, allowing the user to act as a consumer when not signed in rather than showing a Service Blocked page.

Keep in mind that there are multiple ways to clear cookies - for example: https://github.com/timothybrady/Clear-cookies-bookmarklet.

For google/youtube accounts, the plan is to regenerate cookies if they ever get cleared. I think this will address the usecases above re: google accounts better than trying to block all of the ways that users can clear cookies.

RE: comment 28 and 30 - 

YouTube is our concern as well - I came to this thread because we enforce Restricted Mode for our Students on YouTube, and we noticed that although we blocked the chrome://settings pane for cookies, a student can still access it by clicking on the "secure connection" lock icon in the address bar of Chrome, then clicking on "Cookies", where they can just select youtube.com and then select block.  Once the page is reloaded, they're signed out and there's no restricted mode. They can't sign back into their account either, unless they clear the block on the Youtube cookies, but that won't matter to students using this to get around our restrictions. 

If students are able to actually block the cookies from being accepted, I'm not sure the solution that you're proposing will work, at least for the case we're dealing with.  The block would just stay in place until someone releases it. This block still occurs for the user even if their profile is removed from the device.