It's possible you haven't set the policy correctly - can you please post a screenshot of your about://policy page to this bug?

I've triple-checked the policy config, based on https://www.chromium.org/administrators/linux-quick-start

When connected to remote DevTools inspector, about://policy and chrome://policy just display a blank page, where-as any other webpage loads in the DevTools screencast.

We verified that the policy file is correct and that the images in the headless chrome are indeed showing up.

+skyostil as owner of  crbug.com/546953 

In Chromium, the machine-local policies are loaded in ConfigDirPolicyLoader, owned by ChromeBrowserPolicyConnector which in turn is owned/used by BrowserProcessImpl.

As far as I understand, headless chrome is supposed to be a thin wrapper around the content layer of chrome, and does not use BrowserProcessImpl at all.
Is support for enterprise policies something that would make sense for the headless chrome project?

#6: That's correct, headless is basically a separate content embedder. We've thought about this a bit and we're probably leaning against supporting policies in headless. One reason is that while we could probably support some of them (like DefaultImagesSetting), there's no way we can implement all policies supported by Chrome. That means some settings will be silently ignored, which means it would be dangerously misleading for us to claim that we support policies.

I'm also not really sure what use cases folks have for using policies in headless mode. The DevTools remote debugging protocol is meant to be the main way of interacting with the headless browser, and policies seem somewhat overlapping with that. I'm probably missing something here, so it would be great if people could explain why they would like policy support in a comment below.

+Drew: FYI, chrome --headless and policies.

@anilkanth: See Comment #8 - could you please explain your usecase in a bit more detail? Thank you!

@skyostil: Thanks for the clarification! It also sounds like if you're an application/script embedding chrome headless you might not want "headless chrome" to depend on whatever policies are pulled from config files.
Is there a way to disable image loading through the remote debugging protocol, e.g. before navigating headless chrome to the first page? Without thorough analysis, that would sound like the cleanest solution, as it would enable this usecase, be extensible without cluttering command-line arguments or having a half-baked "real" policy support.

#9: That's a good point -- random applications shouldn't depend on policy settings. There's no explicit way to disable images through DevTools right now, but we're working on a way to override network request which would also let you do that.

In my use case I was looking to prevent Chrome accessing file:// urls and IP addresses on private networks as some sort of firewall.
In the meantime I made a solution with iptables

#11: Thanks. I think I would argue that and OS level solution (e.g., a firewall and/or a sandbox) would be a more robust way of limiting access because the browser process (unlike a renderer) is generally considered privileged and isn't limited from accessing files. Therefore blocking file:// won't block all the ways the browser can load a file (dumb example: tricks with LD_PRELOAD).

If I understand correctly, the browser process needs some access to the filesystem/network. Like user data dir, dns resolution, remote debugging. What I want to control however is anything that goes through the network layer of rendering a page. I want to limit access to any files, including the user data dir, I want to limit access to private networks and localhost, including http://localhost:9222/json. but still allow devtools remote debugging. Ideally I'd black/whitelist some protocols and IPs just like can be done in policies

#9: My usecase is to perform DOM analysis at scale, so the pages must load as quickly as possible. Loading images is time-consuming and unnecessary for my usecase (as well as many others), but apart from policies I couldn't find any other reliable way to restrict loading of all images. Ideally, this should've been possible through a Chrome Debugging Protocol filter or setting.

Removing Enterprise label as this isn't really an Enterprise use case. 

#14: I see, thanks. We're investigating letting you customize network fetches over DevTools which should be a good fit for filtering images too.

#13: I guess I'm still a little unclear about who the adversary is in your scenario. Headless Chrome includes the normal origin based access control protections as regular Chrome, so random web pages won't be able to access those resources in any case. Still, the protection from an additional sandbox layer wouldn't hurt.

@skyostil: Should we repurpose this bug to what you mentioned in #16? Or do you already have a bug for that? 

#17 image for instance a screenshotting service. a rest API controls chrome devtools. users can post a url and get a screenshot back. You want to prevent users from taking screenshots of local files by posting file:///etc/passwd. or access resources on private networks. or even just prevent them from sreenshotting localhost:9222/json

#18: We'll file another bug for that once we send out the design doc.

#19: Got it. I think I would still recommend the DevTools based approach for that one since it is more flexible and explicit about what is going on.

#16 - I think the Developer Tools feature gained a request blocking feature recently (it might be an experiment at the moment), so that might help in blocking stuff, including perhaps file:// URLs as well.

Closing this bug as WontFix for now since policies for headless are not planned, see #8 and better ways for solving the actual usecases are being discussed. When a bugs exists for customizing network fetches over DevTools, we will link it here.