I've done some more digging and come up with more questions than answers.
Firstly on the API, most assets are served with relative links: So that raises the unpleasant prospect that the mobile app has been defaulting to HTTP and requesting assets over insecure connections. But I've been through the codebase, and wherever a scheme and domain is missing, the app is hardcoded to assume HTTPS. E.g. attachments, profile avatars.
The app should never request anything over HTTP, and indeed, I just ran the app in dev mode, logging all image requests and there were no requests for LFGSS assets over HTTP. So I really can't explain how you're seeing a request from dart, over an insecure connections. Do you know why the logs mention an SSL cipher and protocol, despite the request being over HTTP? Incidentally, I've never seen a Host header include the scheme. That's pretty unusual.
The problem could have been masked by HSTS - (the website serving http:// links, but chrome silently swapping them with https://), but it's not that. The website is serving attachments with absolute URLs:
I've done some more digging and come up with more questions than answers.
Firstly on the API, most assets are served with relative links: So that raises the unpleasant prospect that the mobile app has been defaulting to HTTP and requesting assets over insecure connections. But I've been through the codebase, and wherever a scheme and domain is missing, the app is hardcoded to assume HTTPS. E.g. attachments, profile avatars.
The app should never request anything over HTTP, and indeed, I just ran the app in dev mode, logging all image requests and there were no requests for LFGSS assets over HTTP. So I really can't explain how you're seeing a request from dart, over an insecure connections. Do you know why the logs mention an SSL cipher and protocol, despite the request being over HTTP? Incidentally, I've never seen a Host header include the scheme. That's pretty unusual.
The problem could have been masked by HSTS - (the website serving http:// links, but chrome silently swapping them with https://), but it's not that. The website is serving attachments with absolute URLs:
On the link shortener:
The api seems to be serving HTTP links:
But the same comment via the web is magically HTTPS: