https mixed content warning

[Raven]

https://gathering.tweakers.net/forum/view_message/49522865

http://cabforward.com/wp-...P-Crewmans-Smoke-Hood.png

[crisp]

Raven schreef op zaterdag 17 december 2016 @ 12:40:
https://gathering.tweakers.net/forum/view_message/49522865

http://cabforward.com/wp-...P-Crewmans-Smoke-Hood.png

Fixed

[Raven]

Thanks

[Hero of Time]

FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016" heeft ook een plaatje dat SSL errors geeft. Krijg helaas niet precies te zien wat er mis is, het certificaat of de chain.

[crisp]

Hero of Time schreef op maandag 19 december 2016 @ 21:20:
FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016" heeft ook een plaatje dat SSL errors geeft. Krijg helaas niet precies te zien wat er mis is, het certificaat of de chain.

Ook maar even via de proxy laten gaan

[Hero of Time]

Opnieuw: FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016"
Plaatje: https://content2.skoften....3/picdump_930_37__800.jpg
Ik dacht dat je skoften.net via de proxy laat lopen? Of is deze niet via de parser naar https omgezet maar door de poster zelf direct als https ingevuld?

[crisp]

Hero of Time schreef op woensdag 28 december 2016 @ 13:31:
Opnieuw: FreshMaker in "Het grote grappige plaatjes topic Editie Q4-2016"
Plaatje: https://content2.skoften....3/picdump_930_37__800.jpg
Ik dacht dat je skoften.net via de proxy laat lopen? Of is deze niet via de parser naar https omgezet maar door de poster zelf direct als https ingevuld?

Dat plaatje lijkt het hier gewoon goed te doen?

[Hero of Time]

Ik krijg er toch echt SSL meldingen op. Helaas is Otter erg beperkt hiermee. Opera 12 geeft echter geen melding. Vreemd.

[Raven]

https://gathering.tweakers.net/forum/view_message/49687869 + https://gathering.tweakers.net/forum/view_message/49687829 , gaat om dezelfde host: dslreports.com

[ Voor 4% gewijzigd door Raven op 01-01-2017 15:34 ]

[Osiris]

Wat een zakken hooi bij DSLreports: CloudFront ondersteunt namelijk gewoon TLS, dus ze zouden hun redirects wel eens mogen ver-TLS-en

[crisp]

Osiris schreef op zondag 1 januari 2017 @ 15:44:
Wat een zakken hooi bij DSLreports: CloudFront ondersteunt namelijk gewoon TLS, dus ze zouden hun redirects wel eens mogen ver-TLS-en

Ze staan nu iig op onze https 'shitlist'

[Raven]

McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

[ Voor 8% gewijzigd door Raven op 05-02-2017 11:43 ]

[Hero of Time]

Reddit? Het plaatje linkt naar imgur. De embedding is alleen wat fout gedaan door hem omdat het door reddit gaat naar imgur (hij heeft de link van het plaatje van reddit ipv de directe link).

[_David_]

Raven schreef op zondag 5 februari 2017 @ 11:42:
McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

Imgur*

De outbound tracking link van Reddit (out.reddit.com) is wel HTTPS, maar de imgur URL waar die naar doorstuurt is dat weer niet HTTPS...

Is het niet een idee om die out.reddit.com links te verbouwen zodat alleen de 'echte' URL (URL parameter) er uitgehaald wordt?

Edit: ik zie dat crisp al aan het editten is

[ Voor 5% gewijzigd door _David_ op 05-02-2017 12:35 ]

[crisp]

Raven schreef op zondag 5 februari 2017 @ 11:42:
McGryphon in "Het Grote Kleinemededelingentopic - Deel 358 (echt!)"
Reddit dit keer.

Dat plaatje is gewoon stuk..

[Raven]

Hero of Time schreef op zondag 5 februari 2017 @ 12:23:
Reddit? Het plaatje linkt naar imgur. De embedding is alleen wat fout gedaan door hem omdat het door reddit gaat naar imgur (hij heeft de link van het plaatje van reddit ipv de directe link).

Woops, zo ver had ik niet gekeken

crisp schreef op zondag 5 februari 2017 @ 12:27:
[...]

Dat plaatje is gewoon stuk..

Nu wel ja , laad niet meer.

[_David_]

crisp schreef op zondag 5 februari 2017 @ 12:27:
[...]

Dat plaatje is gewoon stuk..

De eerste keer dat ik de link opende (voordat hij geedit werd ) deed hij het nog, en als je de link uit de URL parameter haalt, dat doet ie het ook:

[Hero of Time]

Link in img tags hoort eigenlijk https://i.imgur.com/cNqQlY7.jpg te zijn, zoals _David_ demonstreert.

[crisp]

Bij deze aangepast

[Raven]

Weer eens een mixed content warning: Touchdomex in "Het grote kleinemededelingentopic - Deel 360"

[crisp]

Raven schreef op zaterdag 11 maart 2017 @ 10:00:
Weer eens een mixed content warning: Touchdomex in "Het grote kleinemededelingentopic - Deel 360"

Aangepast

[_David_]

De smiley in de quickreply alert van dit topic: [alg] Slechtste programmeervoorbeelden deel 5 is niet gereparsed naar https.

HTML:

<div class="bar warning topicwarning">
<strong>Let op:</strong>
<br>Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. 
<img src="http://tweakimg.net/g/s/smile.gif" alt=":)" />
</div>

[crisp]

_David_ schreef op zondag 19 maart 2017 @ 18:27:
De smiley in de quickreply alert van dit topic: [alg] Slechtste programmeervoorbeelden deel 5 is niet gereparsed naar https.

HTML:

<div class="bar warning topicwarning">
<strong>Let op:</strong>
<br>Uiteraard is het in dit topic niet de bedoeling dat andere users en/of topics aangehaald worden om ze voor gek te zetten. Lachen om je eigen code, of over dingen die je "wel eens tegengekomen bent" is prima, maar hou het onderling netjes. 
<img src="http://tweakimg.net/g/s/smile.gif" alt=":)" />
</div>

Aangepast

[Raven]

Weer een: Saffie_time in "Het grote kleineSmålandtopic - Deel 361"
host: www.112groningen.nl

