New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 638880 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Mixed content detection triggers on "mailto:" links

Project Member Reported by mmoroz@chromium.org, Aug 18 2016

Issue description

I was surfing a web and occasionally noticed that Chrome shows "Mixed content" message because of the following code:

<form action="mailto:mail@example.com" method="post">
    <input type="submit" value="some value">
</form>

The message looks like:

Mixed Content: The page at 'https://some_website/' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'mailto:mail@example.com'. This endpoint should be made available over a secure connection.


I guess that "mailto:" links should be ignored, but may be I'm wrong.

 
Repro page: https://www.whytls.com/test/mailto.htm

The mailto: protocol enables submission of web forms over email. In the browser itself, we don't have any way to know whether the mailto: protocol handler is going to behave in a secure manner. It may (HTTPS transport end-to-end) or it may not (non-authenticated SMTP), and thus I think this warning is appropriate. 

More generally, mailto: is pretty horrible from a privacy point-of-view (since it leaks the sender's email address). Launching such a link from IE shows:

---------------------------
Windows Internet Explorer
---------------------------
This form is being submitted using e-mail.
Submitting this form will reveal your e-mail address to the recipient,
and will send the form data without encrypting it for privacy.

You may continue or cancel this submission.
---------------------------
OK   Cancel   
---------------------------

Firefox shows:

---------------------------
Security Warning
---------------------------
The information you have entered on this page will be sent over an insecure connection and could be read by a third party.

Are you sure you want to send this information?
---------------------------
Continue   Cancel   
---------------------------

Notably, unlike Chrome, neither Firefox nor IE revokes the lock icon upon the initial display of the page. 
elawrence@: I don't think that argument is trying to justify an edge case that we didn't think about, or where too lazy to address.
Chrome sometimes *does* know the protocol handler (e.g. GMail or Inbox). And on the other side of the coin, even an HTTPS form submission may redirect to an HTTP page or be handled on the backend in a way that leaks details.

I'm interested in hearing from Mike whether anyone has explicitly thought about this for Chrome.
Status: Assigned (was: Untriaged)

Comment 4 by mkwst@chromium.org, Sep 6 2016

Cc: lgar...@chromium.org elawrence@chromium.org
1. Max sits next to me, so it's totally important that we fix this one way or another so I can avoid the evil eye. :)

2. I never thought about `mailto:`, no, but I like Eric's retconned justification for the current behavior, if not the current message.

So, let's change the message, but keep the UI-degrading behavior? Fewer `mailto:` forms is better `mailto:` forms.

Also, I don't like either IE or Firefox's current behavior.
Sounds good!

Comment 6 by raymes@chromium.org, Nov 30 2016

Components: -Security>UX Blink>SecurityFeature
Labels: Team-Security-UX

Comment 7 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 8 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment