+Istiaque, Devlin for their thoughts on the issues listed. Feel free to add other folks who might have an opinion.

+meacer@, whose thought about the related issue 157736.

A few thoughts related to the issues above.
1) I could be persuaded either way - meacer@ will likely have a firmer opinion here.
2) I don't think we need to - we're not modifying any data related to that URL.
3) It's a bit of a shame that we'd need to have this as a caveat, but I don't think there's a good way around it - unless with PlzNavigate these requests go through the browser?  +Nasko.

I'm just hearing about DNR now but it sounds similar to webRequest. If the API allows modifying subresources, I'd definitely consider a permission for the same reasons as issue 157736. Since DNR is going to have its own set of permissions, it sounds better to be more restrictive in the beginning.

I agree that (2) doesn't need a permission.

@4, right, we definitely want to be more restrictive than webRequest.  At minimum, we'll want permission to the resource *and* the requesting frame (for subresources).  Any thoughts on whether requiring a permission to the top-level frame for subframes requesting resources?

Maybe it's because it's late in the day, but I can't visualize that scenario :)
Is the idea that with the following structure, DNR should require a host permission for b.com as well as a.com and c.com?

a.com (top frame)
  b.com (iframe)
    c.com (subresource)

given that scenario

a.com (top frame)
  b.com (iframe)
    c.com (subresource)

we're pretty sure that the extension should require b.com (the requesting frame) and c.com (the requested resource).  The question is more about a.com.  Technically, it's not gaining access to data on a.com, but most users wouldn't differentiate.

I see now.

There are cases where this could give indirect access to a.com: E.g. if a.com has a postMessage channel with b.com. If the extension can control b.com, then it can also affect a.com. We consider this scenario out of scope with other host permissions though, so I'm not sure if it's worth considering here.

But as an counter argument, is there a use case for an extension to modify b.com and c.com without having all_urls access? In general there seem to be two main categories of extensions that use webRequest and potentially DNR: Adblockers and everything else. Adblockers will almost always require all_urls, and everything else could simply list which URLs they want to touch?

On comment 3, question 3 - With PlzNavigate, the network request for navigations does get made from the browser process. It should only be hitting the network cache, but whether this allows it to be surfaced to DNR is not something I know for sure.

Also, adding clamy@ for PlzNavigate as the authority on the topic.

> But as an counter argument, is there a use case for an extension to modify b.com and c.com without having all_urls access? In general there seem to be two main categories of extensions that use webRequest and potentially DNR: Adblockers and everything else. Adblockers will almost always require all_urls, and everything else could simply list which URLs they want to touch?

Sure, extensions can list the urls they want to touch.  But consider if an extension wants to modify facebook.com - they may then want to modify facebook.com iframes on arbitrary sites.  The extension can just list facebook.com in the manifest permissions, but the question would remain if they would need permission to access the parent frame (in which case, practically, the extension would need to just specify <all_urls>).

+Raymes who thought more about iframes and permissions in the web context.

Extensions modifying fb iframes sound like either adblockers or privacy related extensions though, which would probably require all urls anyways?

I don't have a good answer. As you said, modifying iframes doesn't seem to require top frame permission, but on the other hand it's hard to explain to users why their page looks different.

On the web we're moving to a model where users only make decisions about top-level frames, because iframes have no associated security UX and so the user is not in a good position to understand their existence or make security decisions about them.

I think you can apply the same argument to extensions. As meacer pointed out it may be confusing to a user that their top-level origin doesn't read "facebook" and yet the extension is running on the page and manipulating content.  It's a bit less compelling in that case because users may have more of an expectation that extensions are running in the background and impacting their various page loads. 

I don't feel particularly strong either way but I'm also not sure I fully understand all the factors at play here but happy to chat more if needed.

@nasko: also note that event before PlzNavigate navigation requests would not be cached in the Blink memory cache, so they would always hit the network stack. As Nasko mentions, navigation requests can be served from the network cache, but that should be transparent to most observers. For example, the ResourceDispatcherHostDelegate would still see a network request, even if it was served from cache. So unless the observer for DNR is plugged very deep inside the network stack, it shouldn't be an issue for main resources.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/10c92aea9719dadd903c0540968844bd36f103f4

commit 10c92aea9719dadd903c0540968844bd36f103f4
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Thu Feb 01 22:37:09 2018

DNR: Introduce manifest key to specify host permissions.

This CL introduces the "hosts" key within the "declarative_net_request" manifest
key. It is used to specify a list of match patterns. These match patterns will
then be used by DNR to evaluate whether an extension has access to a particular
request for the purpose of DNR.

The parsing of host permissions within PermissionsParser is refactored and a new
static utility method called ParseHostPermissions is introduced on the class to
parse a list of match patterns.

In subsequent CLs, the concept of hosts for DNR will be introduced in the
PermissionsSet class and DNR will start checking these host permissions.

BUG= 777714 , 696822
Doc=go/dnr-hosts

Change-Id: Iee31b634ce5e45c5685ad4264219cb79b70070aa
Reviewed-on: https://chromium-review.googlesource.com/888321
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533838}
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/api/declarative_net_request/dnr_manifest_handler.cc
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/api/declarative_net_request/dnr_manifest_unittest.cc
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/api/declarative_net_request/test_utils.cc
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/api/declarative_net_request/test_utils.h
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/manifest_constants.cc
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/manifest_constants.h
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/manifest_handlers/permissions_parser.cc
[modify] https://crrev.com/10c92aea9719dadd903c0540968844bd36f103f4/extensions/common/manifest_handlers/permissions_parser.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf

