If you are using Chrome and are no longer are seeing images.

[wcfn100]

So here's the rollout for this 'feature'.



Taken from here:

https://www.theverge.com/2020/2/10/21132099/google-chrome-users-block-insecure-downloads-https-android-ios

Also says -

These warnings are also coming to the Android and iOS versions of Chrome, but the above schedule will be delayed by a release for the mobile platforms.

Jason

[Chris333]

Because if you post a train photo uncesurely Russia can hack it and turn it into an ad for who to vote for 

[C855B]

Interesting. So, basically, with v86 they're saying that unless a site operator pays somebody to maintain a certificate and reprogram their site for https:, content will not be viewable. Simple read-only content is thereby forced into "secure" world. So, others using Chrome essentially create a ransomware situation for me, where I have to pony up to play. Google can kiss my @$$.

[wcfn100]

Interesting. So, basically, with v86 they're saying that unless a site operator pays somebody to maintain a certificate and reprogram their site for https:, content will not be viewable. Simple read-only content is thereby forced into "secure" world. So, others using Chrome essentially create a ransomware situation for me, where I have to pony up to play. Google can kiss my @$$.

I think only secure sites trying to pull down non secure content are affected.  If your site is not secure, I think it's just a warning.  My own site in not secured and I get a warning in the address bar but I see the photos fine.

Jason

[C855B]

Uh... like TRW? That's the problem. TRW is secure, and linking from here to the non-secure content on my image archive server means Chrome users are or will be locked out from seeing my pix. Already had that problem last week, where a number of Chrome users didn't know about the (soon to vanish) workaround.

[wcfn100]

Uh... like TRW? That's the problem. TRW is secure, and linking from here to the non-secure content on my image archive server means Chrome users are or will be locked out from seeing my pix. Already had that problem last week, where a number of Chrome users didn't know about the (soon to vanish) workaround.

Yeah, that's where this seamed to start for several people.  I first noticed it when DKS started his animation threads.  I wasn't getting the images.

Jason

[DKS]

Interesting. So, basically, with v86 they're saying that unless a site operator pays somebody to maintain a certificate and reprogram their site for https:, content will not be viewable. Simple read-only content is thereby forced into "secure" world. So, others using Chrome essentially create a ransomware situation for me, where I have to pony up to play. Google can kiss my @$$.

Yep. And an SSL cert ain't cheap. Even worse: my host offers a generic SSL for free. Turned it on. Google said, sorry, generics are no good. Thank you, Google.

At least MS Edge still allows mixed content... so far. But since MS just apes everything Google does, there's no knowing how much longer Edge will still allow it.

[wcfn100]

At least MS Edge still allows mixed content... so far. But since MS just apes everything Google does, there's no knowing how much longer Edge will still allow it.

Hate to tell you, but Edge is built off Chromium.   It looks like the setting to block insecure content just isn't activated yet because it's set to block, but obviously isn't doing that.


Jason

[C855B]

Supposedly I can buy a certificate for $20/yr. for the domain I keep the images on, and it's a primary SSL.

HOWEVER, that doesn't automatically fix everything: 1) based on prior experience maintaining a dual HTTP/HTTPS site, I would need duplicate repositories, one for each access method. Maybe the site wasn't setup properly? Then, 2) I would have to touch EVERY link I have on TRW to change the HTTP to HTTPS. I have 1000+ images in the archive, nearly all linked from TRW during the 11 years I've been here.

[...sigh...]

Hate to tell you, but Edge is built off Chromium.   It looks like the setting to block insecure content just isn't activated yet because it's set to block, but obviously isn't doing that.

I just downloaded the current Chromium to see what was going on. It was set to block. Unblocking was a matter of clicking on the lock icon next to the URL (for TRW, not the image server domain) and change the Unsecure Content setting to 'Allow'. I guess that will be the workaround for the time being.

Not looking forward to bowing down before the HTTPS gods and screwing with my server. Last year's hardware crashes aside, it's not needed much maintenance or other sysadmin attention. I guess that was a luxury and it's time to pay the piper.

[Chris333]

So when does the new extension for Chrome come to fix all this?

[Chris333]

So now I'm at home on a real computer. 

Right now this site is set to allow and on this page I see a little pad lock to the left of the address bar. That is what I'd click to get into site settings.

Or I could be a caution triangle with a ! saying "not secure" to click to get into site settings.

[DKS]

HOWEVER, that doesn't automatically fix everything: 1) based on prior experience maintaining a dual HTTP/HTTPS site, I would need duplicate repositories, one for each access method. Maybe the site wasn't setup properly? Then, 2) I would have to touch EVERY link I have on TRW to change the HTTP to HTTPS. I have 1000+ images in the archive, nearly all linked from TRW during the 11 years I've been here.

It becomes a nightmare. No easy fix. I just did a quick inventory. I've got ~3,738 pages, ~17,198 images , and a rough guess of close to 50,000 links. I literally won't live long enough to fix all of that.

All we can do is hope that the Chromium boys catch enough sh!t from the owners of the bazillions of sites they're breaking that they back off, at least for images. I know Google thinks they own the Internet, but guess what...

[DKS]

Hate to tell you, but Edge is built off Chromium...

Yeah, now that I think on it, I recall reading that. Forgot.

[randgust]

OK, it took some digging but I found that setting and got images to display again.

But it still doesn't make any sense why the only image block in on Railwire.

[C855B]

... it still doesn't make any sense why the only image block in on Railwire.

I suspect because user-linked content on most other forum sites is hosted on commercial servers (Google and Photobucket, et al), which provide SSL. @DKS and I, for example, have our own read-only servers with no need for HTTPS since we aren't taking user input. Lots of resentment here about this Chrome thing, frankly.

Putting on my tin-foil hat, I think this move forcing Chrome to embargo embedded simple HTTP content "in the name of internet security" is a backdoor to force everybody to pay for services, be it image hosting, certificates, or pro web development. Running your own web server (server farm in my case) used to be relatively easy and there were once many tools to facilitate this, but the Silicon Valley mafia is making sure that we independents have as difficult a time as possible. If you experience what Apple has done to their OSes over the past six or so years to hobble self-hosting, you would better understand what's going on.

And I'll bring up my bigger problem with Chrome - the mothership. Don't think for a nanosecond that Alphabet/Google isn't tracking and recording the finest details about your browsing activities through their browser. Why would they bother? Because they can. And do. The vast unwashed masses comprising the browsing public don't know, or care, which is why Google gets away with it.

Bottom line to both situations? Don't use Chrome.