best practice filtering chromebooks

[mrstrong]

Hi,

 

can anyone share what/how they handle chromebook filtering.

 

Google's support chat have directed me to this page

 

https://support.google.com/chrome/a/answer/6334001

 

We are using a smoothwall as web filter and firewall with HTTPS inspection (decrypt and inspect) for students.

 

Is it enough "allow" all the urls in that google support page or do I need to go further e.g. set as "do not filter"

and / or "do not inspect" (think do not filter implies do not inspect?)

 

This is what I found on smoothwall's support site (whitelist is the old name for "do not filter")

 

Allow vs Whitelist

The allow action allows the user to access the site, but any HTTPS inspection rules and content modification rules will still be applied.

With a whitelist action, the site will be allowed. It won't be inspected if it is an HTTPS site, and no content modification will be applied.

 

Whitelist / Do Not Filter: This combines the function of the Allow action but also removes HTTPS Inspection from the content and any

relevant Content Modifications. This is used where content is deemed safe to access entirely unfiltered.

NOTE: Using this action on the 'Web Search' category, or any custom category containing search engines (google.com, etc) will remove

the Search Term Filtering functionality for that site and compromises content filtering in search engines.

[DGardiner]

Hi,

 

can anyone share what/how they handle chromebook filtering.

 

Google's support chat have directed me to this page

 

https://support.google.com/chrome/a/answer/6334001

 

We are using a smoothwall as web filter and firewall with HTTPS inspection (decrypt and inspect) for students.

 

Is it enough "allow" all the urls in that google support page or do I need to go further e.g. set as "do not filter"

and / or "do not inspect" (think do not filter implies do not inspect?)

 

This is what I found on smoothwall's support site (whitelist is the old name for "do not filter")

speak to smoothwall, cloud filter is in with the onsite appliance - Just gotta deploy an extension to the chromebooks and it will do the filtering on device - mirroring your onsite appliances rules

[dhicks]

Just gotta deploy an extension to the chromebooks and it will do the filtering on device

 

I'm guessing the extension-deploy option is actually per-user - subtle difference, but it means that anywhere a child logs in to any ChromeOS device with their school account they'll have filtered access. Can be quite nice for home-use - you can explain to parents that as long as their child is logged on to a Chromebook with their school account they should have filtering the same as they would at school, even if it's a home-owned device. And, of course, it means they can switch to an unfiltered home account at home if they (or, hopefully, their parent) wants.

[DGardiner]

I'm guessing the extension-deploy option is actually per-user - subtle difference, but it means that anywhere a child logs in to any ChromeOS device with their school account they'll have filtered access. Can be quite nice for home-use - you can explain to parents that as long as their child is logged on to a Chromebook with their school account they should have filtering the same as they would at school, even if it's a home-owned device. And, of course, it means they can switch to an unfiltered home account at home if they (or, hopefully, their parent) wants.

 

it is a per user extension but i dont think it functions the same on windows - atleast is requires a client installed as well as the extension so it wont magically filter their chrome browser unfortunately - this could have changed since i last tried though

[dhicks]

atleast is requires a client installed as well as the extension so it wont magically filter their chrome browser unfortunately

 

Any idea why not? I thought the whole point of ChromeOS was that everything (including, I assumed, extensions) was "web based" - Javascript or maybe Web Assembly for added performance. I could be guessing wrongly there, of course - I've not looked in to writing any ChromeOS extensions, I just assumed you got some kind of hardware-abstracted API.

[DGardiner]

No idea I expected it to filter kind of like an ad blocker would but anything on windows requires some client kind of annoyed me but at the time chrome os was my big concern - on site appliance does my thing here for winfows

[mrstrong]

Sorry just got back to this. I'm actually trying to fix the filtering in school (not offsite with the extension).

 

I also ran

network_diag --hosts

in crosh terminal and am getting some fails e.g.

 

checking clients1.google.com... FAIL: non-Google SSL/TLS certificate

 

so do I just need to add any failing URLs to a guardian HTTPS inspection "do not inspect" policy ?

 

I suppose "do not inspect" implies "do not filter" so there is no need to and an explicit guardian web filter "do not filter" policy ?

[DGardiner]

Sorry just got back to this. I'm actually trying to fix the filtering in school (not offsite with the extension).

 

I also ran

network_diag --hosts

in crosh terminal and am getting some fails e.g.

 

checking clients1.google.com... FAIL: non-Google SSL/TLS certificate

 

