README updated
This commit is contained in:
parent
d51b3d752a
commit
16c40f305d
39
README
39
README
@ -6,8 +6,8 @@ internet traffic. By looking for this pattern, you are more easily
|
|||||||
identified.
|
identified.
|
||||||
|
|
||||||
randrss fetches all your feeds at random intervals at an random order
|
randrss fetches all your feeds at random intervals at an random order
|
||||||
over a certain period of time. The feeds will be downloaded and all
|
over a certain period of time. The feeds will be downloaded and you then
|
||||||
you need is a local webserver. The added benefits of this approach are
|
serve tjhem using you a web server. The added benefits of this approach are
|
||||||
that you don't have to worry about how your client deals with cookies
|
that you don't have to worry about how your client deals with cookies
|
||||||
etc.
|
etc.
|
||||||
|
|
||||||
@ -16,28 +16,41 @@ pointed to the randrss's downloaded feeds, you avoid certain trackers
|
|||||||
that may identify you across devices (google's feed proxy, cloudflare),
|
that may identify you across devices (google's feed proxy, cloudflare),
|
||||||
because it's very likely that the combination of feeds you read are
|
because it's very likely that the combination of feeds you read are
|
||||||
unique. As your feeds are on a single server now, you can isolate your
|
unique. As your feeds are on a single server now, you can isolate your
|
||||||
RSS reader to its own network container so it can only contact that
|
RSS reader to its own network container so it can only contact your
|
||||||
server. This is probably what you should do to be sure your client does
|
server. This is probably what you should do to be sure your client does
|
||||||
not contact the feed servers in any way. In Thunderbird, set
|
not contact the feed servers in any way. In Thunderbird, set
|
||||||
browser.chrome.favicons to false.
|
browser.chrome.favicons to false.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
randrss fetches the feed using Tor.
|
|
||||||
|
|
||||||
The only drawback of this approach is that the time you get new feeds
|
The only drawback of this approach is that the time you get new feeds
|
||||||
is delayed, but that should be acceptable.
|
is delayed, but that should be acceptable.
|
||||||
|
|
||||||
|
By default, torsocks is used to fetch the feeds.
|
||||||
|
|
||||||
Usage
|
Usage
|
||||||
=====
|
=====
|
||||||
First, tweak the shellscript a bit, if you like
|
Fetchers
|
||||||
The input file has the following format per line:
|
--------
|
||||||
url:output file:(optional parameter for the sleep time, in format x-y)
|
Scripts that request the feeds while trying to look like a normal client.
|
||||||
|
|
||||||
An optional user agent file contains the user agents we will randomly
|
Config file
|
||||||
use per feed. One user agent per line.
|
-----------
|
||||||
|
For each feed, an individual config file is used.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
A simple example config file for kernel.org:
|
||||||
|
FEED_URL="https://www.kernel.org/feeds/kdist.xml"
|
||||||
|
FEED_OUTPUT="/var/www/feeds/kernelreleases.feed"
|
||||||
|
|
||||||
|
Launch
|
||||||
|
------
|
||||||
|
randrss [path to directory containing the config files] [fetchersfile]
|
||||||
|
|
||||||
|
fetchersfile: take a look at the example file in the repo. It lists
|
||||||
|
the paths to the fetchers that will randomly be used.
|
||||||
|
|
||||||
|
optional third paramater: "syncnow". Do not sleep for random intervals.
|
||||||
|
Fetch all feeds and exit.
|
||||||
|
|
||||||
randrss [input file] [user agent file]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user