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?
-
2I 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. – sarnold Sep 29 '15 at 21:45
-
2You can't (without compromising the very purpose of NoScript.) What makes you believe every *.cloudfront.net link is guaranteed to be safe? – arkon Feb 10 '16 at 11:45
3 Answers
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.
-
6Do 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. – sarnold Sep 29 '15 at 21:44
-
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. – DanielM Sep 29 '15 at 22:52
-
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. – sarnold Sep 30 '15 at 22:51
-
1If 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. – DanielM Oct 01 '15 at 10:18
-
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! – sarnold Oct 06 '15 at 17:49
-
@DanielM *"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. – arkon Feb 10 '16 at 11:40
-
1@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. – DanielM Feb 10 '16 at 11:57
-
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. – Kaypro II Apr 12 '16 at 16:53
-
@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. – DanielM Apr 12 '16 at 16:58
-
6_"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. – nh2 Jun 21 '19 at 19:00
Add these addresses to the Noscript whitelist to allow CloudFront scripts globally:
cloudfront.net
amazonaws.com

- 3,100
- 7
- 25
- 37
-
1Where to find this whitelist in Firefox 57+? It seems that the old NoScript configuration window is gone. – nh2 Jun 21 '19 at 18:59
-
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.

- 33
- 9
-
1What did you put in? `"§:cloudfront.net",` doens't seem to have the desired effect of allowing all `*.cloudfront.net` CloudFront subdomains. – nh2 Jun 21 '19 at 18:58