Rechecked the issue on Windows 10, MAC 10.12.5, Ubuntu 14.04 using chrome version 59.0.3071.115. Followed the below steps:

1) Navigated to google.com which was displayed in a secure https connection
2) Opened dev tools and in console entered "window.open("jnlps://<uri_here>")"
3) A new empty tab was displayed
4) Navigated back to the original tab and no warnings was displayed in the console (Screen shot attached)

Kindly let us know if we have missed any steps here.

Thanks.!

Deleted: No Warning.png 118 KB

	No Warning.png 118 KB View Download

It's not clear in what sense `jnlps` is "secure". Generally speaking, Chrome cannot distinguish "secure" local protocols from "insecure" local protocols. Both end up running arbitrary code on a user's machine, based on the software they've locally installed.

 https://crbug.com/318788  and https://crbug.com/393481 have most of the history of the decisions we've made around blocking these requests, and/or surfacing them to users/developers via UI degradation and console warnings, respectively. Those were related to subresource requests, however. As comment #3 notes, I don't think we apply the same check to `window.open()` (though I don't think we made a principled decision there).

CCing estark@ for UI considerations, but I think I'm comfortable with the current state of Chrome's behavior.

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

ranjitkan@, in order to be able to see this alert you need to call the external protocol from an iframe. Calling it from the top level will not trigger it (or cause a navigation and you will not see it).

mkwst@, 'jnlps' is secure only in the sense that it uses ssl encrypted communication and requires a trusted certificate. Since this launches third party software already installed on the client's machine (javaws in this case), the user's decision to install that software and trust its provider has already previously been made. It is up to that third party to implement proper additional security measures. It seems to me that the "insecure resource" warning is not appropriate in this case. Moreover, the current behavior is that when an external protocol is launched a confirmation dialogue is presented to the user (with a 'remember my decision' option, most thankfully), so again, the user's consent is granted.

I am also comfortable with the current state of Chrome's behavior. Specifically, the ability to easily launch external protocols which enables the development of complex systems based on a combination of web and other technologies side by side (even if it requires the 'iframe hack' for now).

This console warning is just a minor nuisance.

@mkwst-- Could you please respond to comment #7 and help us in triaging the issue .

Thanks!

I'm comfortable with the existing behavior, as Chrome can't be expected to make a security decision about a protocol that executes arbitrary native code. IMO, that's something that's reasonable to flag as unsafe. But I'm not a UX guy, so I'm poking estark@ again for a more informed decision. :)

I'm not clear on how the actual warning gets triggered here. Merely `window.open` shouldn't trigger a warning (and I can't reproduce it). If we're talking about including the external protocol in an iframe, then unfortunately I agree with mkwst's assessment that we can't guarantee the safety of a local protocol.

Closing because of lack of feedback + reasoning in comment #9