+screenshots

Deleted: chromeos_captive_portal_1.png 44.3 KB

	chromeos_captive_portal_1.png 44.3 KB View Download

Deleted: chromeos_captive_portal_2.png 29.5 KB

	chromeos_captive_portal_2.png 29.5 KB View Download

 https://crbug.com/386837  is the original bug introduced NetworkPortalWebDialog.
Add one more network label to increase the visibility of this issue. 

Thanks Jialiu!

alemate: According to  https://crbug.com/386837#c23 , this dialog is so that it can bypass proxy settings. 

Is there anything that can be done to improve the current situation? E.g. can we open an incognito window or something similar instead of using a webview? If that's still not possible, can we reuse SimpleWebViewDialog which displays a read only location bar?

(FWIW I noticed SimpleWebViewDialog crashes on alert() dialogs)

This is more complex than just adding an omnibox.  Captive portal can be triggered from a non-signed-in state meaning that if we added an omnibox there it could be used to do general browsing on a device with disabled guest mode.

kuscher@ this really needs thought from a PM perspective. Is there any way to add an onmibox without enabling general browsing?

> This is more complex than just adding an omnibox.  Captive portal can be triggered from a non-signed-in state meaning that if we added an omnibox there it could be used to do general browsing on a device with disabled guest mode.

I think you mean SimpleWebViewDialog which is different than this one. It has a read only omnibox that doesn't allow entering URLs.

Just to clarify, there are two different dialogs:
- Non signed-in state dialog uses SimpleWebViewDialog which has a read only URL bar.
- Signed-in and guest mode uses NetworkPortalWebDialog which doesn't have a URL bar (this bug).

I think we are always using Ephemeral user for captive portal authorization to bypass system proxy. But we have to make sure this cannot be used for anything other than signing in to Captive Portal.

alemate: Do you mean browsing with the proxy bypass shouldn't be allowed? Or do you mean browsing in general? (I think you mean the former, but just wanted to confirm, since browsing is already possible using existing browser windows)

Just exploring alternatives here: Would it be possible to do something similar by creating an extension that uses the chrome.proxy API, and loading an ephemeral browser window that runs that extension?

> alemate: Do you mean browsing with the proxy bypass shouldn't be allowed?
>  Or do you mean browsing in general? (I think you mean the former, but just
> wanted to confirm, since browsing is already possible using existing browser
> windows)

This is usually the case with enterprise devices when device-level proxy is configured by policy. It means the legitimate user cannot ever reach the captive portal interface, because proxy is not accessible.

So we implemented a poped-up dialog associated with ephemeral profile so that we can do captive portal authorization.

Enabling extensions for ephemeral profiles is tricky. So I'd vote against it.

But I am fine with replacing existing dialog with SimpleWebViewDialog provided that it doesn't need a real user profile to run.

Also a tricky point is that this dialog should be runnable when Browser object doesn't exist. But "not requiring regular user profile" usually means the same ;)

Thanks for the clarification. SimpleWebViewDialog doesn't have a Browser object either, so I think it should work.

Using SimpleWebViewDialog will solve the omnibox part of this bug, but we'll need to handle each of the remaining problems separately (alert dialogs, form-not-secure warnings, translation, zoom, favicons etc). Basically, any TabHelper that's created by TabHelpers class is not available to SimpleWebViewDialog, and that's a very large number of features. 

I started fixing these in bug 699197, but it's a rabbit hole and I feel like using a proper browser window would to be easier than doing these one by one :) (Then again, we might be able to simply call TabHelpers::AttachTabHelpers from SimpleWebViewDialog)

We should track this as a security bug: As it stands, an active network attacker can display arbitrary content without an omnibox in a system modal dialog box.

I briefly looked into using SimpleWebViewDialog for this purpose but so for haven't succeeded in doing so.