Will try to get this fixed next week.

Filed RT ticket 657 with Ops to get a secure geoip lookup. Once that is done, fixing it in CentralNotice will be trivial.

m wrote:

Thanks for the quick reaction! Do you have a link to that ticket?

RT tickets are private/secret I believe (for some reason I don't entirely understand)

(In reply to comment #4)

RT tickets are private/secret I believe (for some reason I don't entirely
understand)

They are restricted, yeah. I believe it's because of vendor info and such.

Ryan has this scheduled for completion before the annual fundraiser.

Regardless of when it is scheduled to be fixed, it shouldn't be marked as low priority, IMO. The bug effects everyone using the secure site, regardless of whether there is a fundraiser going on or not. GeoIpLookups are currently done on every page view, even if no banners are running on the wiki. So this bug basically means that our secure site isn't actually secure. I've gotten lots of complaints about this issue from the community, so it should probably retain a high priority.

If it's not likely that we'll have HTTPS geoiplookups for at least a few months, perhaps I should just turn off geoiplookup on the secure site in the meantime. Thoughts?

Ryan is busy at the moment, but suggested there might be a quickish way to fix this.

The ideal fix is sorting the secure system once and for all, which the ops guys were suggesting as the mucho preferred option

Is geoip lookup being used for anything right now?

At the moment there are no CentralNotice campaigns running at all (which is a somewhat rare situation). There are some wiki-specific scripts that piggyback on the geoiplookup to do various types of "geonotices", but I'm not sure if any of those are running anything currently. So the short answer to your question is "Probably, but not for anything important." Thus my suggestion to turn it off completely for the secure site.

ayg wrote:

In Chrome 14 dev, when visiting https://test.wikipedia.org/, I receive a message bar at the top of every page: "Insecure script has been blocked." There's a button that says "Load anyway (not recommended)". So users of Chrome are going to be getting a warning on every page, and the script won't work for them. Seems like it should be a blocker for broader HTTPS deployment. (I don't know if non-dev channels have the warning, but if they don't, they presumably will within a matter of weeks.)

• This bug has been marked as a duplicate of bug 30735 ***