emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Condition to link to javascript code?


From: Achim Gratz
Subject: Re: Condition to link to javascript code?
Date: Fri, 23 Dec 2016 14:40:18 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

Am 22.12.2016 um 20:56 schrieb Richard Stallman:
Could you put some JS code into the page that would give the user
a way to specify a different URL for klipse.js?  Perhaps that could
be stored in a cookie or something else in the browser.

You could do that by rewriting the page into the form that is then ultimately displayed in the browser. But I don't consider that a good solution as the user doesn't know what's going to happen before trying to use the file (and not at all if the respective cookie already exists, which the user might have forgotten about or has been dropped in from somewhere).

Maybe it is a good solution, but I can't tell from what you sent.
Can you show me a clearer description of what features this addon
actually has?

Basically, it intercepts requests to several CDN and delivers those files from a local repository (delivered with the extension) instead.

You can configure it to block requests to those CDN altogether even when the requested file is not locally available. It doesn't cache anything not available from the repository (and also doesn't use anything in Firefox's cache). That's a good thing in a way, but limits you to the selection of locally available files that come with the extension. Creating a custom repository is listed as a "planned feature", though.

      > Protects you against tracking through "free", centralized, content
      > delivery. It prevents a lot of requests from reaching networks like
      > Google Hosted Libraries, and serves local files to keep sites from
      > breaking. Complements regular content blockers.

in regard to klipse.js.

I've not looked into it in much detail, but I think that klipse.js is not yet included in decentraleyes, so it would either block the request totally or allow it to go to the Google API CDN, depending on configuration.

The more permanent solution for this problem would be to use a local filtering/blocking (like privoxy, GPLv2). It would also need to cache CDN files, which privoxy doesn't do; it must be chained with a caching proxy (like squid, GPLv2) to do that. If it would then download missing files via TOR it could completely eliminate tracking via CDN. It would sure be a nice thing to have something like that in a ready-to-use fashion.

Also, is Decentraleyes free software?  What is its license?

MPL-2.0 according to the home page.


--
Achim.

(on the road :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]