|
||||||||||||
Issue descriptionM52 has a policy "PacHttpsUrlStrippingEnabled" which defaults to False for Chrome OS enterprise users, and True elsewhere: https://cs.chromium.org/chromium/src/components/policy/resources/policy_templates.json?sq=package:chromium&dr=C&l=8586 We want to remove the policy in favor of the feature being always enabled (PacHttpsUrlStrippingEnabled = True), without an option to override. Jun 23 2016,To be clear, this bug is about figuring out *when* to deprecate it, and how to safely remove any consumers of it (transitioning them to the new default behavior). The policy itself was just introduced in M52 and hasn't even gone out yet at this time. (Might not be the best first bug). Aug 26 2016,
David, can you find an owner for this? Thanks! Feb 10 2017,Ping Feb 13 2017,Cyrus/David - I'm concerned about the current implementation of this policy, as it means Pac stripping is disabled for *all* managed devices. Here's what I'd propose as the first step of a deprecation strategy: 1) We update DMServer to set this policy (disable stripping) on all current EDU domains. 2) Update policy_templates.json to remove the "enterprise default" (so we will start stripping PAC urls except for the domains specified in #1) ...and we wait to see what breaks. This has the advantage of not breaking any existing EDU customers, but *new* customers will get the stripping functionality while they are doing their initial deployment so they can shake out any issues. It also makes enterprises more secure by doing stripping for non-EDU customers. Cyrus/David, WDYT? I don't have a great plan for fully deprecating this policy, since we have no way of telling who might break if we remove the policy. But at least we can lock down the set of domains that don't have Pac stripping to the current set of EDU customers. Feb 13 2017,SGTM. If anything breaks on Enterprise side and we need to pull an emergency brake, we can always manually set the policy for an affected domain. We followed a similar route with SHA1 root deprecations as that was also a niche policy which we didn't really want to surface UI for but wanted to keep an emergency brake at hand. Jul 3 2017,
Bin, WDYT about making the change in DMServer described in comment #5? Dec 19 2017,Any update on this? It has been over a year, and we are still running Chrome OS with a known security/privacy vulnerability... Apr 4 2018,Is anyone working on this? Other browsers have also followed suite and disabled paths in PAC, so the compatibility risk seems low. If there is no-one planning to do a rollout for this, can I just flip the default in code for Chrome OS so we can make progress towards deprecating this? Apr 9 2018,
Naveen, it's your call. We originally set this policy for managed cros devices for fear of breaking enterprise deployments. I'd be nervous of just flipping it on the client as it might take devices offline - would love to hear from you and Dennis around the feasibility of the path I outline in comment #5. Jun 13 2018,
Aug 31,What is the status of the rollout? We need to remove support for this. Sep 3,+1 - I suspect Naveen isn't seeing these bugs, perhaps you should start an email thread on it instead. Sep 10,
Sep 13,
Sergey, would like to remove the enterprise default for this policy (in policy_templates.json), and set the supported-on flag to m74. Sep 14, Project MemberThe following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0aec57f9714aba3ae2b0a9ba8a05268a5013d046 commit 0aec57f9714aba3ae2b0a9ba8a05268a5013d046 Author: Sergey Poromov <poromov@chromium.org> Date: Fri Sep 14 13:03:22 2018 Start deprecation of PacHttpsUrlStrippingEnabled policy This change removes enterprise_default for PacHttpsUrlStrippingEnabled, that was set to "False" and now all users should have it set to "True". Long-term security-wise the behavior should be that URLs are always stripped for Pac proxies, i.e.as the policy set to "True". We are keeping ability to change the policy in server-side configuration to "False" in case customers will be broken by the change. Otherwise, the policy is going to be deprecated in M74. Bug: 619087 Change-Id: I29db0211ced988b0fde5efaf3ce7863466bffb6e Reviewed-on: https://chromium-review.googlesource.com/1224449 Commit-Queue: Sergey Poromov <poromov@chromium.org> Reviewed-by: Eric Roman <eroman@chromium.org> Reviewed-by: Maksim Ivanov <emaxx@chromium.org> Cr-Commit-Position: refs/heads/master@{#591330} [modify] https://crrev.com/0aec57f9714aba3ae2b0a9ba8a05268a5013d046/components/policy/resources/policy_templates.json Sep 14,
Sep 15, Project Member
This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot Sep 17,
Decided to keep the change in M71+ only. Sep 19,
Changing labels so that next action is scheduled for M75 release. Today (10 hours ago),
|
||||||||||||
►
Sign in to add a comment |
Comment 1 by pbond@chromium.org, Jun 23 2016