Allow Cloudfront Globally on NoScript

Question

So Amazon's Cloudfront CDN is ubiquitous, and as a NoScript user, it can be a little frustrating having to allow every "########.cloudfront.net" on different sites. Does anyone now how to create an ABE rule in NoScript to allow any script coming from a *.cloudfront.net domain?

Cowgirl

I wish you hadn't accepted SMG 1991's answer; it doesn't actually answer the question you asked but because this is "answered", has potentially deterred people from answering it. Thanks. – Ladonna

You can't (without compromising the very purpose of NoScript.) What makes you believe every *.cloudfront.net link is guaranteed to be safe? – Lorin

Answer 1

Add these addresses to the Noscript whitelist to allow CloudFront scripts globally:

cloudfront.net
amazonaws.com

Sandie

Where to find this whitelist in Firefox 57+? It seems that the old NoScript configuration window is gone. – Stanford

the webext version of NS doesn't have this option – Codee

Answer 2

While the answer by @samadadi is correct and will allow you to universally accept content from cloudfront, you might want to consider why you're running No Script in the first place.

Cloud Front is a Content Delivery Network that anyone can use, even "the bad guys". If you allow JavaScript downloaded from there to be run, then you are circumventing the protection NoScript offers. If you want to remain safe, I would recommend staying with allowing it on a site by site basis.

This might be an unpopular option because, yes, it is more work, but you will be safer.

Update (just to save people reading the comments below): CloudFront sub domains, while looking random, remain the same between visits. Permanently allowing cloudfront subdomains from sites you trust should be safe, and will only ask you once.

Caro

Do you know how to address the original question? I'd like to allow *.cloudfront.net access whenever I visit trello.com. Trello is 100% useless without it and I always have to give temporary permissions to the randomly generated cloudfront names. I wish to automate these three clicks. Thanks. – Ladonna

Are you sure the CF subdomains are regenerated each visit? Doesn't perma allowing them (rather than temp) fix the problem? I assumed the subdomains just hid owner association but I could be wrong. – Caro

I very rarely use "Revoke temporary permissions"; it seems most sites that use CF servers have new hostnames every single visit. The FAQ for noscript mentions something similar with akamai but I couldn't get the example ABE to work for trello and cloudfront -- it actually made the situation worse, as there's a new "Couldn't load resources" message from trello in the browser. – Ladonna

If you only temporarily allow scripts, then they shouldn't shouldn't still be allowed on your next visit. The documentation is a little hazy but it describes them as being allowed for the current "session". Of course, that can mean a lot of things. If you visit the page a lot, and you don't want to re-auth the scripts, you have to permanently allow them. I've just opened trello in two different browsers and both are trying to use d2k1ftgv7pobq7.cloudfront.net and d78fikflryjgj.cloudfront.net suggesting these do not change between sessions. – Caro

Thanks for the kick, Daniel. I hadn't realized that "temporarily allow" is as short as it really is. I just got d78fikflryjgj on a new visit. I had figured they were always new because I keep that tab open all the time (one of several hundred...) and figured that'd be sufficient to keep the temporary authorization. Thanks! – Ladonna

@Caro "The documentation is a little hazy but it describes them as being allowed for the current "session"." It's really quite clear. A session lasts until firefox is closed. I.e. granting temporary permissions is persistent until either firefox is closed or the user explicity revokes the temporary permissions. So you're incorrect in saying it shouldn't be allowed on your next visit. Because it should, unless you've closed firefox or revoked the permissions. – Lorin

@b1nary.atr0phy You are probably correct however as I said 'current "session" [...] can mean a lot of different things" and the documentation is a "little hazy" in that it doesn't explicitly say whether it means in terms of the browser application or the website. Even in the case of the browser, is a private browsing window considered a seperate session. I was just pointing out I could say for certain what the behaviour would be. – Caro

Is there any way to determine which ##########.cloudfront.com domain is associated with which site to allow/block them individually (often a site will have multiple)? If you can't do that, you might as well allow them all, since you can't actually make an individual decision. – Gazzo

@kaypro-ii There usually are multiple, and more than one might be required to use the site. You can unblock them one at a time and see what happens (not particularly difficult, just annoying if you do it every time), or you can unblock the lot. However, as I said above, you ought to consider why you're bothering running it in the first place if you're going to do that. Personally I no longer run NoScript, I rely on uBlock Origin and disable Java and Flash in the browser. I feel just as safe, whether I am or not... no idea. – Caro

"remain the same between visits" -- this isn't really true for many websites. For example, console.aws.amazon.com changes its CloudFront URLs pretty much daily. – Stanford

Answer 3

To allow *.cloudfront.net, I checked the debug button, and touched up the JSON as suggested here: https://www.dedoimedo.com/computers/firefox-noscript-10-guide-1.html. Let me know if yo have trouble doing this and I will walk you through it.

Mcgee

What did you put in? "§:cloudfront.net", doens't seem to have the desired effect of allowing all *.cloudfront.net CloudFront subdomains. – Stanford