Download images for oneboxes as well, if download images is set


(Mr.Burns avatar therefor TDWTF) #1

That is due to the oneboxing of the TDWTF post I included in the report here (the avatar image is http as https hasn’t been set up on that instance).


Links to Amazon cause a TLS mixed content warning
Oneboxed http link causes a TLS mixed content warning
Don't load http onebox images when using https
Generating a mixed content warning with a oneboxed link
Oneboxed http link causes a TLS mixed content warning
(Sam Saffron) #2

@zogstrip I thought we should be downloading that image locally, no?


(Régis Hanol) #3

Nope. We explicitely don’t download oneboxed images & avatars. Maybe that should change.


(Sam Saffron) #4

I think we should change this, insecure stamps in the URL bar are a compelling enough reason.

I am unclear why we would want to bypass here


(Jeff Atwood) #5

Why? We should worry about incorrect / unspecified image sizing (a bunch of github oneboxes causes the topic to shift around like a roller coaster) way before this. I do not support this at all until image dimensions are properly set.


(Michael Downey) #6
  • Unspecified image size causes pages to jump around as they’re rendered.
  • Mixed HTTPS & HTTP content causes browser warnings and scares people.

Which seems more serious?


(Jeff Atwood) #7

I assure you no average person cares or knows about https mixed content warnings, which are very subtle. Whereas the page bouncing around like an earthquake just hit is irritating and plainly visible to all users.


(Sam Saffron) #8

Well, we need to download the images to get the proper sizes, so this is part of the problem


(Jeff Atwood) #9

Not really, in the case of github the avatars are all fixed size anyway. Just specify a fixed size in the onebox.


(Régis Hanol) #10

That is now done :wink:

https://github.com/discourse/onebox/commit/aea7c578340f82eb9da8db70b211ec32e7b47276


(Sckott) #11

:+1: for this features, based on my related question Don't load http onebox images when using https


(⛰️) #12

That is not wise. At all.

Part of the SSL ‘industry’ includes educating consumers about the look of the padlock. Some corporations and business entities will go the extra length to get the certificate that includes their name.

Google is also using HTTPS as a deciding factor for page ranking.

So says one Google employee via Hacker News:

That Google actually checks fully for SSL errors now is irrelevant. What is relevant is someday they may do just that and more to make sure SSL certs are not purchased just for pagerank. They are already checking for mixed context in some form.

With all of these factors, you are only setting yourself up for a massive headache when Discourse-backed sites are penalized because of OneBox use.

You cannot bank on every single person that connects to a Discourse instance to not notice the broken padlock. I have noticed it. I know it also relates to OneBoxed youtube videos because I tested here on Meta.

A broken padlock = zero integrity. For an online business that means everything. Especially if they purchased the SSL just to have the padlock in the first place.

I implore you to reconsider. If not for everyone else then at least to mitigate. One ounce of prevention is worth a pound of cure.


(Jeff Atwood) #13

The browsers can’t tell when things are built and downloaded via JavaScript DOM changes versus initial http page loads.

e.g. when I go from “page” to “page” here there is an incorrect yellow padlock mixed content warning on this page which is not correct. It reflects previous page state. If you hard refresh this “page”, it shows green padlock.

Basically the padlock state only reflects the “page” that was initially loaded… navigating to a different “page” (via JavaScript, not an actual page load), does not reset the state of the padlock indicator…


(⛰️) #14

Even then that still does not change the fact we all have the ability to use our peripheral vision to notice the padlock is broken.

EDIT: Also, just because pageviews are generated for a user on the fly does not mean the static html will not have an error. Bots read html and that html will have the mixed content as well.

I did a security run to fact check your reply.

If this site detected it despite the dynamic per-user nature of the front end, then google will too.

Again, these errors will possibly penalize a site in some way. If not now, the future is uncertain.

My initial statement still stands.


(Mittineague) #15

I guess the solution here is to check if the Discourse forum is http or https and if not https don’t allow oneboxing http content. (with a “sorry” message would be best)


(⛰️) #16

If local-caching is not available right now for this, I think you’re right. Or perhaps disable all media and allow text-only.

As for an admin-user who has SSL but insists on disabling local caching for all images (OneBox or otherwise), that is out of purview.

EDIT: If Jeff is saying all OneBox content is written on the fly per pageload, then what is actually shown for clients that do not have javascript set?


(Kane York) #17

I just noticed an easy solution for part of this. Imgur supports https, and it’s big enough that rewriting all i.imgur.com links to be https is probably worth the effort.


(⛰️) #18

Yes, agreed. That is in relation to the idea of supporting any other OneBox sites that have https available. I know there’s also a few places that list all official https-carrying sites so browsers know to auto-ask for https first. Hooking into that may help if a user links media from a https site yet accidentally used http by mistake for whatever reason.


(Allen - Watchman Monitoring) #19

I love the idea of rewriting known URLs to https… but it seems to me that importing all the myriad of images, scripts, etc, which might be referenced in a onebox’d URL is a lot of stuff being imported.


(Erik Swanson) #20

Would it be reasonable/doable to add a knob that disables oneboxing in all cases except where it can be guaranteed to not cause a mixed-content warning?