Education institutions use content filtering products to prevent their users from accessing inappropriate content on their Chromebooks. There are a handful of ways that their users are able to escape this content sandbox and access content that they should otherwise not be able to access. These Android and Chrome App recommendations should help developers ensure their apps work well with content filtering.
If your app uses WebViews to allow students to login to your service or to display documentation, it may enable students to browse the web without the content filtering protections provided by their schools. Some of the most popular content filtering products used by schools on Chromebooks are deployed as Chrome extensions, which can only see traffic within browser tabs. Since web content is often unpredictable, students can often traverse links within the WebView to browse the web freely, without content filtering protections.
By reducing the amount of browser based content shown in your application, you can reduce the likelihood of unwanted content being accessible within your application. If this is impossible, then ensure your WebView only serves content you want and does not link out to a search engine or the open web.
If your app requires a WebView, make sure that the content within your WebView is not able to escape your application and navigate to content that you do not own or control. This can be done by modifying the WebView client to override loading certain URLs via an allowlist on Android or by manually parsing through your site and validating that the links do not link out to third party content that you cannot control, as this may enable your users to go to inappropriate content. For Chrome Apps, you can use the WebRequestEventInterface to also modify requests and validate that they are allowed to navigate to your allowed list of sites.
You can reduce the risk of users getting past content filtering if you open web content in the devices’ built-in web browsers.
In Android apps, consider using Chrome Custom Tabs instead of WebViews. On Android, the custom tab will open a browser tab that is themed like your application. For ChromeOS, this will launch the normal browser and allow users to navigate within the page as normal, but because it’s their normal browser, it will allow the enforcement of browser policies on the content that the students are accessing. For most educational organizations, this means that the content that would be displayed would be visible to content filtering extensions running on the browser. This is especially useful for third party identity providers that rely on implementing OAuth in a WebView.
In Chrome Apps, links to content not owned by you should be opened in a new tab rather than within the WebView that is running. To open a new tab from your Chrome App, you can modify your anchor tags to set the target attribute to point to
_blank which will allow the link to open in a new tab.
If your application only uses Google Sign in, do not use a WebView to sign in. Instead, on Android, handle it with the One Tap sign-in and sign-up flow. If you are using Chrome Apps, continue to use the
chrome.identity API. Links in this sign-in flow start from the browser instead of an embedded WebView, which may not have the same filtering controls applied to it.