Hmm, about: URLs should expand to chrome: URLs, and for those you should get the "You are viewing a secure Chrome page." OIB. Do you have an example?

For data:, might people want to control the permissions of JavaScript running in the page?

There is a single about: URL: about:blank.
If you try to set any permissions for about:blank, they are not persisted. But you can still go through the motions from the page info bubble.

usando uma botnet estena ou interna.

> For data:, might people want to control the permissions of JavaScript running in the page?

That makes sense. But we should make sure this actually works and the saved URL is displayed in a sensible way in chrome://settings and other places.

See discussion in https://codereview.chromium.org/1814993002/:

From within the JS console in that page, do:

w = window.open("about:blank")
w.document.write(w.document.cookie)
w.document.write(w.location)
w.document.write(w.location.origin)

...yet the about:blank openee shows "about:blank" in the OIB, and says "0 cookies from this site, 11 from other sites" but really the cookies are from codereview.chromium.org and www.chromium.org (i.e. not 'other sites'; really, the site is only 'other' because the OIB thinks it is in about:blank).

So, I think we need to have about:blank OIBs use their opener's origin in the strings, and calculate things like the cookie counts and active permissions/settings based on that. Is that a new bug, or should we use this bug for it?

That's partially  bug 469889 , in that we are trying to add the origin of the about:blank opener to the OIB (crrev.com/1460983002)

That bug doesn't list permissions, cookies etc. though, feel free to add them as a comment or a separate bug.

Comment 7: Yes, it would help to show things from the about:blank page's origin in that dialog.  Note that it's not necessarily the opener (which may have been closed).  We do have that info in RenderFrameHost::GetLastCommittedOrigin.  (See also  issue 590035 .)

Here are screenshots of what patchset 2 from https://codereview.chromium.org/1814993002/ gets you. about:blank and no opener, you get the status quo. With an opener, you get the 2nd screenshot.

But, per #9, it sounds like I should use RenderFrameHost::GetLastCommittedOrigin instead of web_contents_->GetOpener()->GetLastCommittedURL(), right? I'll try to spin up a patchset 3 that does that today.

Deleted: about-blank-no-opener.png 64.6 KB

	about-blank-no-opener.png 64.6 KB View Download

Deleted: abou-blank-google-opener.png 65.9 KB

	abou-blank-google-opener.png 65.9 KB View Download

Awesome!  And yes, please use RenderFrameHost::GetLastCommittedOrigin. 

Why does the second screenshot say that the connection is not private? Does it not use the origin or does it need the cert information to make this decision?

There also seems to be no way to differentiate https vs http as the dialog only shows the hostname. Should it display the origin instead, given that permissions are stored per-origin? (Not specifically for about:, but in general)

#11: Is there a material difference between RenderFrameHost::GetLastCommitted{Origin,URL}? The latter (URL) would be better given the expectations of the surrounding code.

However...

#12: Because:

