12

Regarding the announcement from last March, Roadmap to HTTPS: serving and uploading HTTPS-images only, has there been a recent change to this policy?

Non-HTTPS images are being displayed on some posts. For example, from MathOverflow, see Is there a way to get the closed form approximate result of ...

Improve this question
8
  • 2
    Nothing has changed. It's likely the rewrite just missed that post when the conversion took place, possibly because it uses <IMG and the replace wasn't case-insensitive or something.
    – animuson StaffMod
    Mar 29, 2018 at 14:51
  • 1
    Yeah, that does look like a bug with the rebake. AFAICT, those images should've been turned into links, but apparently they weren't.
    – Ilmari Karonen
    Mar 29, 2018 at 16:14
  • 1
    Ps. Apparently there are 98 such missed posts on MO, most (but not all) of them from the same user who seems to be fond of uppercase <IMG> tags.
    – Ilmari Karonen
    Mar 29, 2018 at 16:34
  • changed into bug, if this is resolved then please mark it so...
    – Maarten Bodewes
    Apr 5, 2020 at 0:50
  • Confirmed, still an issue. Example post on Stack Overflow
    – Sonic the Save Ukraine-hog
    Apr 5, 2020 at 6:39
  • @Sonic any data how many such images are there? If dozens or even hundreds, we can edit manually, if thousands no choice but to re-run the script, case insensitive this time.
    – Shadow Wizard Says No More War
    Apr 5, 2020 at 11:23
  • 1
    @ShadowWizardisEarForYou Can't exactly say because the query times out. But I fixed a few instances on SO.
    – Sonic the Save Ukraine-hog
    Apr 5, 2020 at 11:29
  • @animuson It seems the rewrite never took place on per-site metas, and so there are a lot of non-HTTPS images being served on per-site metas: data.stackexchange.com/stackoverflow/query/…. Those all use standard Markdown for images, not things like capital <IMG tags.
    – Sonic the Save Ukraine-hog
    Jul 12, 2020 at 0:21

1 Answer 1

Reset to default
6

This seems to have been mostly fixed with the recent global re-rendering of most posts to CommonMark. All posts that were re-rendered as a result of the migration no longer exhibit this bug.

In the case of the one example I linked in the comments, the non-HTTPS image was previously showing in the revision history, but now it's only showing up as a link. Also, the query linked by Ilmari Karonen returns no results for most sites (as that checks the rendered HTML for a non-HTTPS image embed).

However, as the CommonMark migration post says, a small percentage of posts were not re-rendered, as they used potentially unsupported markup that could not be automatically edited out. This subset of posts is still affected by this bug. After some searching, I found an example.

In summary, this bug has been fixed in the rendering engine, as it no longer renders insecure images when it was updated to the CommonMark specification. However, the posts that weren't re-rendered with the updated renderer can still serve non-HTTPS images.

Update: After querying this across all network sites (except Stack Overflow due to its size), it seems the scope of this bug is a bit bigger than what I had thought before. It looks like the re-bake of non-HTTPS images into plain links never took place on per-site metas, and so there are a lot of per-site meta posts that serve non-HTTPS images. Those posts all use standard Markdown markup for images, so it's not the same (rare) issue encountered on main Q&A sites where there was a capital <IMG tag.

(Note: if you run the query above, only search for one year at a time - longer periods may make it time out.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .