Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)

  • 0 Posts
  • 38 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle


  • It isn’t usually. If it was, the server-side function wouldn’t need a constant runtime at different-length inputs since the inputs would not have differing lengths.

    The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.

    For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.







  • I have that exact setup working. qbittorrent (and -nox) are a lot more involved to set up with I2P, but there is some material on how and once you get it running it works quite well at this point.

    I don’t use docker for it, but that should work too. For browsing I use a maintained fork of proxy switchy omega, which allows to choose a proxy profile based on the url, making it easy to pipe i2p pages into the i2pd socks port (I use I2Pd not I2P, don’t think it matters much). qbittorrent can be configured in the same way to statically use the the local (4447 on i2pd) port as a proxy to prevent any clearnet communication. In addition it needs the dedicated I2P host 127.0.0.1 and port 7656 (the sam bridge, giving deeper access to I2P).

    Don’t expect to do anything on the clearnet over I2P, the exits are not good and it’s not what I2P is meant for. For that reason don’t set I2P up as something like a system proxy/vpn, instead pipe the specific programs you want using I2P into the proxy ports using their proxy settings.

    To get rid of the firewalled status in the I2P daemon, you will need to forward ports. Maybe you have seen advice for servers that are not behind a firewall and nat, so that effectively have all ports “forwarded” already. The mythical dedicated IPv4 address.
    In your case you need to pick the port your I2P daemon uses for host to host communication randomly, then forward both TCP and UDP for it on IPv4. Also make sure you even can forward ports, depending on region ISPs no longer hand out dedicated IPv4 even per router, so you might have to specifically ask your ISP for one (I had to). But that is all generic hosting, if you can set up a minecraft server you can make I2P have full connectivity.









  • This would solve some of the problems. If only 2 instances know about the votes, post instance and sublemmy instance, you can reasonably expect to get most instances to never release that info. It would allow either the sublemmy or post instance to manipulate around in the votes, but most manipulation would be detectable by the respective other instance.

    It would open the door however to manipulating around with internal posts made from the instance in a sublemmy on the instance. And it would allow the post instance to drop votes selectively, though I think that is possible currently all the same.

    Votes being sent to both the sublemmy and the post instance simultaneously would make manipulation a lot harder. And for cases like internal posts, you could add another involved “judge instance” that receives the vote details directly from source, and is merely there to confirm the total. Instances that hand out non-independent “judge instances” could be labeled as untrustworthy in the lemmy community.

    So you end up with a list of instances per post that votes are reported to, to which you add the post instance, sublemmy instance, judge instance, and maybe some more.

    In terms of implementation, I think the activitypub protocol needs an origin for votes, right? I would say an instance can just report the votes coming from a stock of obviously fake accounts, like “masked_upvote_1” to _999999 … and “masked_downvote_1” to _XYZ.
    About the votes, I am not sure. It could be done as a lemmy-internal feature where lemmy instances and other instances knowing of the lemmy protocol send the info to all the relevant instances, while any votes from external instances only arrive at I guess the post instance and that then forwards it on to all other instances. This way the checking doesn’t work for software unaware of that lemmy specific vote implementation, but everything is still compatible.

    You could then even for those lemmy-external votes add an interface on the judge instance, that would confirm via pm if your vote has arrived.

    Do you think this could work?


  • In my case I would like them to be private, but currently they are not. I don’t think it is good to try to hinder the visibility into a fundamentally transparent system.

    I don’t see a technical way to make votes private either, that doesn’t prevent bad actor instances abusing the vote system. As an admin of an instance I could just add 5-10 votes to all of my interactions whenever I feel like it, and noone would be able to tell it didn’t come from legitimate users on my instance. The accounts of vote origin are needed as proof, hence moderators on lemmy having access to them.

    Do you perhaps have any idea how this could be accomplished?