[ Voor 74% gewijzigd door Raven op 27-03-2017 10:28 ]

[crisp]

Raven schreef op maandag 27 maart 2017 @ 10:25:
Weer een: Saffie_time in "Het grote kleineSmålandtopic - Deel 361"
host: www.112groningen.nl

Fixed

[Raven]

https://gathering.tweakers.net/forum/view_message/51081671
http://www.autoblog.nl dit keer.

[crisp]

Raven schreef op maandag 1 mei 2017 @ 19:08:
https://gathering.tweakers.net/forum/view_message/51081671
http://www.autoblog.nl dit keer.

Fixed

[Raven]

Weer een tegengekomen: https://gathering.tweakers.net/forum/view_message/51285219
www.112groningen.nl

[crisp]

Raven schreef op zaterdag 20 mei 2017 @ 10:52:
Weer een tegengekomen: https://gathering.tweakers.net/forum/view_message/51285219
www.112groningen.nl

Fix0red

[Raven]

Crim in "Betatest nieuwe redactionele layout"
https://imageshack.com/a/img924/2629/u0TACm.png

[crisp]

Raven schreef op woensdag 14 juni 2017 @ 16:52:
Crim in "Betatest nieuwe redactionele layout"
https://imageshack.com/a/img924/2629/u0TACm.png

meh, die redirect naar http://imagizer.imageshack.us/a/img924/2629/u0TACm.png terwijl https://imagizer.imageshack.us/a/img924/2629/u0TACm.png ook gewoon werkt

Anyway, fixed voor deze, maar aangezien imageshack vaak gebruikt wordt zullen we hier ben ik bang wel even verder maatregelen voor treffen...

[Raven]

Vaak? Ik kan mij niet eens herinneren wanneer die voor het laatst gebruikt werd hier Tegenwoordig is het meer imgur dan wat anders en daar kun je geëmbedde plaatjes niet zomaar van saven (Zelfde als https://www.reddit.com/r/..._photos_from_photobucket/ )

Thanks

[Raven]

CaptJackSparrow in "[Ervaringen] Oplaadbare Batterijen"
https://www.aldi.nl/image...batterijen_big_115610.jpg

[ Voor 23% gewijzigd door Raven op 25-06-2017 13:46 ]

[Osiris]

Raven schreef op zondag 25 juni 2017 @ 13:39:
CaptJackSparrow in "[Ervaringen] Oplaadbare Batterijen"
https://www.aldi.nl/image...batterijen_big_115610.jpg

Da's ook wel een beetje gepruts van Aldi's kant:

[b][green]osiris@desktop [/][blue]~ $ [/][/]curl -vIL https://www.aldi.nl/images/oplaadbare_batterijen_big_115610.jpg
*   Trying 54.230.14.125...
* Connected to www.aldi.nl (54.230.14.125) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=DE; ST=Nordrhein-Westfalen; L=Essen; O=Aldi Einkauf GmbH & Co. oHG; CN=www.aldi.nl
*  start date: Apr 26 00:00:00 2017 GMT
*  expire date: Nov 14 23:59:59 2017 GMT
*  subjectAltName: host "www.aldi.nl" matched cert's "www.aldi.nl"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SHA256 SSL CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* TCP_NODELAY set
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1bb01c0)
> HEAD /images/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2.0 302 
HTTP/2.0 302 
< content-type: text/html; charset=iso-8859-1
content-type: text/html; charset=iso-8859-1
< content-length: 253
content-length: 253
< location: http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
location: http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
< server: nginx
server: nginx
< date: Sun, 25 Jun 2017 12:28:13 GMT
date: Sun, 25 Jun 2017 12:28:13 GMT
< x-frame-options: *
x-frame-options: *
< expires: Sun, 25 Jun 2017 14:28:13 GMT
expires: Sun, 25 Jun 2017 14:28:13 GMT
< cache-control: max-age=7200
cache-control: max-age=7200
< x-cache-status: HIT
x-cache-status: HIT
< age: 24
age: 24
< x-cache: Hit from cloudfront
x-cache: Hit from cloudfront
< via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
< x-amz-cf-id: EK43sa07LGt6nG8pMXzBJWtEN2zB_YTUp8MWo5B9OvJddGnDOSjQbQ==
x-amz-cf-id: EK43sa07LGt6nG8pMXzBJWtEN2zB_YTUp8MWo5B9OvJddGnDOSjQbQ==

