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

Issue 794253 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature
Team-Security-UX



Sign in to add a comment

Browser is not marking insecure elements of the https page / doesn't allow to resign from them

Project Member Reported by mar...@mwiacek.com, Dec 12 2017

Issue description

Steps to reproduce the problem:
1. make search for example for "wish" in Google in page with mobile and desktop version

What is the expected behavior?
When there are insecure elements in the https page:

1. (short term) insecure pictures should be marked somehow in context menu

2. (long term) browser is asking whether they should be loaded or elements like insecure pictures should marked on the page (with red border?) or insecure pictures should be marked somehow in context menu

What went wrong?
When there is insecure element in the https page, user doesn't have any additional info about them

The problem with insecure elements is visible in mobile version of Google search page too (can be bug about this opened internally @ Google?)

Did this work before? No 

Chrome version: 65.0.3292.0  Channel: canary
OS Version: 7
Flash Version: 

It's rather Feature Request than bug
 
Components: UI>Security>UrlFormatting
Components: -UI>Security>UrlFormatting UI>Browser>Omnibox>SecurityIndicators>VerboseChip UI>Browser>Omnibox>SecurityIndicators
Labels: -Pri-2 Pri-3
Status: Untriaged (was: Unconfirmed)
Adjust components to relay to correct teams.
Temporarily put it to P3. I'd rely on component owners to triage this feature request and assign appropriate priority and labels. 

Cc: mkwst@chromium.org
Status: WontFix (was: Untriaged)
Thanks for the suggestion. At the moment we're focused on trying to drive down the occurrence of passive mixed content. We think this is a better use of our time rather than trying to expose more potentially confusing security info to users. (Most users won't understand what it means for an individual image to be nonsecure.) You can read more about what we'd like to do here: https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md

Comment 4 by mar...@mwiacek.com, Jan 7 2018

Currently even mobile Google page is insecure although is using https.

I understand your explanation, but I don't understand, why we cannot have the same explanation in context menu like in for page (see screenshots) which is easy to implement.

Please explain.
Screenshot_20180107-184015.png
314 KB View Download
Screenshot_20180107-184112.png
190 KB View Download

Comment 5 by mkwst@chromium.org, Jan 8 2018

For Google search pages, I imagine you're seeing non-secure image requests for image search, but only after performing the search and landing on the page that loads the images from their origin servers.

I'd be surprised if the search page itself was loading non-secure images (and I agree that in that case the site info interface you've screenshotted should be informing users of that issue).

Otherwise, I agree with Emily's notes above.

Comment 6 by mar...@mwiacek.com, Jan 8 2018

Comment to #5: when I open google.ch in desktop version and search for "test", I see full https security; when I open google.ch in mobile version and search for "test", I see info about broken https security

Because of it I will appreciate in Chrome info "hey, this element/picture is insecure" and of course it would be good to open internal Google bug about this (which I was also asking for).

Sign in to add a comment