Page MenuHomePhabricator

General-purpose HTTPS-friendly GeoIP solution
Closed, ResolvedPublic


Bug 40714 was invalid, but I think this is a valid request although a low priority one: if the browser doesn't allow to load unsecure resources, the GeoIP lookup to should be skipped or anyway the behaviour should degrade gracefully (or more gracefully than it currently does).
Of course chasing browsers is not an option but maybe someone will come up with a smart solution. The linked thread mentions HTTP 304 Not Modified responses which might give some some clue to ULS maybe?

Version: master
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:14 AM
bzimport set Reference to bz40965.

ULS is degrading gracefully. There is nothing we can do to support https in ULS unless someone sets up https service. We could just not make the requests at all when using https.

You are on an untrusted network, so you only login in https, but as the wiki then loads in http, the attacker replaces the answer and runs arbitrary javascript in your browser...

External services are a security risk regardless of whether it is http or https.

FYI: This request is blocked in Google Chrome by default when browsing translatewiki over HTTPS (as it should).

External services are a security risk regardless of whether it is http or

Yes, but being in http additionally means it is also open to main-in-the-middle, attacks so it disables the https security (for an active attacker).

Related URL: (Gerrit Change Ia18130890d09f86a93b5b61f7da7c48fcfa480c7)