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:

    0_1516651974365_Bildschirmfoto 2018-01-22 um 20.47.26.png

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

    0_1516652064195_Bildschirmfoto 2018-01-22 um 20.48.31.png

    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).

    0_1516652100719_Bildschirmfoto 2018-01-22 um 20.49.32.png

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

    0_1516652211890_Bildschirmfoto 2018-01-22 um 20.50.18 Kopie.png

    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)

    0_1516652264361_Bildschirmfoto 2018-01-22 um 21.17.25.png

    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)

    0_1516652363013_Bildschirmfoto 2018-01-22 um 21.18.29.png

    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):

    0_1516652446628_Bildschirmfoto 2018-01-22 um 21.20.33.png

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

    0_1516652493590_Bildschirmfoto 2018-01-22 um 21.21.19.png

    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:

    0_1516652661750_Bildschirmfoto 2018-01-22 um 21.24.09.png

    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...):

    0_1516652612529_Bildschirmfoto 2018-01-22 um 21.23.16.png

    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:

    0_1516652806551_Bildschirmfoto 2018-01-22 um 21.26.33.png

    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:

    0_1516653257794_Bildschirmfoto 2018-01-22 um 21.29.37.png

    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:

    0_1516653334655_Bildschirmfoto 2018-01-22 um 21.35.17.png


    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...



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



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

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

    I don't quite understand this either...



  • Magnificent work @Morg42 -- ta muchly!



  • 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?



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

    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?

    To block first-party scripts by default in UBO would require adding * * 1p-script block to 'My Rules'. To whitelist first-party scripts for specific sites/domains you would then follow the same procedure you observe when changing a third-party domain to allow/noop.



  • @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.



  • @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).



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

    @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).

    That's what I did to find out what the text rule was, since I couldn't find it documented anywhere. :laughing:



  • 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]:
    0_1516753537950_20180124_002.png
    #########################################
    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 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.



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

    @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.

    Yep, I think that unless you're visiting a lot of dodgy sites, the hassle incurred by denying first parties by default is probably not worth it. Heck, I'm still not satisfied that there's a major security benefit to blocking javascript in general, but if you can live with the extra work it entails (I don't think I can) then it certainly can't hurt either.



  • @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 ;)



  • @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 said in External JS resources and a guide to safer browsing...:

    @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 ;)

    When it comes to privacy, I'm already convinced that blocking javascript works wonders. But modern browsers already seem to have pretty good protection against being compromised by malicious javascript code, to the extent that I'm not aware of any major holes in this area that haven't been closed in short order. The problem for me, and the way I use the web, is that there are quite a few instances where I actually want sites to be tracking me; for instance, when I move from a shop front to Paypal, or from a library link to a digital resource where my credentials are shared to authenticate accessing said resource. Having these sorts of transactions fail (or appear to fail) mid way can, and sometimes has, led to consequences that are more than just inconvenient (e.g., whitelisting necessary domains causing a page refresh that results in being billed twice). That's why, for me personally, the security pay-off would have to be pretty remarkable.



  • @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. ;)



  • great guide!



  • Thank you :)



  • 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.



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


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.