commit d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Mon Feb 05 23:09:28 2018

Revert "DNR: Introduce manifest key to specify host permissions."

This reverts commit 10c92aea9719dadd903c0540968844bd36f103f4.

Reason for revert: Changing the approach as per discussion, don't need DNR specific
host permissions any longer.

Original change's description:
> DNR: Introduce manifest key to specify host permissions.
>
> This CL introduces the "hosts" key within the "declarative_net_request" manifest
> key. It is used to specify a list of match patterns. These match patterns will
> then be used by DNR to evaluate whether an extension has access to a particular
> request for the purpose of DNR.
>
> The parsing of host permissions within PermissionsParser is refactored and a new
> static utility method called ParseHostPermissions is introduced on the class to
> parse a list of match patterns.
>
> In subsequent CLs, the concept of hosts for DNR will be introduced in the
> PermissionsSet class and DNR will start checking these host permissions.
>
> BUG= 777714 , 696822
> Doc=go/dnr-hosts
>
> Change-Id: Iee31b634ce5e45c5685ad4264219cb79b70070aa
> Reviewed-on: https://chromium-review.googlesource.com/888321
> Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
> Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#533838}

TBR=rdevlin.cronin@chromium.org,karandeepb@chromium.org

Change-Id: I63cb84b126de6ba02d604efb4503959e3de6cef7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  777714 , 696822
Reviewed-on: https://chromium-review.googlesource.com/900162
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534525}
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/api/declarative_net_request/dnr_manifest_handler.cc
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/api/declarative_net_request/dnr_manifest_unittest.cc
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/api/declarative_net_request/test_utils.cc
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/api/declarative_net_request/test_utils.h
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/manifest_constants.cc
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/manifest_constants.h
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/manifest_handlers/permissions_parser.cc
[modify] https://crrev.com/d2ec3bc618df7e5e7fd7a14eea68d2df62f4d7bf/extensions/common/manifest_handlers/permissions_parser.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea2dc902c30310942f19faef732056a843767ef1

commit ea2dc902c30310942f19faef732056a843767ef1
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Wed Feb 07 05:50:23 2018

Extensions: Add ability to check host permissions for initiator as well.

This CL adds the ability to check for host permission access to both the request
url and its initiator. WebRequestPermissions::REQUIRE_HOST_PERMISSION is renamed
to WebRequestPermissions::REQUIRE_HOST_PERMISSION_FOR_URL and
WebRequestPermissions::REQUIRE_HOST_PERMISSION_FOR_URL_AND_INITIATOR is
introduced. This will subsequently be used to check access for the Declarative
Net Request API.

BUG= 777714 , 696822

Change-Id: I8ec9b08be1e8eb240e28328b7c254055e63005f3
Reviewed-on: https://chromium-review.googlesource.com/905405
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534924}
[modify] https://crrev.com/ea2dc902c30310942f19faef732056a843767ef1/chrome/browser/extensions/api/web_request/web_request_permissions_unittest.cc
[modify] https://crrev.com/ea2dc902c30310942f19faef732056a843767ef1/extensions/browser/api/declarative_webrequest/webrequest_action.cc
[modify] https://crrev.com/ea2dc902c30310942f19faef732056a843767ef1/extensions/browser/api/web_request/web_request_api.cc
[modify] https://crrev.com/ea2dc902c30310942f19faef732056a843767ef1/extensions/browser/api/web_request/web_request_permissions.cc
[modify] https://crrev.com/ea2dc902c30310942f19faef732056a843767ef1/extensions/browser/api/web_request/web_request_permissions.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4821d731a0a380428445d566f0c0b290e36fc027

commit 4821d731a0a380428445d566f0c0b290e36fc027
Author: Karan Bhatia <karandeepb@chromium.org>
Date: Tue Feb 13 20:31:32 2018

DNR: Check host permissions for request and its initiator.

This CL implements host permission checking during ruleset evaluation for the
Declarative Net Request API. Host permissions to the request url and its
initiator are checked while evaluating an extension ruleset.

BUG= 777714 , 696822

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Ic25a3895e61afdf8073618ae65cbcb9c60bb4cff
Reviewed-on: https://chromium-review.googlesource.com/905570
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536450}
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/chrome/browser/extensions/api/declarative_net_request/declarative_net_request_browsertest.cc
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/chrome/browser/extensions/api/declarative_net_request/rule_indexing_unittest.cc
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/chrome/browser/extensions/api/declarative_net_request/ruleset_manager_unittest.cc
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/chrome/browser/extensions/api/declarative_net_request/ruleset_matcher_unittest.cc
[add] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/chrome/test/data/extensions/declarative_net_request/page_with_four_frames.html
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/extensions/browser/api/declarative_net_request/ruleset_manager.cc
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/extensions/browser/api/declarative_net_request/ruleset_manager.h
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/extensions/common/api/declarative_net_request/test_utils.cc
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/extensions/common/api/declarative_net_request/test_utils.h
[modify] https://crrev.com/4821d731a0a380428445d566f0c0b290e36fc027/testing/buildbot/filters/mojo.fyi.network_browser_tests.filter