Loc.alize.us bookmarklet blocked

[pigreco314]

Hello,
I've been using extensively the bookmarklet created by aemkei to geotag photos on Flickr which pops up a map where one can select the location of the photo shoot.
I had no problem using it for years in combination with NoScript after giving proper authorizations to the site involved (essentially flickr.com,github.com,sumaato.net and googleapis.com).

Since I installed Firefox 6.0, the bookmarklet does not work anymore: the map does not show up when clicking the bookmark, no error message is displayed. Basically nothing happens.
I didn't try with Firefox 5 but I'm positive it did work with Firefox 4.x
The only way to make it work again is to disable the NoScript plugin completely as not even allowing scripts globally works and neither option is acceptable for me.

When NoScript is enabled, the FF console shows a messages marked as informative (neither as error nor warning):
[NoScript] Blocking nosniff Javascript served from https://raw.github.com/ubilabs/flickr_g ... er/main.js with wrong type info text/plain, inline and included by http://www.flickr.com/photos/seaan/5655 ... otostream/

I'm using NoScript 2.1.2.7rc2

The bookmarklet (code below) invokes a script stored on the remote server.

Does this ring a bell to anyone?

Thanks in advance
Pi314

Code: Select all

javascript:(function(){
if(window.geocoding_bookmarklet){geocoding_bookmarklet.reload();return;}
var script=document.createElement("script");
script.src="http://github.com/ubilabs/flickr_geocoding_bookmarklet/raw/master/main.js?" + Math.random();
document.body.appendChild(script);})();

[pigreco314]

Hi,
me again from the STFF department (search the F* Forum first).

This is a problem similar to this and can be solved by adding "https://raw.github.com/ubilabs/flickr_g ... er/main.js" to NoScript preference noscript.inclusionTypeChecking.exceptions

Sorry for the waste of bandwidth,storage and time.

Follow up question though: what are the risks involved in adding this kind of exceptions?

Thanks
Cheers
Pi314

[al_9x]

Follow up question though: what are the risks involved in adding this kind of exceptions?

An exception for a specific script shouldn't be a risk, however, you wouldn't want an exception for all of github. The problem is that all github user content, that can't be implicitly trusted, is served from the same 2nd level domain as github code, and the only thing stands in the way of it executing is the inclusion mime enforcement.

If one didn't want to depend on the github server (raw.github.com) serving the right headers, one could mark raw.github.com untrusted, or leave it implicitly allowed but use ABE to restrict access to specific scripts on raw.github.com and from specific origins.