User Guide

Your Freedom User Guide
Page 41 of 52
access anymore to any of our servers. Our idea is that it’s fairly simple to block all
our IP addresses as they pop up because we cannot have new ones every day, but it
won’t be possible to do something about thousands of new URLs every day that
haven’t got anything in common.
It is quite obvious why people would like to use such a “CGI relay” – because they
have to. There is no other reason because obviously, this method is not as fast and
interactive as the other connection methods. But when you’re desparate and no other
way of connecting is left, it’s better than nothing. But why would people put the script
on their web servers when all they get for it is a lot of additional traffic?
We have thought of setting up a rewarding scheme that allows people to earn bonus
points that they can then trade in for packages, but we haven’t implemented it yet.
We soon will when we get the feeling that our users would actually like it and provide
relays. So tell us! But be aware that such a relay could easily create hundreds of
gigabytes of traffic per month, and that your provider probably doesn’t like it if you run
it on a virtual server.
So how do you use such a CGI relay? You need to know the “URL”. I put it in double
quotes because you don’t need a full-fledged URL – you need the server name and
the URI. For example, if the script could be accessed in a web browser using the
URL http://some.server.somewhere/some/path/script.php, the CGI
relay would be called some.server.somewhere/some/path/script.php in
Your Freedom. Simply use it as the server name, choose CGI as the connection
model, and disable automatic server selection.
And how do you know about these? Well, that’s another matter entirely. We won’t
publish any lists and we would ask that you do neither. Why? Because we don’t want