< 
* Connection #0 to host www.aldi.nl left intact
* Issue another request to this URL: 'http://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg'
*   Trying 54.230.128.156...
* Connected to www.aldi.nl (54.230.128.156) port 80 (#1)
> HEAD /images_archiv/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: CloudFront
Server: CloudFront
< Date: Sun, 25 Jun 2017 12:28:38 GMT
Date: Sun, 25 Jun 2017 12:28:38 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 183
Content-Length: 183
< Connection: keep-alive
Connection: keep-alive
< Location: https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
Location: https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg
< X-Cache: Redirect from cloudfront
X-Cache: Redirect from cloudfront
< Via: 1.1 b2053f9f1abb60895bf31f80837ba9b6.cloudfront.net (CloudFront)
Via: 1.1 b2053f9f1abb60895bf31f80837ba9b6.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: XEd8axI7ZYAqWk45hEgu6TIcEbhLNtQcgH9ceb0Y0kTI8qT4OV2s1g==
X-Amz-Cf-Id: XEd8axI7ZYAqWk45hEgu6TIcEbhLNtQcgH9ceb0Y0kTI8qT4OV2s1g==

< 
* Connection #1 to host www.aldi.nl left intact
* Issue another request to this URL: 'https://www.aldi.nl/images_archiv/oplaadbare_batterijen_big_115610.jpg'
* Found bundle for host www.aldi.nl: 0x1bc65f0 [can multiplex]
* Re-using existing connection! (#0) with host www.aldi.nl
* Connected to www.aldi.nl (54.230.14.125) port 443 (#0)
* Using Stream ID: 3 (easy handle 0x1bb01c0)
> HEAD /images_archiv/oplaadbare_batterijen_big_115610.jpg HTTP/1.1
> Host: www.aldi.nl
> User-Agent: curl/7.49.0
> Accept: */*
> 
< HTTP/2.0 200 
HTTP/2.0 200 
< content-type: image/jpeg
content-type: image/jpeg
< content-length: 130909
content-length: 130909
< server: nginx
server: nginx
< date: Sun, 25 Jun 2017 12:28:38 GMT
date: Sun, 25 Jun 2017 12:28:38 GMT
< x-frame-options: *
x-frame-options: *
< last-modified: Fri, 23 Jun 2017 13:19:41 GMT
last-modified: Fri, 23 Jun 2017 13:19:41 GMT
< expires: Sun, 25 Jun 2017 14:28:38 GMT
expires: Sun, 25 Jun 2017 14:28:38 GMT
< cache-control: max-age=7200
cache-control: max-age=7200
< x-cache-status: HIT
x-cache-status: HIT
< accept-ranges: bytes
accept-ranges: bytes
< x-cache: Miss from cloudfront
x-cache: Miss from cloudfront
< via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
via: 1.1 36a14b9cb5cc947f05a9a38c2e38f707.cloudfront.net (CloudFront)
< x-amz-cf-id: ZufVknDqNyqOuI7UrjItKqWkuls1g5lBJ9m4n15aZQ5TLEqjbI8hFw==
x-amz-cf-id: ZufVknDqNyqOuI7UrjItKqWkuls1g5lBJ9m4n15aZQ5TLEqjbI8hFw==

< 
* Connection #0 to host www.aldi.nl left intact
[b][green]osiris@desktop [/][blue]~ $ [/][/]

De URL wordt geredirect naar een ander path, via een non-HTTPS-URL. Komt uiteindelijk wel weer uit bij een HTTPS-URL, dus een nutteloze tussenstap, maar da's Aldi's fout.

Idealiter zou de caching server de redirects volgen totdat 'ie bij de daadwerkelijke content uitkomt en die laatste URL gebruiken indien er een HTTP redirect in voorkomt.

[crisp]

Dan maar via onze eigen proxy

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 14:36:
Dan maar via onze eigen proxy

Misschien wel interessant om een eventuele patch voor "follow redirects with non-HTTPS-checking" ook via GitHub aan te bieden?

Of blijft 't bij handmatig fixen van dit soort issues?

[crisp]

Osiris schreef op zondag 25 juni 2017 @ 14:58:
[...]

Misschien wel interessant om een eventuele patch voor "follow redirects with non-HTTPS-checking" ook via GitHub aan te bieden?

Of blijft 't bij handmatig fixen van dit soort issues?

Onze proxy volgt gewoon redirects? Het probleem was dat de link in 1e instantie niet geproxied werd omdat de https-versie an sich gewoon werkte. Het blijft handwerk om imagehosts die https redirecten naar/via http via onze proxy te forceren. Dat, of echt alles gaan proxieën ook als https wel goed werkt...

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 15:14:
[...]

Onze proxy volgt gewoon redirects? Het probleem was dat de link in 1e instantie niet geproxied werd omdat de https-versie an sich gewoon werkte. Het blijft handwerk om imagehosts die https redirecten naar/via http via onze proxy te forceren.

Je kunt natuurlijk ook gedurende het redirecten checken of er een non-HTTPS URL tussen zit en indien dat het geval is geen genoegen nemen met die chain of redirects en het geheel proxien. Iets wat klaarblijkelijk nu niet gebeurt? Dat lijkt me niet per se handwerk te hoeven zijn.

crisp schreef op zondag 25 juni 2017 @ 15:14:
(…) of echt alles gaan proxieën ook als https wel goed werkt...

Dat is het nou net: het werkt niet goed zodra er bij al die redirects er een HTTP-URL tussen zit. Dan accepteert (in ieder geval) Chromium het plaatje niet zonder het groene slotje weg te halen.

[ Voor 26% gewijzigd door Osiris op 25-06-2017 15:20 ]

[crisp]

@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 17:15:
@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

En er komt klaarblijkelijk geen error-event op een mixed-content-warning? Is er geen warning te vinden somehow in dat proces? Want de browser spuugt zo'n warning wel over de console heen, de vraag is alleen of je dat bij je client-side check t.b.v. de caching proxy kunt gebruiken

[ Voor 15% gewijzigd door Osiris op 25-06-2017 17:26 ]

[crisp]

Osiris schreef op zondag 25 juni 2017 @ 17:25:
[...]

En er komt klaarblijkelijk geen error-event op een mixed-content-warning? Is er geen warning te vinden somehow in dat proces? Want de browser spuugt zo'n warning wel over de console heen, de vraag is alleen of je dat bij je client-side check t.b.v. de caching proxy kunt gebruiken

Nope, het plaatje laadt immers wel...

[Osiris]

crisp schreef op zondag 25 juni 2017 @ 20:11:
[...]

Nope, het plaatje laadt immers wel...

Is 't niet mogelijk algemene waarschuwingen af te vangen (lees: mixed content warnings) en te checken of het 't desbetreffende plaatje betreft?

Sowieso natuurlijk goed om global mixed content warnings proberen af te vangen, aangezien dat 't doel is van de proxy Moet 't alleen wél mogelijk zijn

[Raven]

Ze germans are coming?
@crisp Geen specifieke post dit keer, het gaat op elke pagina mis

http://www.smartdodo.com/GOT/heilpompom.gif

[crisp]

Raven schreef op maandag 3 juli 2017 @ 14:46:
Ze germans are coming?
@crisp Geen specifieke post dit keer, het gaat op elke pagina mis

http://www.smartdodo.com/GOT/heilpompom.gif

Maar even in mijn eigen fotoalbum gezet; die is wel https

[Raven]

Dat is ook een oplossing

Overigens, die domeinnaam, @SmartDoDo ?

[Hero of Time]

gambieter in "Het grote grappige plaatjes topic Editie Q3-2017" bevat een Fokke en Sukke plaatje gehost op http://www.cs.vu.nl//~fra...kke-sukke-consultancy.jpg. Het plaatje staat er met https in, maar redirect direct naar http. Met als gevolg dat in mijn geval het plaatje niet geladen wordt.

[crisp]

Hero of Time schreef op donderdag 6 juli 2017 @ 12:05:
gambieter in "Het grote grappige plaatjes topic Editie Q3-2017" bevat een Fokke en Sukke plaatje gehost op http://www.cs.vu.nl//~fra...kke-sukke-consultancy.jpg. Het plaatje staat er met https in, maar redirect direct naar http. Met als gevolg dat in mijn geval het plaatje niet geladen wordt.

Fix0red

[Hero of Time]

crisp schreef op donderdag 6 juli 2017 @ 12:07:
[...]

Fix0red

Wauw. Snelheidsrecord?

[Raven]

https://gathering.tweakers.net/forum/view_message/51792425

Mixed content warning via IPv4, via IPv6 laad de hele afbeelding niet:

Uw verbinding is niet beveiligd

De eigenaar van www.hopefarms.nl heeft zijn of haar website niet juist geconfigureerd. Om uw gegevens tegen diefstal te beschermen, heeft Firefox geen verbinding met deze website gemaakt.

[ Voor 46% gewijzigd door Raven op 12-07-2017 11:37 ]

[crisp]

Raven schreef op woensdag 12 juli 2017 @ 11:36:
https://gathering.tweakers.net/forum/view_message/51792425

Mixed content warning via IPv4, via IPv6 laad de hele afbeelding niet:

[...]

En ook via de proxy geforceerd

[Raven]

Zojuist weer eens een warning tegengekomen, alleen was ik verantwoordelijk
http://wp.tipsenweetjes.n.../uploads/2017/04/Toet.jpg
Het bericht is al aangepast door het plaatje via mijn eigen domeinnaam/hostingpakket weer te geven.

Kan de betreffende hoster (tipsenweetjes.nl) via de proxy geforceerd worden?

[Raven]

Weer een: keverjeroen in "Het Grote Lego Topic - Deel 5"
gamer.vjmedia.com

[crisp]

Raven schreef op woensdag 23 augustus 2017 @ 10:28:
Weer een: keverjeroen in "Het Grote Lego Topic - Deel 5"
gamer.vjmedia.com

Fixed

Raven schreef op zaterdag 12 augustus 2017 @ 15:25:
Zojuist weer eens een warning tegengekomen, alleen was ik verantwoordelijk
http://wp.tipsenweetjes.n.../uploads/2017/04/Toet.jpg
Het bericht is al aangepast door het plaatje via mijn eigen domeinnaam/hostingpakket weer te geven.

Kan de betreffende hoster (tipsenweetjes.nl) via de proxy geforceerd worden?

Ik zet niet elk domein op onze proxylijst; alleen als een domein vaker gebruikt wordt voor embedded plaatjes. Anders wordt het een nodeloos lange lijst...

[.oisyn]

crisp schreef op zondag 25 juni 2017 @ 17:15:
@Osiris: de check of https 'werkt' wordt clientside al gedaan door te checken of het plaatje geen error-event afvuurt. Dan is dus niet te bepalen of er een http-redirect tussen zit.

Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:14:
[...]


Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

Omdat het het inladen van het plaatje niet blokkeert. Het is non-active content, dus geeft enkel een warning. Of het met de fetch API dus wel een error oplevert is nog maar de vraag...

[.oisyn]

@crisp Het gaat niet zozeer om de error zelf, met de fetch API kun je redirects detecteren.

[Raven]

crisp schreef op woensdag 23 augustus 2017 @ 11:03:
[...]

Fixed

crisp schreef op woensdag 23 augustus 2017 @ 11:03:
[...]

Ik zet niet elk domein op onze proxylijst; alleen als een domein vaker gebruikt wordt voor embedded plaatjes. Anders wordt het een nodeloos lange lijst...

Ok

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:44:
@crisp Het gaat niet zozeer om de error zelf, met de fetch API kun je redirects detecteren.

Ah ja, dat zou sowieso handig zijn. Ik zal er eens naar kijken

[Raven]

Jan Treur in "Elektrische auto's - Deel 2"

https://www.few.vu.nl/~tr...ngeindication20170806.jpg

[crisp]

Raven schreef op zondag 10 september 2017 @ 15:10:
Jan Treur in "Elektrische auto's - Deel 2"

https://www.few.vu.nl/~tr...ngeindication20170806.jpg

Fix0red

[Raven]

crisp schreef op zondag 10 september 2017 @ 15:14:
[...]

Fix0red

[Hero of Time]

Saffie_time in "19-9 Talk like a Pirate-day" heeft een plaatje https://stupidstuff.org/source/pirate05.jpg welke niet volledig HTTPS is. De site draait erop, maar bied geen certificaat aan. In mijn geval zie ik geen plaatje. Open ik de afbeelding direct in Firefox, dan krijg ik geen waarschuwing maar wel het plaatje (site zelf net zo), omdat het teruggaat naar http. Kan die via de proxy gaan?

[ Voor 3% gewijzigd door Hero of Time op 19-09-2017 08:14 ]

[crisp]

Hero of Time schreef op dinsdag 19 september 2017 @ 08:12:
Saffie_time in "19-9 Talk like a Pirate-day" heeft een plaatje https://stupidstuff.org/source/pirate05.jpg welke niet volledig HTTPS is. De site draait erop, maar bied geen certificaat aan. In mijn geval zie ik geen plaatje. Open ik de afbeelding direct in Firefox, dan krijg ik geen waarschuwing maar wel het plaatje (site zelf net zo), omdat het teruggaat naar http. Kan die via de proxy gaan?

Er gingen wel meer plaatjes fout in dat topic. Bij deze gefixed

[Hero of Time]

Ja, die in de TW bijvoorbeeld, maar dat kon een GC mod ook fixen. Rest van de reacties niet gecontroleerd.

[Raven]

Goldia in "Cities: Skylines - Deel 2"
https://goo.gl/EeYLfc -> http://members.ziggo.nl/w...images/Screenshot%206.png

[crisp]

Raven schreef op maandag 25 september 2017 @ 11:30:
Goldia in "Cities: Skylines - Deel 2"
https://goo.gl/EeYLfc -> http://members.ziggo.nl/w...images/Screenshot%206.png

Fixed. Shorteners gebruiken voor plaatjes is sowieso maar raar...

[Raven]

crisp schreef op maandag 25 september 2017 @ 12:15:
[...]

Fixed.

crisp schreef op maandag 25 september 2017 @ 12:15:
Shorteners gebruiken voor plaatjes is sowieso maar raar...

Dat vond ik ook raar , wist niet eens dat de img-parser daar mee overweg kon

[crisp]

Raven schreef op maandag 25 september 2017 @ 12:34:
[...]



[...]


Dat vond ik ook raar , wist niet eens dat de img-parser daar mee overweg kon

De parser kijkt alleen of het een valide url is

[Raven]

crisp schreef op maandag 25 september 2017 @ 13:15:
[...]

De parser kijkt alleen of het een valide url is

Ok

[Raven]

Verwijderd in "HELP-wat voor aansluiting heb ik en hoe krijg ik internet?"
https://extreme.pcgamesha...n-img_20130828_173847.jpg

[crisp]

Raven schreef op dinsdag 3 oktober 2017 @ 22:56:
Verwijderd in "HELP-wat voor aansluiting heb ik en hoe krijg ik internet?"
https://extreme.pcgamesha...n-img_20130828_173847.jpg

Slotje is weer mooi groen

[Raven]

crisp schreef op dinsdag 3 oktober 2017 @ 23:03:
[...]

Slotje is weer mooi groen

, thanks

[crisp]

.oisyn schreef op woensdag 23 augustus 2017 @ 11:14:
[...]


Waarom komt er eigenlijk geen error-event? De client zou op dat moment al last moeten hebben van mixed content warnings.

Met de fetch API zou je het overigens wel moeten kunnen detecteren.

We hebben gekeken naar de fetch API, maar we lopen daarmee (uiteraard) tegen de cross-domain policy aan. Met no-cors kan je nagenoeg geen properties uitlezen van het Response object wat het helaas onbruikbaar maakt...

[Raven]

Boegie in "Het Grote Kleine Mededelingentopic - Deel 369"
https://memeshappen.com/media/created/2017/02/BUT-WHY-.jpg

[crisp]

Raven schreef op zaterdag 7 oktober 2017 @ 12:37:
Boegie in "Het Grote Kleine Mededelingentopic - Deel 369"
https://memeshappen.com/media/created/2017/02/BUT-WHY-.jpg

Fixed

[Raven]

Dat was snel

[Raven]

Coffeemonster in "Het Grote Kleinemededelingentopic - Deel 370"
https://www.toxel.com/wp-...2011/06/privacydesk01.jpg

[ Voor 19% gewijzigd door Raven op 25-10-2017 13:47 ]

[crisp]

Raven schreef op woensdag 25 oktober 2017 @ 13:46:
Coffeemonster in "Het Grote Kleinemededelingentopic - Deel 370"
https://www.toxel.com/wp-...2011/06/privacydesk01.jpg

Fixed

[Raven]

crisp schreef op woensdag 25 oktober 2017 @ 14:13:
[...]

Fixed

Thanks

[Raven]

Daar gaan we weer

Ramzzz in "Het Grote Gitaartopic - deel 8"
profile.ultimate-guitar.com

[crisp]

Raven schreef op zondag 10 december 2017 @ 17:44:
Daar gaan we weer

Ramzzz in "Het Grote Gitaartopic - deel 8"
profile.ultimate-guitar.com

Fixed

[Raven]

crisp schreef op zondag 10 december 2017 @ 17:57:
[...]

Fixed

[.oisyn]

Enigszins gerelateerd. Zojuist postte iemand in het plaatjestopic het volgende plaatje: http://www.dewals.nl/plaatjes/gammel.jpg

Deze werd door de plaatjeschecker geconverteerd naar de HTTPS variant: https://www.dewals.nl/plaatjes/gammel.jpg. En het plaatje is idd ook via die URL beschikbaar, alleen is het certificaat niet geldig. Maar ja, de plaatjeschecker runt lokaal in de browser van de poster, dus als de poster van het plaatje dat certificaat vertrouwt of de error genegeerd heeft, dan wordt er dus doodleuk HTTPS van gemaakt en zitten we met een niet werkend plaatje.

Hier is natuurlijk niet heel veel aan te doen, behalve het request via t.net te laten lopen ipv lokaal. Een andere optie is eventueel om niet https te checken voor onbekende domeinen, zodat het sowieso al gewoon via de proxy loopt.

[ Voor 11% gewijzigd door .oisyn op 04-10-2018 12:15 ]

[Hero of Time]

Weer eentje in het plaatjes topic: Sjonny in "Het grote grappige plaatjes topic Editie 2018"
Wijst naar https://assets.amuniversa...0b84b013660cb005056a9545d, wat een incorrect SSL certificaat heeft en bij mij iig niet geladen wordt. Als ik echter http://assets.amuniversal...0b84b013660cb005056a9545d open, werkt het wel gewoon. Lijkt er dus ook op dat de image checker incorrect denkt dat https gewoon werkt omdat de server erop reageert.

[ACM]

Hero of Time schreef op donderdag 1 november 2018 @ 22:14:
Lijkt er dus ook op dat de image checker incorrect denkt dat https gewoon werkt omdat de server erop reageert.

Sterker nog, hij ziet een https-url (zoals al eerder in dit topic gemeld) en vertrouwd erop dat dat klopt. Gaan we wmb ook niet fixen.

Het is in beginsel de verantwoordelijkheid van de gebruiker om afbeeldingen te linken die werken, maar doet ie dat met http; dan zetten wij dat om via onze https-proxy, de gebruiker heeft tenslotte niet altijd de keus om er https van te maken.

Het is niet ons doel om automatisch alle afbeeldingen te downloaden en te checken of e.e.a. ook echt werkt met https. Dat is bovendien onbetrouwbaar, want certificaten en protocollen verouderen/verlopen of kunnen in (specifieke) browsers uitgesloten worden. Dat zou dan betekenen dat we eigenlijk elke https-afbeelding steeds opnieuw zouden moeten controleren...

Wat mij betreft stoppen we ook met dit soort foutieve urls als 'bug' te beschouwen, het is uiteindelijk gewoon een onjuist geplaatste afbeelding. Daar zijn wmb de topicreports voor

[Hero of Time]

ACM schreef op donderdag 1 november 2018 @ 22:24:
[...]

Sterker nog, hij ziet een https-url (zoals al eerder in dit topic gemeld) en vertrouwd erop dat dat klopt. Gaan we wmb ook niet fixen.

Het is in beginsel de verantwoordelijkheid van de gebruiker om afbeeldingen te linken die werken, maar doet ie dat met http; dan zetten wij dat om via onze https-proxy, de gebruiker heeft tenslotte niet altijd de keus om er https van te maken.

Maar dat gaat dus regelmatig fout, zoals in dit geval waarschijnlijk ook gebeurt is. Zoals hier ook is genoemd, doet de image checker een controle om te zien of de locatie ook via https bereikbaar is en past de URL aan. De gebruiker heeft hier 0 invloed op, tenzij je het afbreken van de controle invloed wilt noemen. Het wordt dus helemaal niet via de proxy gestuurd. Dat gebeurt pas als het plaatje niet via https te serveren is, oftewel, als de webserver waar het plaatje staat niet op 443 luistert.

Wat mij betreft stoppen we ook met dit soort foutieve urls als 'bug' te beschouwen, het is uiteindelijk gewoon een onjuist geplaatste afbeelding. Daar zijn wmb de topicreports voor

Prima, als we maar invloed hebben of het plaatje wel of niet achter een werkende https server hangt.

Voor het idee zet ik het plaatje hier in img tags, zonder https en druk alleen op 'Verstuur'. Eens zien wat er gebeurt.


Edit:
Verrek, het doet niet idioot https ervan maken. Is dat in de tussentijd verandert?

[ACM]

Hero of Time schreef op donderdag 1 november 2018 @ 22:39:
Edit:
Verrek, het doet niet idioot https ervan maken. Is dat in de tussentijd verandert?

Vast niet, maar wellicht deed dat plaatje het wel bij de topicstarter via https... Je weet maar nooit wat men allemaal aan certificaten whitelist

Overigens doet de afbeelding in de reactie waar jij naar verwijst het ook gewoon via https bij mij, zonder browser-warning.

[ Voor 15% gewijzigd door ACM op 01-11-2018 22:46 ]

[.oisyn]

Maar is het echt zo'n impact om gewoon te respecteren wat de gebruiker heeft aangegeven, ipv op goed geluk https te proberen bij de client? Zoals ik al eerder zei, desnoods doe je dat alleen bij een handjevol bekende hosts, dan heb je al meteen de grote bulk van de plaatjes.

[ Voor 32% gewijzigd door .oisyn op 01-11-2018 23:10 ]

[crisp]

Omgekeerd: gaat het echt zo vaak nog fout dan?

desnoods doe je dat alleen bij een handjevol bekende hosts, dan heb je al meteen de grote bulk van de plaatjes.

Dat doen we serverside iig al

[Hero of Time]

ACM schreef op donderdag 1 november 2018 @ 22:44:
[...]

Vast niet, maar wellicht deed dat plaatje het wel bij de topicstarter via https... Je weet maar nooit wat men allemaal aan certificaten whitelist

Overigens doet de afbeelding in de reactie waar jij naar verwijst het ook gewoon via https bij mij, zonder browser-warning.

Nu op werk in Firefox doet 'ie het idd, maar gisteravond thuis met Otter dus niet, daar krijg ik deze melding:

Connection is insecure
The owner of assets.amuniversal.com has configured their page improperly. To protect your information from being stolen, connection to this website was aborted.

Als ik dan kijk naar het certificaat, staat er dan ook ssl.cdngc.net bij Common Name. Daar zal Otter over vallen denk ik zo. En het is ook volkomen terecht dat er zo'n melding komt, wat de naam in het certificaat komt niet overeen met de site die ik bezoek. Alsof ik een certificaat voor Google krijg als ik Tweakers bezoek. Valideert allebei, maar niet voor de juiste site.

[crisp]

Hero of Time schreef op vrijdag 2 november 2018 @ 07:57:
[...]

Nu op werk in Firefox doet 'ie het idd, maar gisteravond thuis met Otter dus niet, daar krijg ik deze melding:

[...]

Als ik dan kijk naar het certificaat, staat er dan ook ssl.cdngc.net bij Common Name. Daar zal Otter over vallen denk ik zo. En het is ook volkomen terecht dat er zo'n melding komt, wat de naam in het certificaat komt niet overeen met de site die ik bezoek. Alsof ik een certificaat voor Google krijg als ik Tweakers bezoek. Valideert allebei, maar niet voor de juiste site.

Ik ben geen expert in certificaten, maar ik zie assets.amuniversal.com wel staan bij 'Certificate Subject Alt Name'...

[Hero of Time]

Daar staat idd een hele waslijst met alt names. Die ik overigens niet zie met openssl -connect. Dan moet het daar fout gaan.

[ACM]

crisp schreef op vrijdag 2 november 2018 @ 08:07:
Ik ben geen expert in certificaten, maar ik zie assets.amuniversal.com wel staan bij 'Certificate Subject Alt Name'...

Sterker nog, dat is ook hoe het certificaat voor Tweakers werkt. Het domein gathering.tweakers.net zit ook in het certificaat geintegreerd van die van tweakers.net

[Raven]

ACM schreef op donderdag 1 november 2018 @ 22:24:
Daar zijn wmb de topicreports voor

offtopic:
Dan moeten die wel afgehandeld worden , ik heb er weer eens een paar her en der openstaan die nooit afgehandeld zullen worden omdat de topics inmiddels druk bezig zijn met wegzakken. Waaronder in SB...

[.oisyn]

ACM schreef op donderdag 1 november 2018 @ 22:24:
[...]

Sterker nog, hij ziet een https-url (zoals al eerder in dit topic gemeld) en vertrouwd erop dat dat klopt. Gaan we wmb ook niet fixen.

Het is in beginsel de verantwoordelijkheid van de gebruiker om afbeeldingen te linken die werken, maar doet ie dat met http; dan zetten wij dat om via onze https-proxy, de gebruiker heeft tenslotte niet altijd de keus om er https van te maken.

Het is niet ons doel om automatisch alle afbeeldingen te downloaden en te checken of e.e.a. ook echt werkt met https. Dat is bovendien onbetrouwbaar, want certificaten en protocollen verouderen/verlopen of kunnen in (specifieke) browsers uitgesloten worden. Dat zou dan betekenen dat we eigenlijk elke https-afbeelding steeds opnieuw zouden moeten controleren...

Wat mij betreft stoppen we ook met dit soort foutieve urls als 'bug' te beschouwen, het is uiteindelijk gewoon een onjuist geplaatste afbeelding. Daar zijn wmb de topicreports voor

Wacht even, zeg je nu dat de image checker van een post niet eerst HTTPS probeert als je linkt naar HTTP? Want dat doet ie dus wel. En dat is imho gewoon een bug als het plaatje niet voor iedereen standaard beschikbaar is via HTTPS.

.edit: oh wacht er was nog een pagina

crisp schreef op donderdag 1 november 2018 @ 23:46:
Omgekeerd: gaat het echt zo vaak nog fout dan?


[...]

Dat doen we serverside iig al

Ik zie het zo nu en dan gebeuren. Het probleem is dat de poster het niet opvalt, want bij hem werkt het gewoon, want die accepteert een fout certificaat.

Maar als je dat serverside al doet, waarom dan zo krampachtig volhouden proberen aan de clientkant al HTTPS te proberen?

[ Voor 18% gewijzigd door .oisyn op 27-11-2018 16:06 ]

[ACM]

.oisyn schreef op dinsdag 27 november 2018 @ 16:03:
Wacht even, zeg je nu dat de image checker van een post niet eerst HTTPS probeert als je linkt naar HTTP? Want dat doet ie dus wel. En dat is imho gewoon een bug als het plaatje niet voor iedereen standaard beschikbaar is via HTTPS.

Er zijn twee dingen relevant hierbij:
- Wat de gebruiker post, na eventuele javascript processing
- Wat de gebruiker invoert; dus voor eventuele javascript processing

Van de urls die met de POST-request meekomen gaan we bij https-urls ervanuit dat die werken. We gaan dus niet (steeds) testen meer of de https-urls wel valide zijn, geldige certificaten hebben, logins nodig hebben, etc. Dat is onbegonnen werk en een enorme verspilling van resources; en dan waarschijnlijk alsnog onbetrouwbaar op het moment dat bijvoorbeeld bij een client strengere ssl-validatie aanstaat of de https-versie anders blijkt te zijn dan de http-versie (maar wel beide images).

We testen trouwens ook niet of plaatjes met http-urls het wel doen, die zetten we blind om via onze image proxy.

Net voor submit wordt bij de plaatjes-check functie inderdaad nog voor iedere afbeelding gechecked of ie toevallig met https werkt en zoniet dan de http-versie gebruikt.

Ik zie het zo nu en dan gebeuren. Het probleem is dat de poster het niet opvalt, want bij hem werkt het gewoon, want die accepteert een fout certificaat.

Maar als je dat serverside al doet, waarom dan zo krampachtig volhouden proberen aan de clientkant al HTTPS te proberen?

Krampachtig? Zoals gezegd gaan we wmb geen resources verspillen aan server-side testen of afbeeldingsurls wel werken. En ook als we niet zelf afbeeldingen om zouden zetten naar https via de client side, zouden jouw scenario's ook misgaan als de gebruiker van die sites zelf https-linkjes neerzet. Dat hebben we tenslotte ook gezien met gebruikers die plaatjes plaatsten waar authenticatie voor nodig was...

Uiteindelijk hebben wij invulling gegeven aan de door gebruikers uitdrukkelijk uitgesproken wens om de site via HTTPS uit te serveren. Maar dat betekent wel dat er een paar randvoorwaarden zijn ontstaan; de resources - zoals door gebruikers geplaatste afbeeldingen - moeten via https.

Omdat dat laatste toen in ieder geval niet realistisch afgedwongen kon worden, hebben we twee dingen gedaan: pro-actief toch https proberen en als dat echt niet kan dan via onze eigen https-proxy.


Wellicht moeten we gewoon stoppen met die proxy en iedereen verplichten https-images toe te voegen? Want effectief ondersteunen we nu een gebruiksscenario dat buiten de wens van diezelfde gebruikers viel.
Deze laatste vraag is niet eens bedoeld als rant, maar een serieus vraag

[.oisyn]

ACM schreef op dinsdag 27 november 2018 @ 20:18:
[...]

Er zijn twee dingen relevant hierbij:

Niet echt. Voor jullie relevant, maar vanuit het oogpunt van de gebruiker totaal niet . Er telt maar 1 ding: wat hij in het formulier invoert. Wat er verder mee gebeurt ligt compleet binnen jullie controle. Je kunt de gebruiker niet de verantwoordelijkheid toewijzen voor wat het clientside controleerscript met de invoer doet.

We gaan dus niet (steeds) testen meer of de https-urls wel valide zijn

Waarom staat die "steeds" daar? Hij staat dan wel tussen haakjes, maar ik zie niet hoe het ooit van toepassing is. Er is maar 1 moment: op het moment dat het plaatje wordt toegevoegd aan een post.

Dat is onbegonnen werk en een enorme verspilling van resources;

Jullie doen het ook voor niet-https-plaatjes, wat nog veel meer resources kost (het plaatje moet daadwerkelijk gedownload en opgeslagen worden), dus eerlijk gezegd denk ik het mijne bij deze stelling . Meer resources dan nu idd, dat is zeker waar. En op een andere plek/moment (plaatjesproxy ipv forumpost).

en dan waarschijnlijk alsnog onbetrouwbaar op het moment dat bijvoorbeeld bij een client strengere ssl-validatie aanstaat of de https-versie anders blijkt te zijn dan de http-versie (maar wel beide images).

Valide argument. Misschien gewoon helemaal niet meer omzetten, dan? . Dat is uiteindelijk mijn voorstel: de clientside plaatjeschecker niet de test laten doen maar gewoon respecteren wat de gebruiker heeft ingevoerd.

De serverside check is dan alleen maar een optimalisatie om de proxy te verlichten (waardoor je uiteindelijk mínder resources gebruikt tov gewoon alles proxy'en wat http is)

Krampachtig? Zoals gezegd gaan we wmb geen resources verspillen aan server-side testen of afbeeldingsurls wel werken.

Dat vind ik kortzichtig. Er is meer data nodig natuurlijk, maar je moet de afweging maken hoeveel van de plaatjes uiteindelijk succesvol worden geconverteerd van tevoren. Er is een reden dat de gebruiker een http link pastete - zo is het plaatje hem geserveerd. Sites met goed werkende https hanteren in de regel sowieso al https URL's. En daarnaast hebben jullie naar eigen zeggen een whitelist van de grote plaatjesserveerders.

En ook als we niet zelf afbeeldingen om zouden zetten naar https via de client side, zouden jouw scenario's ook misgaan als de gebruiker van die sites zelf https-linkjes neerzet. Dat hebben we tenslotte ook gezien met gebruikers die plaatjes plaatsten waar authenticatie voor nodig was...

Don't make perfect the enemy of good enough. Ik constateer een probleem dat in principe oplosbaar is. Het kost idd niet álle problemen op, maar wel een groot deel. Of je tijd en resources wil spenderen aan die oplossing is uiteraard aan jullie .

Wellicht moeten we gewoon stoppen met die proxy en iedereen verplichten https-images toe te voegen? Want effectief ondersteunen we nu een gebruiksscenario dat buiten de wens van diezelfde gebruikers viel.
Deze laatste vraag is niet eens bedoeld als rant, maar een serieus vraag

Natuurlijk is dit wel een rant en totaal niet iets dat jullie willen .

[ Voor 3% gewijzigd door .oisyn op 27-11-2018 20:59 ]

[ACM]

.oisyn schreef op dinsdag 27 november 2018 @ 20:54:
Niet echt. Voor jullie relevant, maar vanuit het oogpunt van de gebruiker totaal niet

Het was relevant voor de opmerking die je maakte a.d.h.v. mijn eerdere antwoord.

Waarom staat die "steeds" daar? Hij staat dan wel tussen haakjes, maar ik zie niet hoe het ooit van toepassing is. Er is maar 1 moment: op het moment dat het plaatje wordt toegevoegd aan een post.

Omdat een plaatje dat nu werkt via https over een week een ingetrokken of verlopen certificaat kan hebben.
Bij http kan het natuurlijk ook gebeuren dat plaatjes niet werken, maar bovenop 404's en verdwijnende hosts komen er dus nog wat meer varianten bij waarom een host niet goed is. Ook problemen die je aanhaalt waar we 'nu' op zouden moeten checken.

Jullie doen het ook voor niet-https-plaatjes, wat nog veel meer resources kost (het plaatje moet daadwerkelijk gedownload en opgeslagen worden), dus eerlijk gezegd denk ik het mijne bij deze stelling . Meer resources dan nu idd, dat is zeker waar.

Nee dat doen we niet. Met checken bedoel ik specifiek een plaatje server-side downloaden, controleren wat de response was en als die niet werkte dan nog via http proberen. Dat vraagt om problemen die waarschijnlijk ook de nodige hoeveelheid false positives geeft, juist bij hosts die sowieso hun https niet lekker hebben geconfigureerd (of net als wij clients redelijk streng behandelen).
Bovendien is het dan alsnog 'achteraf', zonder dat de gebruiker daar wat van merkt.

Dat vind ik kortzichtig. Er is meer data nodig natuurlijk, maar je moet de afweging maken hoeveel van de plaatjes uiteindelijk succesvol worden geconverteerd van tevoren. Er is een reden dat de gebruiker een http link paste - zo is het plaatje hem geserveerd. Sites met goed werkende https hanteren in de regel sowieso al https URL's.

Er is nog veel te veel fout geconfigureerde https waarbij plaatjes niet werden gedirect terwijl er ook gewoon een https versie van was. Maar zonder data kunnen we beide eigenlijk alleen op inschattingen reageren

En daarnaast hebben jullie naar eigen zeggen een whitelist van de grote plaatjesserveerders.

Alleen van de grote. Wat dus een aardige lange long-tail van allerlei andere hosts geeft.

Natuurlijk is dit wel een rant en totaal niet iets dat jullie willen .

Het is vooral een verzuchting dat de wens tot https zoveel gedoe blijft opleveren. Bij een poging om gebruikers te helpen bij wat theoretisch gezien ongewenste input is (http-links) lijkt niet goed te doen.

• "Foute" urls, met http, laten staan en niet proxyen levert mixed content op
• De urls blind laten staan zorgt voor een zwaardere belasting van onze proxies (ik heb geen cijfers voor hoeveel). En die proxy is ook niet perfect, waardoor die imperfecties meer zichtbaar worden.
• Zoveel mogelijk alvast omzetten naar https (wat we nu doen) geeft de hier benoemde problemen
• Dat verplaatsten naar server-side geeft waarschijnlijk allerlei andere nieuwe problemen en waarschijnlijk ook daarnaast een deel van dezelfde die we nu hebben

De http-urls als invalid input hanteren is daarom een eenvoudige oplossing voor de meeste problemen, maar geen gebruiksvriendelijke (wat dus weer een nieuw probleem geeft).

Ik heb ook een beetje de angst dat uberhaupt die plaatjes controleren als ze op http staan op den duur niet meer goed gaat werken - dus met name de afmetingcheck niet meer - door mixed content issues. Dat zou dan een extra reden zijn om toch eerst de https-versie even te proberen. Tenzij natuurlijk dat 'controleer mijn plaatjes' uberhaupt ongewenst is?

[.oisyn]

Ik kan me on veel van de punten die je noemt wel vinden, hoor. Wat betreft de laatste vraag, wmb is de afmetingchecker wel gewenst, en je kunt 'm altijd nog uitzetten indien nodig.

[ACM]

We gaan dit voorlopig niet veranderen, maar wellicht wordt het relevant ivm de interpretatie van de AVG door de AP