360 void WebsiteSettings::Init(
361     const GURL& url,
362     const SecurityStateModel::SecurityInfo& security_info) {

Although I am finding a new |url| through |web_contents_|, the |security_info| is the same. I am starting to think we should change the caller(s) of WebsiteSettings::WebsiteSettings (which is what directly calls WebsiteSettings::Init with these parameters), rather than trying to get the right info here in Init. (And, for WebsiteSettings::Init to take |url| is redundant; in its caller, WebsiteSettings::WebsiteSettings, |url| == |site_url_|.)

Refactoring ahead...

#14: GetLastCommittedURL returns about:blank (vs GetLastCommittedOrigin, which should return Google in your example).

Hmm, question for those more knowledgeable. The call tree is rather deep, but chains up to (among others) this, from chrome/browser/ui/views/location_bar/location_icon_view.cc:

 30 void ProcessEventInternal(LocationBarView* view) {
 31   WebContents* contents = view->GetWebContents();
 32   if (!contents)
 33     return;
 34 
 35   // Important to use GetVisibleEntry to match what's showing in the omnibox.
 36   NavigationEntry* entry = contents->GetController().GetVisibleEntry();
 37   // The visible entry can be nullptr in the case of window.open("").
 38   if (!entry)
 39     return;
 40 
 41   ChromeSecurityStateModelClient* model_client =
 42       ChromeSecurityStateModelClient::FromWebContents(contents);
 43   DCHECK(model_client);
 44 
 45   view->delegate()->ShowWebsiteSettings(contents, entry->GetURL(),
 46                                         model_client->GetSecurityInfo());
 47 }

So I can obviously easily pass contents->GetMainFrame()->GetLastCommittedURL() or (...Origin(), if necessary). But, where can I grab the right SecurityInfo from? Access to it from here seems to be keyed from |contents|, but that may not be/is not right right WebContents. Is there a way to get the WebContents associated with contents->GetMainFrame()->GetLastCommittedURL() (so that the I could get the right ChromeSecurityStateModelClient)? Or is there some other way to get the right SecurityInfo?

#15: Ah, yes, I see.

FWIW, here are screenshots of Patchset 3 from https://codereview.chromium.org/1814993002/. I took the approach of getting the right URL and SecurityInfo in the caller, rather than trying to grovel around for the opener URL, because I can't yet figure out how to get the opener's SecurityInfo.

Note the nice thing: when you click Details in the OIB, it shows you the Security Panel in Dev Tools in the opening tab.

Note the problem: But if the opening tab is closed, clicking on Details shows you the Security Panel in the opened tab, which can only show you the details of about:blank. So then the person sees an inconsistency between what the OIB says about connection state (secure, google.com) and what the Dev Tools say (not secure).

Deleted: 1.png 65.9 KB

	1.png 65.9 KB View Download

Deleted: 2.png 74.2 KB

	2.png 74.2 KB View Download

Deleted: 3.png 31.4 KB

	3.png 31.4 KB View Download

First, let's clarify-- the opener is a red herring.  It's one way for an about:blank frame to inherit an origin, but about:blank can inherit an opener in other ways (e.g., frame's parent, or from an earlier opener before the opener changed via a window.open call).  We also can't assume that the opener still exists (as you noted), even though the about:blank frame still has its origin.

It seems like you would want |contents| (i.e., the about:blank's tab) to base its SecurityInfo on contents->GetMainFrame()->GetLastCommittedOrigin().  That's really the only reliable way to know the effective origin of about:blank.  How does SecurityInfo usually get initialized?

The SecurityInfo is derived from ChromeSecurityStateModel::GetVisibleSecurityState() which uses NavigationController::GetVisibleEntry(). I haven't really been following this bug but it sounds like it might be reasonable to, at least in some cases, use GetLastCommittedEntry() instead?

When an interstitial is showing, though, we definitely want to be using GetVisibleEntry(), not GetLastCommittedEntry(). (And also while a navigation is in progress, I think.)

Maybe ChromeSecurityStateModelClient needs to have GetLastCommittedSecurityInfo() and GetVisibleSecurityInfo() instead of a single GetSecurityInfo()...?

Wait-- we're talking about different things.  And you raise a good point.

We MUST stay with GetVisibleEntry for things in the OIB, since that's the URL showing in the omnibox.  Using GetLastCommittedEntry is the wrong thing to do in the case that we have a pending back/forward navigation (etc) and the URL doesn't match the last committed page.  Same with interstitial pages.

And for that matter, my recommendation to use GetLastCommittedOrigin would be wrong in those cases as well.  I was really recommending that you use the Origin and not the URL (and not recommending that you switch from Visible to LastCommitted).

What this means is that we might need to add an Origin to NavigationEntry.  And that's possibly non-trivial because it wouldn't be serialized for session restore.  (Then again, maybe we could get away without serializing it because the origin itself isn't inherited again if you restore the about:blank tab...)

 Issue 469889  has been merged into this issue.

I've written up a public doc with a deeper discussion about comment 21 and the direction we might want to head:

https://docs.google.com/document/d/1xcrOn2v28VrOspSuCTvBTcknvaF8HHAGnJfikUkKZss/edit?usp=sharing

 Issue 360138  has been merged into this issue.

Removing previous designers and adding maxwalker as the primary security contact

 Issue 666739  has been merged into this issue.