Hacker News Reader

Another alternative: uBlock Origin with "advanced mode" enabled. You can tell it to globally block "inline scripts", "1st-party scripts", "3rd-party scripts", and "3rd-party frames", and selectively undo that block when needed. See https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu... for an explanation with screenshots.

uMatrix provides a more fine grained approach to blocking and has an interface to match this. uBlock's interface can be easier for a more coarse grained approach (see dynamic filtering, medium mode).

I never tried uMatrix. uBlock has the ability to block a particular set of links e.g. abc.com/min/* and whitelist some links within that set e.g. abc.com/min//.png. I think that's a fine grain approach. Can uMatrix do things like this?

Here is a quick tutorial showing what uMatrix can do https://github.com/gorhill/uMatrix/wiki/Very-bare-walkthroug.... As you can see, it gives you an easier way to have fine-grained control of each individual type of resource. It also allows you to configure third-party domain resources globally, or per domain. This allows you to do something like allow youtube embedding (js + xhr) on all websites at once.

NoScript provides many features that uMatrix does not:

* Shift+click on host name, and pull up info on trustability from NoScript.net database

* Filters WebGL, XSLT, @font-face

* Sophisticated XSS protection: Look up XSS on these pages:

https://noscript.net/features

https://noscript.net/faq

* CSRF protection

* Clearclick: Detects invisible elements which cover clicked visible elements

https://hackademix.net/2008/10/08/hello-clearclick-goodbye-c...

* A pretty sophisticated firewall in your browser, Application Boundaries Enforcer (ABE), where you can even write your own policies:

"Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request"

"Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level."

"The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections ... by delivering a firewall-like component running inside the browser ... specialized in defining and guarding the boundaries of each sensitive web application"

More here: https://noscript.net/abe/

Also, there's a project to create a GUI for just the ABE component, called SABER

https://forums.informaction.com/viewtopic.php?f=19&t=8059

Some of these features can be accomplished simply through blocking javascript.

Which ones are you thinking about?

Sometimes you want to enable JavaScript and still be protected from attacks.

For us tech-savvy people that might be an option. But for the average user it's not. Too many things don't work. I use Privacy Badger and install it on every system that I maintain. It's simple and clean, and set up by an organisation that doesn't need shady ads on its website.

I do find it ironic that people assume that NoScript's only feature is the one that is the most hassle to use. The more passive always-on protections get overlooked, and people recommend as equivalent alternatives extensions that only provide a better UI for the domain-based script blocking, while not providing the defense in depth that NoScript has.

Not sure if this is considered bad practice, but I have uMatrix installed with noscript. I use uMatrix for script blocking and have noscript set to globally allow scripts, with ABE, XSS, clickjacking, etc protection enabled to cover the weak points of uMatrix.

Why would it be bad practice?

Perhaps bad practice was the wrong word. Unnecessary might have been a better word.

"Shift+click on host name, and pull up info on trustability from NoScript.net database"

The irony of that is staggering given NoScript being busted for spreading malware in this story.

The report includes only links to third-party information, eg.: https://noscript.net/about/news.ycombinator.com;news.ycombin...

> It will take about three or four refreshes before you can whitelist everything necessary to get Youtube working. First youtube, then s.ytimg.com, then googlevideo.com, THEN you might finally get a video.

> Any page with a Google Captcha on it will take several refreshes to completely let them through. This is particularly irritating if there's a captcha on a form.

> Anything which needs to reach out to jquery, ajax, etc. will fail. But you should be able to whitelist those once then add them to your permanent whitelist.

These should all be one time deals though. You can whitelist some or all of this stuff in the global scope so it applies to all web pages (if you want to do this). For example you can whitelist the youtube stuff in the global scope so that any page which has imbedded youtube videos will show them. This should be a safe practice as the google domains should generally be trustable.

Or don't do this. And whitelist it on a site by site basis. The choice is yours.

You say uMatrix is "somewhat more usable than NoScript, insofar as it usually allows Javascript on the local site by default, while automatically blocking JS on third-party domains"

But that's exactly the default I do not want. One of the main reasons I use NoScript in the first place is to protect against Javascript vulnerabilities. If the default is to enable Javascript, that defeats that protection.

You can toggle it on both extensions.

A more useful alternative may be disabling JavaScript globally, and maintaining a clearlist of sites allowed to run it.

Or combine this with uMatrix, giving yourself a global blocklist with 3rd party granularity on the sites you do clearlist.

Was this comment really so unhelpful as to merit a downvote?

You can change this behavior in both NoScript and uMatrix. In uMatrix all you have to do is disable first party scripts in the global (*) profile. NoScript defaults to the opposite (don't allow any scripts) but the behavior can be changed to allow first party scripts by default.

How do I disable scripts for just one site? I tried to use uMatrix once as it was suggested as the alternative of noscript for chrome. I just wanted to get rid of those annoying anti-adblock popups on wired.com. However every setting I tried on the drop down menu failed to block javascript, or just blocked all content on the domain wired.com. I tried going deeper into the settings but I found the user interface confusing and nothing was labelled. It's definitely not a convenient alternative for noscript/javascript blocking. Even if it may be possible to achieve that with it.

Make the script column for the host you want to block red/blue. Then make sure to save if it worked as intended.

How much of the 2016 Web is usable without JS?

A pretty good amount. For instance, HN is barely degraded at all. Voting causes a full page refresh, but that's about it.

Some news organizations implement their paywalls with JS. It gets rid of a lot of annoying ads and scroll-behavior modifications. It actually makes some sites subjectively better.

> For instance, HN is barely degraded at all.

HN isn't the 2016 web at all. Not that you fundamentally need JavaScript, but HN's HTML hearkens back to the pre-CSS table-driven web.

Most of the time you just enable the scripts with domain name and "cdn" in them. Sometimes, it's trial and error to find the fight combo but I usually get it in first guesses. I've found that the sites that were too much ttouble I just skip, momentarily irritated I didnt see the content, and then forget about that site. I can't say Ive lost anything major boycotting the worst offenders.

> HN isn't the 2016 web at all.

Yes but when visiting a website with JS turned off, the site can still be progressively enhanced similar to how an electric stairs still works when the power is switched off. Users of the stairs still get to climb it, but now they have to put in extra effort.

> Yes but when visiting a website with JS turned off, the site can still be progressively enhanced similar to how an electric stairs still works when the power is switched off.

It can, but sites often don't test that path (if they develop it at all), because it only applies to people who intentionally disable JavaScript.

Once upon a time, screen readers and similar accessibility software didn't work well with JavaScript, so better sites would pay attention to that case for accessibility. However, screen readers work fine with standard browsers and JavaScript now, which makes the "JavaScript disabled" case an incredibly tiny fraction of web users. (In fact, Mozilla found a few years ago that there were far more users with JavaScript accidentally disabled than people who actually wanted it disabled.) So, handling disabled JavaScript by just saying "you seem to have disabled JavaScript; you should fix that" really does seem appropriate for the proportional amount of time worth spending on that tiny subset of users.

That said, know your target audience. If you're building a mainstream consumer product, the proportional amount of time worth spending on running with JavaScript disabled rounds to zero. If you're building a product catering to a smaller subset of users, and you expect people with JavaScript disabled to represent a much larger fraction of your potential users, by all means take the extra development time to make that case work well.

Enabling first-party scripts makes most of it usable, but not all. Disabling first-part scripts means probably about 50% is still useful. The internet seems so much 'quieter' with NoScript installed...

It depends what you do on the web. To use web applications, obviously you need JavaScript. To read text, you generally don't. Also, even when you do need JavaScript, you generally need it from the original host and maybe one other (e.g., googleapis.com); you don't need it from the analytics and advertising hosts, for example.

Buying things with security add-ons installed sometimes can be tricky: When you click 'buy', the host site sometimes contacts destinations that were previously unknown to your browser (payment processors, etc.), meaning you wouldn't know to enable them. You may hesitate to reconfigure NoScript/uMatrix and reload because you don't know if you are making multiple payments or placing multiple orders.

On the positive side, uMatrix and NoScript can remember what you enabled to get that page working, so you configure them the first time you visit the site and then forget it. NoScript's configurations are less granular, however, which may discourage permanently allowing some things:

https://news.ycombinator.com/item?id=12624628

(But NoScript has many more security features:

https://news.ycombinator.com/item?id=12624596 )

> To read text, you generally don't.

This is becoming less and less true unfortunately, thanks to stupidly designed (eg: not progressively designed ) JS frameworks.

I'm using NoScript and I temporarily enable JS on sites.

Usually sites work well enough by enabling 1st party JS and sometimes not even all of them. I lose all the code from tracking and monitoring services, which I really don't care about. I gain a much faster browsing experience.

Then there are sites with CDNs, and I have to enable them to see some content. Or Disqus comments, must enable to read them. Then there are some sites that are like a puzzle and I can't understand what to enable. I either give up (lose-lose) or read them in a browser I use for that kind of sites (I lose, they win). Then there are sites with content embedded in the JavaScript (I really mean in the script, not loaded by the script) or in some invisible element that only JS can make visible. Forbes is one of them and the one I hate most. I did a short script to deobfuscate the content at a Forbes URL and display it in a brower.

By using NoScript I appreciate how useless is JavaScript on some sites: there is no reason not to serve basic content (text and most of the images) directly and use JS only to enhance it. Examples: to add comments, to zoom into images, to load the next article - which has it's own URL anyway.

A lot of it is unusable with JS, and progressively getting worse.

Security is a sliding scale. I could stay home all day and wer big pads with sirens on saying "DONT TOUCH ME", but I choose to drive a car at 70mph, walk along-side busy roads and load 1st party JS from sites.

My rationale is that I've chosen to go to a site, and most JS dangers are served from ad networks and trackers. Not typically from the site itself.

I let JavaScript run, but not by default, so it's like "before getting in someone else's car for the first time, I check the brakes work before going 70mph".

Of course, as long as we don't try to force our preferences on each other, we can both browse the web however we like.

Other default settings in uMatrix:

uMatrix comes with many hosts files enabled[1], so even if working in allow-all/block-exceptionally, most trackers/ads and whatnot will still be blocked.

There is no pre-whitelisted (aka "trusted") 3rd-party hostnames in uMatrix, that will be for you to decide.

The default in uMatrix, in full view in the popup panel, can be changed with a few clicks from the main popup panel, and you can also remove all the default whitelisted hostnames in NoScript.

[1] entries are translated into `* hostname * block`.

>One of the main reasons I use NoScript in the first place is to protect against Javascript vulnerabilities

All 0 of them?

You've received downvotes, but you're not wrong. Javascript security used to be a concern, but that's been effectively eliminated with modern browser design.

Code is sandboxed, processes are isolated, OS-level security is used on top of that. The few CVEs that show up are reported quickly via browser bounties or in-house testing. People claim bounties are ineffective, but how many exploits have we really seen emerge from "black markets" or other sources?

I ran without JS for a few years and then realized it was making my online experience more miserable than it needed to be. I can't remember the last time I actually saw a computer "infected" just from visiting a website, and not through social engineering. Can you?

The bottom line is that the margin for being compromised via JS is so small that it might as well not exist. If you disable it because privacy or surveillance or whatever else, that's your prerogative. But the security issue is completely overstated and largely misinformed.

If you use Firefox, you could add https://addons.mozilla.org/de/firefox/addon/decentraleyes/ , it might make the common CDN stuff easier.

for the english speakers amongst us: https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...

Another advantage is uMatrix on Firefox is already multiprocess compatible and NoScript is not.

> insofar as it usually allows Javascript on the local site by default

NoScript can do this too BTW. The web is almost unusable without that setting enabled.

The drawbacks you identified are exactly the same on NoScript so they should not be used as a reason to pick one over the other.

It takes a LONG time to get a good list of whitelisted sites, now that mine is more or less usable I don't intend to switch - especially since I disabled the "show webpage with ads" thing on NoScript, so I don't have the problem in the article.

One advantage of uMatrix: You can filter based on host-destination pairs.

That is, in NoScript you can only filter based on the destination. For example, if you allow one site to run scripts from cloudfront.net, every site can. Effective the rules are,

  DENY  * *
  ALLOW * cloudfront.net

In uMatrix, you can write rules based on host-destination pairs, permitting scripts from, e.g., cloudfront.net to run on your bank's website but not on any others:

  DENY  * *
  ALLOW mybank.com cloudfront.net

Finally, you can filter by host & destination & function:

  DENY  * *
  ALLOW mybank.com cloudfront.net JavaScript

... which would not allow plugins, images, CSS or anything else from cloudfront.net, only JavaScript.

EDIT: Add, improve examples

Google, Bing, Gmail, Yahoo Mail, Facebook, Twitter, Reddit, HN, Slashdot, and Github all work with Javascript disabled. If a site does not (e.g., Office 365, Slack, Instagram), that tells me something about the competence of the developers they are willing to hire.

Does Google Docs work without Javascript?

IIRC you can only view the document, which makes sense.

> If a site does not (e.g., Office 365, Slack, Instagram), that tells me something about the competence of the developers they are willing to hire.

How exactly do you think Slack is supposed to work without JavaScript? It's probably the poster child of why web applications need JS.

It's the outdated notion that "the web is still a collection of hypertext documents". Yet the reality is that JS webapps have been the standard for some time now, and won't be going away any time soon.

I agree the trend is toward thick Javascript apps, but I call that the death of the web and a wholesale regression to client/server architecture where data is entombed and only usable by a single piece of software that you don't maintain.

That's a pretty harrowing view. I see the movement of logic from the server to the client as liberating, personally, as it gives me more control over it.

Javascript is open source by its very nature. So if I wanted to tweak how Slack works, for instance, I can do so via extensions or writing code myself. In the cases of completely client-side apps, I can even back them up for my own use, such as I've done with a regex testing tool.

You've referred to it as a regression, but let me give you an example like Twitter. Would it make sense to have the server generate the HTML for each and every request, and then send that as a new page whenever you click a link? It's actually much faster to instead have the client send a small AJAX request (give me tweet #3242565), the server respond with that data, and then the client to update the page with it.

Twitter on its face is pretty simply. There's only a few template pages it needs to know ahead of time (timeline, individual tweet). So by moving to a data passing model you actually send far less data. The "javascript payload" being too large can be mitigated by rendering on the server for the first view, as is done in React.

In the case of Twitter, you're still dependent on the server for info either way. But this lets you conserve data, reduces server load, and yields a faster client interaction.

As I said, the web isn't static documents anymore. We've moved beyond that and it's actually pretty great. HN's overall position on this subject disappoints me for that reason.

It could just post the current chat via plaintext up until that point. Yes, you'd have to manually refresh to see updates, etc, but if you are blocking JS, you should expect reduced functionality of web-apps.

I think Slack can be forgiven for not catering to people who basically don't want a chat application to function as a chat application.

> The web is almost unusable without that setting enabled.

The web (i.e., the web of hypertext documents linked together) is perfectly usable with JavaScript disabled; what doesn't work are all the single-page apps which hijack the web's infrastructure in order to break it. This is somewhat like a medicine which does not interfere with the operation of human cells but which disrupts the replication of viruses.

Another alternative (for Mozilla-based browsers): LibreJS

https://www.gnu.org/software/librejs/ https://ftp.gnu.org/gnu/librejs/gnu_librejs-6.0.13-fx.xpi

- Blocks non-free Javascript

LibreJS is not a security tool, and the filtering it provides is fairly easy to bypass.