tolleydbg

~could~?

I aware what the license says, but it doesn't really matter how it's worded or how we would like to interpret it, under US law, this is likely non-binding clause without a release/distribution. The fact that the license mentions release in section 5b makes it clear that either the license wasn't carefully crafted or that this particular edge case isn't what was meant in that clause. If that is what they meant, this seems to violate one of the central tenants of the FSF.

The use of the qualifier 'patent' in the license definitely doesn't clear anything up if Truth Social wasn't released for commercial consumption.

If this was released for consumers, as some above have suggested, then that's a different case, but I haven't seen any evidence of this, not that I spent much time looking.

1. I didn't realize that anyone thought thought the service was launched. I've only seen reporting that it was discovered and defaced. This would make a difference.

2. and 3. The license can say whatever it wants and we can interpret it however we want, but at least for US law, it makes a difference whether or not this constituted a release/distribution to be a binding agreement. Non-binding contracts are not enforceable. If you have reporting that it was used by consumers, then this is different, but this doesn't seem to be the case.

A release and a distribution of a product have almost the same legal definition, but in both cases, the definition includes the product being available "for the consumer." If the license is poorly written to include anything else, then it is likely non-binding. But I think it is clear that his was not a public release for the intended audience, and I think it is entirely relevant what state the site was in when the alleged violations occurred.

I'm not asking about whether or not they violated AGPL on a narrow interpretation of the license from a single clause, but whether that caveat in the license is enforceable in this situation. I'm thinking they will have a hard time showing that this constituted a release or distribution under US law.

I was just wanting someone with more legal experience than me to weigh in.

Section 5, which they are accused of violating, specifically mentions a release of the software in item (b). Item (c) does provide some ambiguity, but given that the access was unauthorized, regardless of how bad the OpSec was in the part of the developers, I can't imagine a judge enforcing a discovery subpoena. They may have had a case that it wasn't malicious access if they didn't use Trump's name as a handle and post "Pig Poop Balls" meme.

Software licenses apply to releases, and it is not clear this a release. This is the legal question I am asking about, i.e. Does the developers making this publicly accessible for testing constitute a release?

It isn't an issue of whether the developers made an error or not, but whether this constitutes a "release". Both in terms of the license, and the general legality of the situation. I think they would have a hard time showing this was.

I think this may be carelessly worded in the article. It was publicly accessible, but I don't think it was intended to be publicly available to anyone who wasn't developing it. Am I misremembering the reporting on this?

I didn't realize that this "test site" was publicly available. I thought it was "discovered".

Shouldn't we wait until it's launched to see if they include the license or not?

I think there is evidence that this is true for some sweeteners, such as Ace K, but I don't think this is the case with aspartame.

NordVPN relocated to the United States late last year.

As a researcher studying VPN security, I have tested a lot of VPN providers, and there are few that stand out as trustworthy. Mullvad is mentioned in this thread several times for a reason. When we publicly disclosed CVE-2019-14899, they had a patch within a day and included it in the release - all within a week. To the best of our knowledge, Mullvad was the only provider and WireGuard was the only protocol to take swift action to mitigate the vulnerability.

This comment is only about the trustworthiness of the provider and not of VPNs in general, which I'm still hesitant about. I'll provide a link for our paper exploring CVE-2019-14899 and attacks we've developed since then:

https://www.usenix.org/system/files/sec21-tolley.pdf

There's also a blog post, which is quicker to read and written for a general tech audience:

https://breakpointingbad.com/2020/05/25/Vintage-Protocol-Non...

Each connection is NATed through the VPN though and the fact that the port number does not change makes it possible to make inferences about connections a user has made through the tunnel and inject arbitrary data into the connections.

https://www.usenix.org/system/files/sec21-tolley.pdf

200,000 Americans aren't dead because of something they read on Facebook.

Donenfeld has been great and makes a wonderful product. We've been using WireGuard as our primary VPN solution for a long time now and don't anticipate a change anytime soon.

I think this class of attack can best be mitigated at the kernel level, but unfortunately, side-channels exist anywhere that maintains state, and this might be a more general routing problem.

Correct. It does completely prevent the attack for IPv4, however, so we didn't notice the attack until the rp_filter settings were changed.

I can verify that turning rp_filter on in my use case is an acceptable solution on Manjaro and Ubuntu.

EDIT: To clear up the confusion below, I was saying that setting the rp_filter variable to strict mode does prevent this attack from working against IPv4, and in my situation, this is enough since I am not using IPv6 or any complicated routing on my network etc.

This seems like the most popular solution, but there are concerns that it may disrupt routing, and also does not work on -some- systems.

Hi Colm, were still working on a response to your email, but we appreciate the insight you provided and look forward to our conversation.

This disclosure only deals with the specific threat against active TCP connections, but there are more coming.

Yes, it is correct that you cannot easily hijack connections that use TLS, but you can make inferences about active connections that use TLS. This is still fairly devastating for a large number of vulnerable users that rely on VPNs in nations with authoritarian information controls.