HTTPS Everywhere

This is possibly a 'their problem, they need to fix it' thing but I thought I'd post it here so you're aware of it (and anyone else who gets these symptoms and comes to report it can see there is a workaround).

EFF's HTTPS-Everywhere was updated 2 days ago (version/date 2012.6.18) and has added a new rule called Whiskey Media (partial). This rule breaks the GB site (when it detects the url) and so the site fails to load some images (very visible as it is things like the background gradient (top of white theme) and little arrows for the drop-down menus and word bubble icon for the comments etc).

This is in Chrome 19 (current) with the above mentioned extension (on Win7x64 with current updates but I don't think that's relevant).

Hope the following is enough detail for the top men to replicate this (as I said, not sure if there's something you can do at your end or if EFF need to be contacted about their new rule and how it doesn't work). Not sure how widespread use of HTTPS-E beta for Chrome is but it took me a few minutes to pin down exactly what has gone wrong when GB suddenly stopped working perfectly.

Replicate:

Open Chrome 19, load giantbomb.com and everything is fine.

Install current HTTPS-Everywhere plugin (6.18) and ctrl-shift-reload (to ensure cache is flushed and loads are from server) giantbomb.com. Several broken image icons on page. Look at plugin details for page and Whiskey Media (partial match) rule is listed and enabled by default.

Disable HTTPS-Everywhere plugin and ctrl-shift-reload, page is back to looking correct.

Uninstall HTTPS-Everywhere and install previous version (5.1) and ctrl-shift-reload, page is still looking correct. Look at plugin details for page and no Whiskey Media rule listed. This seems to be giving a clear indication of what has changed.

Workaround:

For users who are having this issue the workaround is to disable the rule (click blue HTTPS-E icon right side of address bar in Chrome and deselect the Whiskey Media (partial) rule). This will require a ctrl-shift-reload as the browser cache will likely (at least for me) keep the cache of the broken 'securified' links (image links fed in via css and so cached? I only gave the page source a very quick glance) to images not there. After this forced refresh the rule will stay off and pages should all look perfect and white theme top is readable again as it has the gradient image.

Here's the ruleset for Whiskey Media. I've tested the rule by manually modifying the URLs of a few images and they all worked. Hopefully someone else can take a look at the ruleset and see if there's anything in there that could cause the issue you're having.

@LordAndrew: Which images? The ones that break (the little arrows by the dropdown menus at the top or by the selected menu item in the left menu, the icon by the words in the position below a video like the blue comments bubble icon) are generated by the CSS, the html source for the page does not directly reference them.

One example (where a lot of the icons come from, I can't work out where the menu arrows come from for some reason - Chrome inspector isn't giving me any hints with the computed style for those elements) http://media.giantbomb.com/static/vine/img/generic/icn_sprite2.png which should be rewritten to...

https://s3.amazonaws.com/media.giantbomb.com/static/vine/img/generic/icn_sprite2.png which also exists so the rule shouldn't break it, unless HTTPS Everywhere + images loaded via their CSS is a touch dodgy.

Were you able to replicate my issue on your computer following those steps?

Thank you very much for figuring this out. I knew as soon as I saw this topic in the list that the image problem was https everywhere. Thanks again.

I wondered what happened to all the images, the HTTPS Everywhere 'Whiskey Media' rule was indeed the problem.

I am unfortunately unable to test this with Chrome and HTTPS Everywhere, otherwise I would have. Manually testing the rule against images is the best I could do.

Since the missing images do seem to exist at the location HTTPS Everywhere should be looking for them, it looks like it's a bug in HTTPS Everywhere. Can you test this rule with the Firefox version of HTTS Everywhere? Perhaps it's a Chrome-only issue.

@LordAndrew said:

Can you test this rule with the Firefox version of HTTS Everywhere? Perhaps it's a Chrome-only issue.

I use this add-on for Firefox and have not noticed the issue.