I would hope the difference is that the f-droid version does not contain any proprietary code.

I think it depends on where the bottleneck is, and what they're actually trying to prevent, as to whether or not rate-limiting would actually help anything.

If they are blocking source IP addresses explicitly, it could be for a more specific concern we're not aware of, like trying to limit the amount of email "spam" that would be sent out from automated requests. A rate-limit wouldn't fix that issue, only slow it down.

We're all also assuming any of this is even intentional on their or anyone's part.

I think you assume that there is even a contract, and that if it did exist, it wouldn't allow this.

Going to court for this would also cost way more than the product is worth.

I disagree, there are many resources for making and distributing android reproducible builds, including third-party F-Droid repos like IzzyOnDroid mentioned in my previous link.

And to my knowledge there is no technical requirement that F-Droid actually needs to build OR sign packages on behalf of anyone... I haven't seen any actual official rationale listed for it, but I assume one of the main reasons is convenience for the developers so they don't have to provide their own builds and deal with signing/losing keys.

I understand that the risk of problems can be somewhat mitigated in F-Droid by using reproducible builds, but I don't consider that sufficient for the most privacy-conscious users because:

• reproducible builds are not required by F-Droid

• it is not made clear to the user that a particular package even supports reproducible builds

• the verification of reproducible builds is not made plainly visible somewhere publicly if at all

• a user can still easily be misled by a one-off rogue package that is NOT reproducible, due to the previous point

• independent verifications of those builds reliably made by others are not common

Conversely I stay clear of F-Droid as they build and sign packages on behalf of the original developers, adding yet another point of injection for malicious code or supply chain attacks.

I wouldn't say they ignore it, it's just that they're too stupid to realize it, or they simply never learned/forgot American history from school.

Blocking non-Mozilla user agents has eliminated 99% of scraping in my experience. I've seen a few larger sites do it as well but not many.

Many teknoparrot games will not run on linux under wine, and a VM without a passthrough GPU cannot do any hardware accelerated rendering on Windows, so without a second GPU or dual-booting into Windows I cannot play them. Recent adobe suite apps also won't work on wine, and many functions use the GPU now like in Photoshop. There's so many things that still don't work in wine or a non-accelerated VM it's not even funny.

Any homeserver that federates (even indirectly) with matrix.org will still have practically all the same data shared with it, just not your password.

https://geekflare.com/run-linux-from-a-web-browser/

Totally not a coincidence this happens at the same time Bibi is accused of puppeting Hamas from the start.

I think they're asking about the text on the website that says "not compatible with VPNs" which I think is a reference to an Android system limitation where you simply must turn off an existing VPN connection to use the app merely because it interferes with the app becoming its own localhost VPN to get around android networking limitations.