Re: Numbered List of Freenet Project Ideas
1. Introduce a restricted plugin API: nextgens has had this idea for a while - only give plugins a plugin API object instead of a full classloader with access to the entire Node. If plugins can only access Fred functions explicitly intended for plugin use, it should be way easier to figure out how plugins are intended to do things, way easier to document and find documentation for because it’s all in one area, and it could also have better security characteristics with more work - like a system for plugins to be granted and restricted from various capabilities, both within Freenet’s API and on the system. It’d be better for backwards compatibility going forward because now it’s defined instead of plugins reaching into the Node object and poking at whatever they found to make things work. 2. Make FCP into a plugin: bonus points if it uses the restricted plugin API. It’d be a good way to test the plugin API and ensure it covers a good amount of functionality. This would separate an important function from core Fred code. (Side note: FCP really should require two-sided user interaction like KeepassXC and its browser companion plugins, or an API key, instead of giving access to whatever plugin can connect to its port.) The plugin might also be able to be run in a passive mode in a transition phase, like GitHub can do with changes it makes, where its answer to a query is compared to that of the integrated FCP. (This’d have to be for some subset of queries that doesn’t change the state of things - are there many/any of those? Maybe fall back to integrated FCP for things not implemented by the plugin?) Maybe it would be a good idea to use a platform-neutral API? Then people could develop their plugins in whatever languages they wanted, instead of having to tightly couple them to Java. So either you'd connect over TCP to a port, or you'd use some kind of C API, which nearly every language trivially can make bindings for. For smaller plugins, FCP could execute them, like in CGI. It would be some work to sandbox them though. One way around it would be to not have the system execute them, and for instance restrict yourself to Java at first, but make it possible to extend to other language. Personally, I'm a stickler for Lua, and that sandboxes very well. As for queries changing the internal state, the nuclear option would be to provide some "testing mode" where you run two instances and replicate everything. But then what about the non-deterministic parts? Another approach might be to gradually change FCP to interface with a replica of the plugin API but still be integrated non-plugin functions anymore, it can be separated out cleanly. In a second step, the plugin API could be changed into a Java binding for a C plugin API, which in turn is implemented as a C binding for a Java plugin API. 4. Transport plugins: we need more things Freenet traffic can look like and more ways for it to move around, and as a bonus doing this will likely continue to turn up bugs in various places. What about Shoeshop? Could that architecture be extended? Not to mention a Tor Hidden Service transport plugin - listen as a hidden service, and connect to other nodes so listening. Isn't I2P better for such applications? Freenet does use a lot of bandwidth, after all. Another low-hanging fruit would be BitTorrent. The DHT could be used as a backup seed node. BitTorrent traffic doesn't draw attention, is already encrypted, and doesn't look odd connecting to specific sets of IPs. The GFW does use this heuristic to detect proxies - if a certain percent of outbound bandwidth goes to an IP, then that gets blocked. 6. Can we adapt existing applications?: forgetting for a moment how JavaScript adverse much of our userbase is, can those who are willing to run it (not from Freesites but from local applications) be served by writing a backend powered by Freenet for an existing forum or wiki? How practical would that be to do? https://github.com/Requarks/wiki https://github.com/discourse/discourse I feel like we’re spending a lot of effort trying to write these applications from the ground up, and while that does have some desirable properties it’s also more work for fewer features. For what purpose? Wikis are entirely static already, and to engineer a forum does more or less require a from-the-ground-up re-architecture anyway. And such an engineering work has been undertaken already, see FMS. I wouldn't think it's possible, anyway. Most of these applications rely on secret databases and incoming connections, of which Freenet furnishes for neither. You'd just be using Freenet as a poor man's Tor, as I understand it. Then you'd be better off running conventional MediaWiki software, using a script to dump all of the pages as HTML to a directory, and then publishing it as a conventional freesite. The downside is of course the read-only nature and the poor scaling.
Re: Proper form for a public FMS outproxy?
On 2019-07-21 08:11, Arne Babenhauserheide wrote: yanma...@cock.li writes: On 2019-07-20 07:59, Arne Babenhauserheide wrote: yanma...@cock.li writes: Frontends would be disposable and dime-a-dozen 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). If you want to make it dime-a-dozen, you need to make it easy to install Freenet with FMS already setup. Aren't Freenet and FMS already trivial to install programmatically? If you have actual IDs, you must provide a secure way to log in — not secure against the server, but secure against others users impersonating you. Visibility is also based on the ID, otherwise you don’t get real spam defense (you’d have to rely on the site hoster to manage spam for you). Well, doesn't the cookie mechanism I described do this? Everyone is anonymous, but personally I think that goes under "It's not a bug, it's a feature". No need for an actual login field, although you could give them a link that sets the cookie for them that they can use as a bookmark if they want. If you need reliable names, you could implement tripcode functionality. For a bit more security, secure tripcodes. This also simplifies implementation. On the other hand, it's ugly. But then again, Worse is Better, and if you want your software to spread you should make it as simple as possible, like a virus. https://en.wikipedia.org/wiki/Imageboard#Tripcodes Recap: When posting, you enter a name and a secret, separated by one or two pound symbols. For instance, yanmaani#NDl5tlZY. Then the server hashes whatever is after the pound symbol(s), and replaces it by its (possibly truncated) hash. So an example output would be yanmaani#Ri2dTa5T. If using two pound symbols, a secure tripcode is computed, where the server appends a secret salt, which makes offline brute-force impossible. That has the downside of not being portable, of course. Maybe you'd want to replace the pound symbol by something else, but that's an implementation detail. A user who was really serious about becoming famous should either GPG sign their messages or download Freenet. I don't think "secure identities" are useful more than as a spam countermeasure, and for that purpose tripcodes are more than enough. Anyway, the upside of predictable names is that you could separate the "announce" and "post" parts. Then posting could require for instance one captcha, and announcing ten. And there would be no need for the server to do any book-keeping. So the workflow for a new user would be a1) visit gateway.com/announce a2) type in their name (optional) and tripcode a3) solve 10 captchas b1) visit gateway.com/board/thread b2) make their post, type in tripcode b3) solve 1 captcha, for rudimentary flood/tripcode bruteforce control Steps B can be done before steps A, but a minor UX issue is users doing steps B and only B. There could be a warning if the server believes that to be the case, though. Kind of like on this mailing list: first you solve a captcha to get your e-mail added to the list, and then you can post. Except for the part where you can't first post and then solve captchas. Super ugly but probably decently functioning hybrid approach: posting, if done from a clean IP, gets a very low trust from a seed node, provided the IP hasn't been used in the past week or whatever. This would make it possible for "normal users" (e.g. casuals dropping by who just want to try it out) to post without much hassle, while still making it possible for Tor users to post. And the network could handle blacklisting that seed node if botnets are raising too much hell. Of course now the implementation is much harder, since you need to pass the IP on to the onion service without terminating SSL. So I would rather not go down that route. The network could handle blacklisting too old identities that suddenly resurface - an attacker stands nothing more to gain from solving 20 captchas and getting a new identity from the service than they do from solving 20 captchas and getting a new identity with its own key, so I wouldn't imagine it that big a problem. Another way could be for posts without well-announced identities to go into some kind of "pool" where you can vote on them. Or you could just have low standards for initial identity verification. Probably, this can be fine-tuned on-the-fly long as you get the concept working. So I wouldn't bike-shed it too much. What I'm curious about is how the identity generation should proceed. In particular, can the WoT have multiple identities sharing the same key? No, and that wouldn’t be a good idea, since they could switch to the other ID if they’d manage to trick the server into using another public name. But there's no issues if the server is well-coded? Or does WoT point blank not have the ability to deal with multiple identities sharing the same key?
Re: Proper form for a public FMS outproxy?
yanma...@cock.li writes: > On 2019-07-20 07:59, Arne Babenhauserheide wrote: >> Hi, >> >> yanma...@cock.li 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. If you want to make it dime-a-dozen, you need to make it easy to install Freenet with FMS already setup. > All you'd need to do is write the code that does the filtering. If you have actual IDs, you must provide a secure way to log in — not secure against the server, but secure against others users impersonating you. Visibility is also based on the ID, otherwise you don’t get real spam defense (you’d have to rely on the site hoster to manage spam for you). > What I'm curious about is how the identity generation should > proceed. In particular, can the WoT have multiple identities sharing > the same key? No, and that wouldn’t be a good idea, since they could switch to the other ID if they’d manage to trick the server into using another public name. > 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 If you block open proxies, then you exclude all tor users, but you don’t get real security, because botnets are horribly cheap. > Doesn't FMS already limit posting rate on the client side? Not that I know of. It has delay of messages to provide more anonymity. > Solving an additional captcha per week would be trivial to add. > 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. The server always has non-public information about the users. The question is just how to represent it. >>> 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? Yes. It would then be the same as those public IDs (where the secret key was published intentionally) which get blocked after abuse. > 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. There are distributed leader election protocols. You could use a simple bully-protocol https://en.wikipedia.org/wiki/Leader_election#Asynchronous_ring[3] > 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. You’d likely have to block them via FMS and only consider bots in the distributed algorithm which are not blacklisted by given moderator IDs. > 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? There is public gateway mode, but I would not vouch for its security — it might have deteriorated over the past years of little usage. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