so do I just need to add any failing URLs to a guardian HTTPS inspection "do not inspect" policy ?

 

I suppose "do not inspect" implies "do not filter" so there is no need to and an explicit guardian web filter "do not filter" policy ?

Theres an extensive list of stuff to no inspect.

 

https://github.com/google/gfw-deployments/blob/master/apps/utils/GoogleAppsWildcardedDomains.txt

 

Youre gonna have - to be careful though, if you stop inspecting some urls you lose contextual filtering on youtube/search so i would do as little as you need to make them work

[mrstrong]

...

Youre gonna have - to be careful though, if you stop inspecting some urls you lose contextual filtering on youtube/search so i would do as little as you need to make them work

 

yes this was my worry, being too gung-ho and breaking search filtering.

 

In general if you want a url /category as "do not inspect" (ie a policy under HTTPS inspection policies"

do you also add a corresponding policy under Guardian Web filter policies (e.g. allow or "do not filter") ?

 

Just using smoothwall's category search for a lot of the FAIL urls many are in the "Googeldrive and Sync" category

Could I get away with having that complete category as "do not inspect" ?

 

(just FYI this post came about from an ongoing issue with gmail: http://www.edugeek.net/forums/cloud-services/224810-gmail-not-loading-emails.html)

[DGardiner]

aa.google.comaccounts.google.co.ukaccounts.google.comaccounts.youtube.comalt4-mtalk.google.comandroid.clients.google.comcalendar.google.comcalendarsuggest.clients6.google.comchrome.google.comclients.l.google.comclients6.google.comconnectivitycheck.android.comconnectivitycheck.gstatic.comdocs.google.comdrive.google.comggpht.comgoogleapis.comgoogledrive.comgoogleusercontent.comgroups.google.comgstatic.comgstatic.com/generate_204gvt1.comgvt2.comgvt3.cominbox.google.comlh3.google.complay.google.comssl.gstatic.comtalk.google.com

accounts.blogger.comalt1-mtalk.google.comalt2-mtalk.google.comalt3-mtalk.google.comapps.chromechat.google.comclients6.google.comdl.google.comfirebaseio.comhangouts.google.comid.google.commail.google.comogs.google.complay.google.comprinterconfigurations.googleusercontent.comtasks.google.comtools.google.com

is my list of google allowed stuff, not inspected - not gonna claim its perfect though and use at your own risk

 

Just to be double safe id make sure you have search in a force inspection rule above everything you whitelist, can help avoid accidents

 

Sory forum ate the formatting

Edited November 30, 2021 by DGardiner

[ibpalle]

....

so do I just need to add any failing URLs to a guardian HTTPS inspection "do not inspect" policy ?

 

I suppose "do not inspect" implies "do not filter" so there is no need to and an explicit guardian web filter "do not filter" policy ?

 

 

Do not inspect bypasses HTTPS inspection, which in turn prevents content mod and anti malware policies from applying as well.

 

The same is valid for Do not filter - HTTPS inspection, Content Mod and Anti malware policies are all bypassed, se essentially they are the same thing.

 

You can use either - you don't have to use both.

[mrstrong]

Do not inspect bypasses HTTPS inspection, which in turn prevents content mod and anti malware policies from applying as well.

 

The same is valid for Do not filter - HTTPS inspection, Content Mod and Anti malware policies are all bypassed, se essentially they are the same thing.

 

You can use either - you don't have to use both.

 

so am I right in thinking if you have something in a "do not inspect" there is no filtering at all, i.e. no policies under Guardian -> Web filter

would apply ?

 

I suppose I'm trying to understand how the policies eg, HTTPS inspection and Web filter apply / interact.

[ibpalle]

No, with do not inspect, only https inspection would not apply. If porn is blocked and someone goes to Playboy, it will still get blocked.

[mrstrong]

ah ok, so with a web filter block for playboy it would block it (based on the url I guess),

even if you had it as do not inspect. But with "do not inspect" you are pretty limited as you can't

see the page source ?

 

Just looking under Guardian > categories > standard categories, I can see google drive and can edit it

but no entries are visible, e,g, nothing in Domain/URL filtering, Search term filtering, URL patterns,

File types, Video ID filtering

Is that right / because its "built in" ? Is there anyway to see what smoothwall have included here

e.g. for Domain/URL filtering ?

[ibpalle]

Yes, without https inspection only the domain part of the URL would be visible to the Guardian filter.

 

You can add to the standard categories using the features in the categories section - you can't see what's in our blocklist. It's considered IP so contents is not publicly available.