Supongo que su razonamiento es algo como: "Si la persona que construye la página elige enviar algunas de sus imágenes de forma insegura, el navegador debe respetar que esta decisión se tomó por una razón y permitirla sin advertencia. La página es tan seguro como la entidad que lo proporcionó quería ".

Por el contrario, el razonamiento de los desarrolladores del navegador es algo como: "Estamos colocando un icono seguro en la página tal como lo ve el usuario y el usuario debería poder asumir que eso significa que toda la página es segura. Si alguna parte de lo que no es, el usuario merece saber eso ".

Ambos argumentos son válidos, son solo interpretaciones diferentes de lo que significa que una página web sea segura.

También hay riesgos específicos con las imágenes. La imagen se solicita en claro utilizando el protocolo HTTP. Esto revela cualquier información en la URL o encabezados. La amenaza más seria es que la imagen podría contener instrucciones o información que el usuario asumiría que se originó de forma segura en el sitio que el usuario eligió. Esto podría ser usado para ataques de phishing.

El navegador no sabe qué tipo de información se supone que una imagen u otro recurso debe transmitir: tal vez sea solo un logotipo, o tal vez sea parte de la interfaz de usuario, o tal vez la imagen sea el punto entero de la página en la que está re visitando No hay forma de que el navegador sepa si un recurso es importante o no para el usuario.

Cuando la URL principal (página) está cargada con HTTPS, entonces el navegador le indica al usuario que la página que se está viendo es segura, generalmente con un icono lock o una barra de URL verde, o algo así como eso. No dice "esta página es segura, excepto esa única imagen", simplemente no hay un mecanismo para indicar al espectador qué partes son las partes inseguras. Entonces, en lugar de eso, la resolución es que si el navegador dice que la página es segura, TODOS los elementos de la página deben ser seguros, o el usuario debe ser notificado de la excepción.

Tenga en cuenta que ver una URL insegura con algunos elementos seguros no genera notificaciones ni advertencias, pero al mismo tiempo no hay ninguna señal para el usuario de que haya alguna medida de seguridad en la página. Dado que no hay expectativas de seguridad, la presencia de contenido mixto no es digna de mención.

Respuesta corta: falta de información semántica

Respuesta larga

En un foro, el usuario, naturalmente, espera que las cosas provengan de terceros "no autorizados" (cualquier usuario registrado, realmente podría ser cualquier persona), no solo del webmaster (y autores autorizados).

El usuario entiende completamente que los mensajes no representan la opinión del webmaster , y no están "autorizados" de ninguna manera por el propietario del dominio. Para cualquier usuario razonable, no existe una gran expectativa en particular con respecto al contenido de los mensajes que aparecen en la página web, o para las imágenes incluidas en dichos mensajes (existe una débil expectativa de que la escoria se elimine de manera oportuna, pero antes de que se elimine). Puede ser visto por cualquiera).

Pero un navegador web no entiende qué es un foro . Se espera que se confíe en la página https://example.com/ para que provenga de example.com y de manera segura (como en la seguridad del transporte) represente la opinión de example.com web-master, y cualquier imagen suficientemente insegura (en particular, IMG sin un tamaño explícito ) podría usarse para mostrar una gran advertencia de que

  

Tu cuenta está suspendida. Debes ir a http://fakesite-example.com/ para confirmarlo. Si no lo hace, su cuenta puede ser eliminada permanentemente.

renderizado como una imagen.

Por supuesto, en un mensaje del foro se consideraría que representa la opinión del autor del post, pero el navegador web no puede saberlo.

En realidad, tylerl, el navegador sabe qué tipo de información trata de transmitir un recurso.

El riesgo obvio es que la información se expone en la solicitud (una vez que se inyecta javascript en la página, es trivial inyectar datos en la URL sin cambiar la funcionalidad, por ejemplo, img.src = img.src + '? session = 1234' ;) y, por lo tanto, puede utilizarse para comprometer el intercambio.

Otro riesgo es que la imagen puede tener valor, en términos de derechos de autor, confidencialidad o tal vez como parte de un proceso de autenticación.