Issue metadata
Sign in to add a comment
|
URLs defined in URLBlacklist policy are not blocked from being fetched (not navigated)
Reported by
dan.hob...@gmail.com,
Dec 17 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Steps to reproduce the problem: n/a What is the expected behavior? What went wrong? I'd like a policy that allows admins to prevent their users from running Chrome with certain (or any) command line switches. For instance, disabling access to the --disable-web-security switch Until such a policy exists, I suppose I'll have to compile my own version of Chrome with prefs.web_security_enabled hard-coded to true. Did this work before? N/A Chrome version: 55.0.2883.87 Channel: stable OS Version: 10.0 Flash Version:
,
Dec 18 2016
I would add that the normal behaviour of Chrome - allow AJAX requests even to blocked URLs is actually okay - typically if you allow a site in the URLWhitelist, you want that site to function correctly for users, so any underlying resources fetched by AJAX (with the correct CORS headers) are a-okay in my book. The problem is --disable-web-security (or any other means by which CORS is disabled). With that, plus the above behaviour, the whole web is open to a user with a bit of Javascript knowledge.
,
Dec 19 2016
,
Dec 19 2016
Looks like the issue can't be triage from TE end.Adding respective label for further triage help.
,
Dec 21 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by phistuck@chromium.org
, Dec 18 2016Summary: URLs defined in URLBlacklist policy are not blocked from being fetched (not navigated) (was: No policy for command-line switches?)