Re: Proper form for a public FMS outproxy?

On 2019-07-20 07:59, Arne Babenhauserheide wrote:
> Hi,
> 
> [email protected] writes:
> 
>> Now, my idea is this: You set up a public (onion or clearnet) frontend
>> where you can make and read posts, with its back-end being FMS.
> …
>> Frontends would be disposable and dime-a-dozen; a front-end with too
> To get to this situations, you must make it very, very easy to host
> them. This might be a major endeavor (but one which would benefit
> Freenet a lot).
> …
Well, would it? You can pass through FMS, and only intercept the parts 
related to posting. You'd also want to intercept the progress screens 
for downloads, which might be a bit harder.

But it shouldn't be too much work.

All you'd need to do is write the code that does the filtering. For HTTP 
-> Freenet, you'd want to block out everything like config pages, and 
only show the actual data. To make things easier, you could just expose 
the FMS HTTP frontend directly and pass all GET requests through.

The other side is a bit more complicated. You'd filter POST requests, so 
that it checks if it's for the boxes in the FMS frontend used for 
posting. If it is, check cookie. If it doesn't have the cookie, 302 it 
to some page like /auth. That gets a special exemption. The easiest 
implementation I can think of is a small PHP script with a hardcoded 
secret. It checks if the captcha is OK. If so, it sets a cookie to (time 
|| id || hash(secret || time || id)), where || is concatenation. Then 
the frontend also has the hardcoded secret.

Ugly but would probably work fine. For smaller attack surface, it can be 
replaced with a tiny CGI binary or whatever.

If it does have the cookie, then make a post using the ID in the cookie.

What I'm curious about is how the identity generation should proceed. In 
particular, can the WoT have multiple identities sharing the same key?

If so, it's quite trivial: You have a master key, let's call it 
"master@asdasd...". Then any users post from "user_<unique 
ID>@asdasd...". And each post gets some script to run that tells WoT to 
add it into the trust database.

The end result would be a binary that you download, give a FCP and FMS 
port, a captcha provider (with a built-in fallback, of course), and 
execute. On port 443 you get your frontend, no config needed.

In theory, no need to rate limit or do anything else complicated. The 
network would handle it fine. In practice, might be best to limit it to 
1 post/minute and put in some simple bayesian filtering, so the master 
identity doesn't get completely sullied. Or does FMS do rate limiting 
already?

Certainly, it would take you some time, but it's not strictly speaking 
difficult work as long as this identity generation problem gets solved.
>> My idea is that each user posting would get some kind of unique name
>> (e.g. truncated salted IP hash, or for Tor users a cookie they need to
>> solve say 20 captchas to get - maybe you could do JS PoW or something
>> like that). Then the frontend would post with its key but that
>> name. It would also assign message trust slightly above zero, but no
>> list trust.
>> 
>> Do you think this would work? It's a bit ugly taking the IPs, but not
>> disastrously bad. The server wouldn't need to do any IP banning of
>> pathological cases. It could carry out basic spam filtering
>> (e.g. Bayes), but it wouldn't have to. Captchas might be possible to
>> replace with rate limits.
> 
> I’m thinking about this as I would an attacker to do. If I did not like
> your forums, I would simply DoS them by posting from many different 
> IPs.
> 
> Providing this with an ID just tied to solved captchas via cookies 
> could
> work. That would then be ephemeral identities. If combined with limited
> posting rate and limited lifetime (i.e. solve one additional captcha 
> per
> week so you cannot just collect IDs and then use them all at once
> without maintenance cost) would prevent using this system to DoS FMS.
> 
That makes implementation much simpler too, since you don't need to pass 
on the IP info or treat onions as a special case. What you could do 
otherwise is to use for instance the Spamhaus RBL. That would block all 
the open proxies. An attacker could pay to rent botnets or whatnot, but 
that costs money. So does solving captchas, so it's not a perfect 
defense either.

Doesn't FMS already limit posting rate on the client side?

Solving an additional captcha per week would be trivial to add. For more 
privacy, you could have that give you a brand new identity with trust 
assigned based on the old one. Ideally this would be of limited 
resolution (has good history/has no history/has poor history) so you 
can't link them together but still can't use it to "launder" burned 
identities. And this would be assigned by a new identity, so people's 
distrust of that doesn't interfere with their distrust of master.

This might be overkill though. Adds implementation cost, and now the 
server gets access to non-public information (although it never has to 
save it). Easier to just tell people to make a new identity once a 
month.

>> Specifically, a user that didn't like this would set list trust of the
>> master identity to 0. Do you reckon this would happen?
> 
> Yes, I think this would happen, because one bad apple would spoil the
> whole identity.
> 
> But if you would find a way to pre-generate IDs and then assign them to
> new users (so the standard FMS spam-defense would work), then this idea
> could work.
> 
> If the proxy had a main ID which gives trust-list-trust to these IDs,
> then people could decide whether they want to see the new IDs.
> 
Well, this is what I'm concerned about. Do you reckon they would 
blacklist the main ID's trust list, because it has too many children 
which are rotten apples?
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken

Another question: Say you want to forward mailing lists over Freenet, 
such as this one. What'd be the best approach?

Either you could have a single bot with a single username, and rely on 
the central moderation to kick spammers out. It then posts to FMS.

Or you could do Freemail mailing lists.

Or you could use the approach I outlined above.

But how do you get redundancy? If you have two such bots running, you'd 
get duplicated messages. If you have one, you get atrocious fault 
tolerance.

Does FMS support cancelling messages? Obviously you can never delete 
them, but you could ask user agents politely not to download them or 
judge you for their contents.

Then the bots could agree on some protocol; they make posts announcing 
themselves somewhere, and then these are assumed to take effect after X 
seconds. If other bots find X too low, they rate them negatively, but 
they all get to specify X. And a similar parameter, let's call it Y.

Then, each bot computes hash(key || message hash) for all the bots it 
knows about, and sorts the list of hashes. If it's first in the list, 
it's the first one who should propagate the message. If it's the second 
in the list, it should propagate it if nobody else sends after Y 
seconds. If it's the third, wait Y*2 seconds and see. If it's the nth, 
wait Y*n-1 seconds and see. And so on, and so forth.

Bots which "jump the gun" would get blacklisted by the other bots 
programmatically. Bots which censor messages would get blacklisted, 
provided they didn't block all messages sent within a certain timeframe.

Maybe this is a solved problem already in CS, though.

Another question is if FCP already supports a "stripped-down mode", 
where it doesn't expose internal material, only stuff that's on the 
network. I know SIGAINT ran a Freenet <-> Tor proxy, do you know how 
they did it?

Cheers