Project

General

Profile

Actions

Feature #270

open

Fine grained JavaScript controls

Added by Soren Stoutner almost 6 years ago. Updated 5 months ago.

Status:
New
Priority:
4.x
Start date:
04/12/2018
Due date:
% Done:

0%

Estimated time:

Description

This will allow enabling and disabling individual JavaScript commands, allowing simple layout commands to function while disabling more dangerous ones.

Actions #1

Updated by Prince Cooper over 1 year ago

But we donno which one's dangerous & which aren't. Instead it's better to focus on content blocker support such as uBlock Origin integration, which does a great job at that.

Actions #2

Updated by Soren Stoutner over 1 year ago

Implementing this feature will require a lot of work. Each JavaScript function will have to be classifies as to the worst possible damage it can do to the security and privacy of the user.

One of the interesting aspects of this is that, once you start thinking about it deeply, JavaScript functions that originally appear to be benign can be abused in unexpected ways to compromise the privacy of users. As an example, consider all of the ways apparently innocuous JavaScript commands have been used to fingerprint users.

My guess is that the final list of safe JavaScript commands will end up being fairly small.

Actions #3

Updated by Soren Stoutner 12 months ago

  • Subject changed from Fine graned JavaScript controls to Fine grained JavaScript controls
Actions #4

Updated by ask low 5 months ago

Don't you think this is much more difficult than just filtering the web elements ?

As far as I know this isn't even being done by the current top tier content blockers like uBO.

What approaches are you exactly mentioning when you say disabling dangerous JS functions ?

Actions #5

Updated by Soren Stoutner 5 months ago

Content filters like uBlock Origin or anything based on the AdBlock syntax do not have the plumbing to block individual JavaScript commands. This is a step beyond anything of which I am aware of being currently available.

Actions #6

Updated by ask low 5 months ago

Wouldn't blocking an entire JS segment cause breakages ?

Actions #7

Updated by Soren Stoutner 5 months ago

Yes, it will cause breakage. There is no version of having privacy and security on the internet that won't break things as they currently exist.

Actions #8

Updated by ask low 5 months ago

I've recently heard that modern browsers (both chrome & fox based) already do some form of JS filtering which they calling it web filtering. Is it true ? Or is it just a fluff ?

Actions #9

Updated by Soren Stoutner 5 months ago

Do you have a link to any information about that?

Actions #10

Updated by ask low 5 months ago

Google calls it Google SafeSearch, which they claim that their AMP websites reduce the site clutter...
https://amp.dev/documentation/examples/interactivity-dynamic-content/client-side_filtering/

I still believe it's all fluff, as those claims were never showcased in realtime.

Trying to learn the inner workings from here:
https://www.freecodecamp.org/news/how-to-write-your-own-map-filter-and-reduce-functions-in-javascript-ab1e35679d26/

Actions #11

Updated by Soren Stoutner 5 months ago

AMP (Accelerated Mobile Page) is only a tangentially related issue.

Basically, Google noticed what everyone else noticed, which is that lots of JavaScript slows things down. So, they created a standard called AMP, which doesn't let you use most JavaScript. But, most critically, AMP also requires that you host your pages on Google's servers instead of where they are normally hosted. This lets Google continue to spy on you.

Google's answer always lets them continue to spy on you.

Beyond that, AMP is basically dead, because everyone realized that letting Google force you to host on their servers was a really bad idea.

https://plausible.io/blog/google-amp

Fundamentally, AMP is different than what this feature request is describing. AMP removes the JavaScript commands from the file on the server before it is sent to the browser. This feature request ignores some JavaScript commands after the browser receives them from the webserver.

Actions #12

Updated by ask low 5 months ago

LMAO. How does Google even kill their projects even before we know ? I thought it was still floating around.

So AMP is (was) a client-server based filter, whereas browser based JS filter is local only right...

Actions #13

Updated by Soren Stoutner 5 months ago

AMP was a system where Google made a list of things that you weren't allowed to put in your webpages, including some types of JavaScript, CSS, HTML, etc.

https://amp.dev/documentation/guides-and-tutorials/learn/validation-workflow/validation_errors

Then, you had to host the page on Google's server instead of your own.

If you did this, your page would appear higher in Google's search results.

Typically, AMP pages would have a corresponding non-AMP page that was hosted on the original site.

Particularly, AMP targeted news organizations. So, CNN would have AMP and non-AMP pages for each of their articles. The AMP ones would rank higher in Google searches. They would have fewer ads. They would load more quickly. They wouldn't include a lot of JavaScript, including tracking JavaScript. In fact, CNN might not even know if you clicked on one of their AMP pages.

Google liked this idea. If everyone adopted AMP, then Google would be the only host on the internet. They would have all the data and all the power and all the control and everyone else would have to do what they said. And, if the entire internet had switched to AMP, anything that wasn't AMP would eventually not be accessible, and a web browser eventually wouldn't know how to find anything that wasn't on Google's servers.

You can see why everyone thought this was a bad idea. Centralizing the entire internet at Google is the antithesis of what the internet was originally designed to be.

Getting rid of most JavaScript is good. Giving Google entire control of the internet is bad. Putting the two together doesn't end up as a net positive.

Actions

Also available in: Atom PDF