Fix for UnsafelyTreatInsecureOriginAsSecure policy in browser UI
This CL updates secure_origin_whitelist::GetWhitelist() to delegate parsing the set of whitelisted sites to a new function, ParseWhitelist, which takes in a string and returns the parsed vector of strings. This allows callers in the browser process to explicitly parse a whitelist from either prefs or command-line switches. This allows SecurityStateTabHelper to have its own custom IsOriginSecureWithWhitelist function to which it can bind an explicitly passed whitelist of origins, rather than just using content::IsOriginSecure as the callback to security_state functions. content::IsOriginSecure uses GetWhitelist() which only loads the whitelist from command-line flags, which are only correctly set for renderer processes. The custom callback for SecurityStateTabHelper allows it to also check prefs for the whitelist, which is how the enterprise policy is accessible in the browser process (where security indicator UI logic occurs). This can cause the pref and the switch to be two different sources of truth for the origin whitelist, however this simpler fix will be easier to backport. This fix favors the switch over the pref if both are set, allowing developers to still set temporary overrides while maintaining the policy behavior for general users. More general fixes may involve changing how the whitelist propagates between parts of Chrome (including in content and blink). Bug: 869422 Change-Id: I93b46d66844af8cee00d919537ce66fc2c56cd46 Reviewed-on: https://chromium-review.googlesource.com/1157029Reviewed-by:Avi Drissman <avi@chromium.org> Reviewed-by:
Mustafa Emre Acer <meacer@chromium.org> Commit-Queue: Christopher Thompson <cthomp@chromium.org> Cr-Commit-Position: refs/heads/master@{#579835}
Showing
Please register or sign in to comment