Guide | External JS resources and a guide to safer browsing...

[Morg42]

External JS resources and a guide to safer browsing...

As an offspin of a discussion about safe browsing I decided to put this posting here, so maybe others might also profit of it.

One of the reasons for this posting is the following article: Harvesting credit card numbers and passwords from your site
(tl;dr: it's easy to insert malicious JS code into almost any site which uses JS frameworks)
Just to make sure everyone got the scope of the article: this was fictional, but it is very real. And you can not defend yourself against it.

Or can you? I'm hopelessly optimistic, so I don't want to play along with fatalistic "you can't do anything". Let's see what we _can do.

---

First and foremost, nowadays JS is the single most important and prevalent incident vector for malware, tracking and phishing.

So, turn off JS, that's easy. Vivaldi has an option for it, I'm sure, I saw it.

Right, that's a possible way - but you won't last long in today's internet, methinks. Most sites include JS today, many for good reasons. And also many sites don't work without JS at all - while some work quite well without JS or at least with a minimal amount of JS.

And talking about ads or trackers, almost all of these don't work without JS anymore.

Got your attention? Keep reading...

---

One of the concepts this will be about are external resources. Most know these for example as images, stylesheets or - actually - JS files. They can be loaded from the same server the main website resides on (e.g. http://host.domain/style.css for http://host.domain/page.html) - or they can be loaded from 3rd party servers (a popular example with regard to the article at the beginning might be jQuery, which commonly is included from http://ajax.googleapis.com).

The main difference is that the first type of external resource is hosted by the same one who hosts the website - and the second one is (possibly) hosted by someone else. Important fact: this often means that the website owner does not have any control about what is delivered to the web browser (this is one of the key aspects of the article linked at the top).

So, maybe we can get away with restraining our beloved V to "first party resources"?

Actually, we can. Let's see how.

---

I strongly recomment using uBlock Origin and ScriptBlock, although the former might be replaced by uMatrix and the second (for example) by ScriptSafe. Try what you like best - the following will mainly deal with uBlock Origin.

I won't go into setting up uBlock Origin (UO) and choosing your filter lists. It comes with an impressive selection of lists where most users should be able to find appropriate inputs. Out of my personal experience, you can't really overdo it and choose too many lists. From some point on most lists start overlapping, and I haven't seen V get too slow by filtering your web requests.

Do activate the "I am an experienced user" option in UO options, though - we will need it.

If you installed a JS blocker (ScriptBlock), keep it in "block" mode for starters, if you want to go along with the guide.

---

As a first example, I'll use the website of The Guardian, just because it came up in the discussion and at least some people have seen it. Furthermore, it proves as a good example - you'll see why.

This is what the site looks like with no filtering and only JS blocked:

If you open the popup of UO, you can extend the options by clicking on one of the horizontal grey dividers:

Then the detailed list of resources pops out. Here we have rows of domains and hosts which are accessed by the website and (basically) two columns. The left column (with the red/gray/green marker) is for global access without regard to the currently active website; the right column is for "local" access, that is access by the active website. (I'll explain these immediately).

And this is the list of resources used by the page:

You can see that a lot of domains and external resources is loaded by the current page. Remember that we want to minimize JS?

For this, I'll try to explain the access model of UO. This might sound complicated, but I try to show everything in images

UO has three modes of access:

• deny access (red)
• allow access (green)
• don't care, called "no op" (grey)

These can apply to all websites (global access, see above) or only to the current page (local access) by clicking on the appropriate box (which gets coloured): (sadly the mouse pointer isn't visible - it's over the "deny" box left of the lightning symbol)

Global access modes can be "inherited" - if a setting is "deny" for global access, it will initially also be "deny" for local access. To indicate it's inherited, the marker is light red (or light green/grey for allow and no op):

Local settings will overwrite global settings (or invalidate allow/deny if the local action is "no op"):

So, let's start with disabling

• inline scripts (which are embedded in the HTML source of the active page)
• 3rd party script (which are loaded from foreign servers)
• 3rd party resources (e.g. images loaded from foreign servers)

For this, enable "global deny" for the mentioned items:

If you reload the page, you'll notice that a lot of sites are not accessed anymore (the list got shorter, e.g. doubleclick vanished...):

Some of the vanished resources we want to stay away - for example doubleclick, an ad network. This was included via inline JS (which ScriptBlock sometimes seems not to block). As inline JS now is forbidden, the website doesn't even bother to load ad networks anymore. Hooray!

But sadly, the images went away, so we want to enable images. An educated guess lets me reenable "guardian images" on guim.co.uk (watch how the host entries below guim.co.uk (assets.guim.co.uk, i.guim.co.uk, interactive.guim.co.uk) inherit the "allow" policy:

Now, if you really don't need anything else, this is it. Compare the list of loaded resources to the one at the beginning of this guide and - just for fun - to the one you get if all JS blocking is turned off:

Isn't this scary?

---

So you might keep JS blocking on as long as everything works. If something doesn't work, try the following steps one by one:

• look for CDN entries in the domain list and enable selectively (this mostly resolves issues of images not loading or missing stylesheets messing up the page)

If this doesn't help (maybe you actually need JS?)

• enable JS for the site in the JS blocker (remember: UO will still block most JS anyway)
• enable inline script in UO for the site
• try to find if external scripts might be needed (e.g. ajax.googleapis.com, jQuery entries, maps.google.com, YouTube or similar)

If nothing else works, you can always disable UO for the current website. Just know what you do.

---

If you found settings you are content with, you can make these permanent (save them) by clicking on the grey lock in the UO dialog:

---

Congratulations - you successfully set up your V to be more safe.

But, as alway, there's no thing as a free beer...

this WILL DEFINITELY make your browsing a bit more of a hassle and rob you of a bit of comfort... but it will almost definitely make your browsing a lot safer, as long as you don't enable everything anywhere because it's easier...

---

Afterthought:

I am aware that ScriptBlock does not (properly) block inline scripts. As I use UO anyway (which does block inline JS), I don't care about this gap. And as ScriptBlock exactly looks like the extension I've been using on Olde Opera for years, I'm not going to change it (although I tried out ScriptSafe...). Just saying...

--
ModEdit: Title

[luetage]

This is informative, good explanation. One question: Why are you using scriptblock additionally?

[Steffie]

Magnificent work @Morg42 -- ta muchly!

[Steffie]

The "1st-party scripts" D/F setting is not mentioned specifically herein, nor in https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-quick-guide . What are they, & is there any particular good-practice management policy for them pls?

[Morg42]

@luetage
For two reasons.

First - nostalgy. Have been using it (and its predecessor on Olde Opera) for so many years now...

Second - for a practical use. On some sites I use (example: lawblog.de ) I don't need any external resources, so ScriptBlock more or less kills all those for me.
If I want to read the comments (provided by disqus, which I don't like having active), I enable JS in ScriptBlock. But then I still only like to enable those items absolutely needed. So my "config" for disqus is set in UO, but only gets active if JS is enabled in ScriptBlock. Similar variants of "reduced website to read" / "lesser reduced website to work with" are existent in my configuration.

So I use ScriptBlock as a kind of "master switch" for most of those websites. Besides, it provides me with a quick feedback on the JS status (which UO doesn't on its extension icon).

Is it necessary? No. You can do all your blocking with UO, and I guess it won't really be more work.

[Morg42]

@purgatori said in External JS resources and a guide to safer browsing...:

To block first-party scripts by default in UBO would require adding * * 1p-script block to 'My Rules'.

Or just click on the global "deny" field for 1st party scripts in the dialog I find this method easier, especially for those not versed in text-based configuration.

But you are right, of course.

And in my example I didn't block it in UO as I used ScriptBlock for that (see above).

[Steffie]

Hello. I spent the bulk of yesterday continuing my uO dynamic filtering rules experimentation, learning, & settings' finessing. I think i must be bonkers for expending so much time on it, but hey, the alternative is Real Life, & that just wouldn't do.

Current Generic status [continuing the GA example for valid reference]:

#########################################
EDIT: UPDATE: No further GA uO finessing needed after all; closing & relaunching V-SS made the site & uO play nice again... but i remain a bit concerned that something clearly went temporarily bad.
#########################################

Current dynamic filtering rules list:

no-csp-reports: * true
* * 3p block
* * 3p-frame block
* * 3p-script block
* * inline-script block
* facebook.com * block
* facebook.net * block
* googletagservices.com * block
au.tv.yahoo.com brightcove.com * noop
au.tv.yahoo.com brightcove.net * noop
au.tv.yahoo.com yimg.com * noop
behind-the-scene * 3p noop
behind-the-scene * 3p-frame noop
duckduckgo.com duckduckgo.com * noop
en.wikipedia.org wikimedia.org * noop
firejail.wordpress.com wp.com * noop
forum.vivaldi.net vivaldi.com * noop
forum.vivaldi.net vivaldi.net * noop
global.americanexpress.com aexp-static.com * noop
ibs.bankwest.com.au serving-sys.com * noop
iview.abc.net.au abc.net.au * noop
iview.abc.net.au akamaihd.net * noop
iview.abc.net.au edgesuite.net * noop
iview.abc.net.au jwpcdn.com * noop
iview.abc.net.au oztam.com.au * noop
iviewsupport.abc.net.au * 3p noop
linux.slashdot.org fsdn.com * noop
profile.theguardian.com guardianapps.co.uk * noop
profile.theguardian.com guim.co.uk * noop
radio.abc.net.au * 3p-script noop
radio.abc.net.au abcradio.net.au * noop
radio.abc.net.au akamaihd.net * noop
theblueroom.bupa.com.au typography.com * noop
thenewdaily.com.au netdna-ssl.com * noop
thenewdaily.com.au youtube.com * noop
theninthwatch.com googlevideo.com * noop
theninthwatch.com youtube.com * noop
vivaldi.com vivaldi.net * noop
www.finder.com.au * 3p noop
www.finder.com.au * 3p-script noop
www.finder.com.au gstatic.com * noop
www.netflix.com netflix.com * allow
www.netflix.com nflxext.com * noop
www.netflix.com nflxvideo.net * noop
www.scamvoid.com bootstrapcdn.com * noop
www.smh.com.au akamaihd.net * noop
www.smh.com.au brightcove.com * noop
www.smh.com.au brightcove.net * noop
www.smh.com.au fairfaxstatic.com.au * noop
www.speedtest.net activ8me.net.au * noop
www.speedtest.net cdnst.net * noop
www.techrepublic.com * 3p-script noop
www.techrepublic.com akamaized.net * noop
www.techrepublic.com cbsistatic.com * noop
www.techrepublic.com google.com * block
www.theguardian.com guardianapps.co.uk * noop
www.theguardian.com guim.co.uk * noop
www.theguardian.com youtube.com * noop
www.timeanddate.com tadst.com * noop
www.woolworths.com.au woolworths.media * noop
www.youtube.com ggpht.com * block
www.youtube.com googlevideo.com * noop
www.youtube.com gstatic.com * block
www.youtube.com ytimg.com * noop

Thankfully there were many of my other regular sites that did not break even with the toughened global rules, but for those above i had to do finessing as in some case they were otherwise completely broken, in other cases partly broken. I seem to have evolved a little workflow sequence to efficiently "process" each site now.

Today, in between parallel pleasures like hitting my head with a brick & sticking rusty needles under my fingernails, i intend to begin experimenting with the "1st-party scripts" setting [as i said -- bonkers!].

I've used uO for many years [long predating V], but until now pretty much only as an ad blocker. With the wonderful help here i've learned a lot of cool new stuff about really extending the innate power of uO, & i am very grateful for this kind assistance.

[Steffie]

@steffie said in External JS resources and a guide to safer browsing...:

Today, in between parallel pleasures like hitting my head with a brick & sticking rusty needles under my fingernails, i intend to begin experimenting with the "1st-party scripts" setting [as i said -- bonkers!].

Posting this several hours later. I've abandoned this "final frontier" for uO. It broke as near as damnit every site i tried it on [not really surprising, i suppose]. Whilst on all the sites i did test it on [~dozen'ish] i was then able to unbreak them again by further finessing the uO filtering, i suddenly realised that this is pretty pointless. I reverted to the file copy i made this morning of the settings, & now feel pretty pleased that this is a good working balance. This uO extension really is a pretty amazing piece of work.

[Morg42]

@Steffie: As I said, denying the "last" js frontier (1st party) is prone to break most current sites, if you expect some interaction. As long as I only read news (for example), this works quite well on most sites. And I find it easier to quickly toggle js on/off via the ScriptBlock icon than to open the oU popup and try to hit the small 1st party js local allow block..

@purgatori: What I massively notices by blocking js in general (ignorant of any finessed 3rd party and external js blocking, just "off") is that the experience of browsing the web has massively sped up. No js frameworks to load, no tracking scripts to load, and not a ton of additional resources every 3rd party script wants to pull in afterwards.
Aside from the speed, I still hold to on of my first statements: almost every not-user-intended function on the web (tracking, phishing, ads, ....) is absolutely depending on JS.
While I can't with a clear conscience recommend total or almost-total js blocking because of the hassle it definitely will bring, I found that surfing with (generally) deactivated/blocked js works fine for me and I enjoy the relative safety. tbh, the relative (!) privacy is even more important to me, but nowadays, the one mostly comes with the other.

And as someone often uses his mobile data plan for surfing via mobile hotspot, I really relish the much lower data volume requirements

[luetage]

@morg42 For sites you only want to read on blocking js is fine. Even if you are only presented with pure html, you can likely use Vivaldi's built in reader mode to your advantage.

However, javascript is simply a main building block of the web. If you want to do anything else but to read articles, you will need it. And it has to be said ublock handles trackers quite well with its filter lists, Most third party domains don't connect in the first place.

[Morg42]

@luetage: Of course you're right (and basically, I've said the same). But I found that - for me! - many sites "work" well enough without JS. This doesn't rule out many websites I know and use with proper JS permissions also...

@Steffie: Absolutely. And still - while intended fictional - the malicious code in the article referenced at the beginning of this thread is included by you 1st party webserver and served as 1st party JS code with all proper granted rights. This is why the concept in the article is scary. Blocking any 3rd party crap is (mostly) no big deal.

[derDay]

great guide!

[Morg42]

Thank you

[LonM]

A proof of concept for tracking via CSS only: https://github.com/jbtronics/CrookedStyleSheets

It isn't as detailed as tracking done by JS, but still yet another attack surface to consider and protect against.

[Steffie]

@lonm Oh nooooooooooooooooo, i'm feeling exhausted...

[Morg42]

And that won't be the last. Luckily (?), CSS stylesheets are included in "3rd party resources" blocking, if activated.

Find your own balance between "this is a hassle", "this website barely works", "wow, everything works and blinks" and "I'm feeling lucky today".

Mostly, the old adage holds that you can't get security and comfort at the same time. I only described one way, there are others. Which one will be yours, we can't say (and probably, as of now, so can't you )

But don't despair.

[Dantesoft]

For now, the built-in way of disabling Javascript (that is, disabling at the website domain level) doesn’t sound like a good idea to me, as this also disables any extensions that might offer some privacy protections.
You’re right @Morg42, I must have done something wrong, the extensions work fine with webpage Javascript disabled.

[Morg42]

Extensions are not affected by JS disable/block or filtering decisions. That would be quite counterproductive as well...

Do you experience problems with extensions when disabling JS?

[Blackbird]

As long as the browser feeds back upon demand any platform-specific or usage-specific data to a website, there will be the potential for a site's manipulation of that feedback mechanism to generate some form of user-tracking ID. Unless the sites are to be static and simple, feedback about the capabilities of the visiting system and the details of user interaction is essential to modern website design. Some degree of user tracking via a generated ID based on that feedback will thus always be made possible.

One key to a user's minimizing of this tracking is to weaken the usefulness of any created ID itself, both by forcing the site to use tracking techniques that are poorer in detail to start with and by breaking continuity of a tracking ID over time. The more active and capable the scripting language permitted a website by the browser, the richer the possible detail (hence, the uniqueness) of a created tracking ID. In this regard, JavaScript is more 'capable' than CSS, for example. Unfortunately, the reliance upon scriptings by websites means script blocking will usually have some degree of negative impact on how the site appears and functions in the browser.

If a tracking ID generated in one site visit is somehow preserved and made available later in time or to another website, the tracking usefulness of that ID is increased. Moreover, if subsequent visits to the original site or to cooperating sites result in increased data detail that can be appended to the originally-created ID, that ID then becomes even more unique over time. Things like cookies, local-stored site data, and evercookies can be used for storing tracking IDs for later access and refinement. Frequent deletion of these kinds of data in order to break user-tracking continuity across time may have negative impacts on preserving certain site settings and user information when revisiting the site.

Because the selling of user data (or the renting of site space to acquire user data) is the dominant form of revenue raising under the current "free website" business model, tracking visiting users and their behavior has become a key tool for that business model. Since the business model is unlikely to change in the forseeable future, user tracking is only likely to grow in sophistication, scope, and intensity.

Bottom line: the age-old war between convenience and privacy/security is at work here. There are things users can (and I believe should) do to protect their privacy/security, but they will come at the cost of convenience in some way or another. Each user has their own level of comfort regarding the tradeoff. Things like blocking 3rd-party cookies, limiting JavaScripting, frequent deletion of browser private/cached/history/tab data, URL-blocking of common data harvesting URLs, and user-agent spoofing are tools users can employ to greatly increase their online privacy/security... but each tool comes at some potential convenience cost, the most common being that a particular site simply won't work right. Hence, a privacy/convenience-conscious user either has to employ such tools and accept whatever resultant site breakages occur as a way of life, or the user has to become knowledgeable and reasonably proficient in tweaking the tools to minimize the damage to the convenience elements the user demands.

[Morg42]

And yet another (if already known) reason not only to block ads, but to specifically block all js you don't absolutely need...

https://www.bleepingcomputer.com/news/security/crooks-created-28-fake-ad-agencies-to-disguise-massive-malvertising-campaign/