Re:Wonder if Bit.ly is still happy about their URL
on
Libyan Internet Flatlined
·
· Score: 5, Informative
Root servers for the ly TLD:
dns.lttnet.net
auth02.ns.uu.net
ns-ly.ripe.net
phloem.uoregon.edu
dns1.lttnet.net
All of these would have to inoperable before all.ly domains would stop resolving, and there's still the matter of caching at intermediate DNS servers until the TTL expires for records. Additionally, bit.ly isn't hosted within Libya. In short, I don't expect bit.ly to be going down over this.
Where, precisely, in that post did I mention LOIC? To put it simply, anyone using that particular method to participate in a DDoS attack is a moron, and deserves what's coming to him. However, since you mentioned the civil aspect of this issue, I'll once again wish you "good luck" in getting any compensation whatsoever out of anyone actually subject to a civil penalty in such a case. Your armchair lawyering aside, history has more than adequately demonstrated the folly of what you're advocating. Oh, and don't forget about the technical consultation fees required to actually get beyond the "reasonable doubt" aspect of the case, the sheer enormity of the number of potential defendants you'll need to chase down, the legal fees involved in putting the matter through the courts (time isn't free, even if you're an attorney yourself), additional repercussions and continued attacks from those who are displeased by such actions, etc.
If they have anyone technically competent around it would be trivial for them to identify and sue participants in a DDOS, ADDING to their cash flow.
You've just demonstrated a severe lack of knowledge about the basics of DDoS operations. It is most assuredly not trivial, especially when tens of thousands of compromised machines owned by people who are barely aware of the location of the power switch are involved. Even assuming a handful of folks were stupid enough to carry this out in a manner that were to permit their apprehension, there are probably going to be jurisdictional issues to contend with (likely crossing national borders), coupled with the age old adage that "you can't get blood out of a stone." In other words, good luck identifying any actual willful participant, and good luck getting any money out of said person should you manage to drag him into court.
And yeah, don't worry, they're not going to abide by the licensing terms so they aren't going to be considered a part of your community anyway.
You're missing a point here, actually. To use the GPL as an example, those who modify the code are not required to make those changes public unless they're distributing the code outside their organization. For large government entities, well, those are very large organizations. It doesn't mean they're violating the terms of the license at all.
Additionally, I've been a direct observer of code produced within a government agency being contributed back upstream. You're probably going to want to split hairs by replying with something like "oh but some governments will still find ways to break the license," but that would just make you guilty of the same behavior you just accused the GP of displaying.
Wrong. Only a very small subset (GPL and its derivatives) of the Open Source licenses actually require you to share your source with your binaries. Most (BSD, MIT, Apache, MPL, zlib) don't.
That's a very misleading statement. While there are tons of OSI-approved licenses, and many others that haven't been subjected to any formal review criteria, I'd love to see statistics on how many projects use licenses that require code sharing versus those that don't. Given the enormous growth in popularity of the GPL alone over the last decade alone, and my personal memory of over 20 years of open source and free software, I strongly suspect the number of projects that require sharing code will dwarf the alternative.
In fact, the GPL seems to have become the "default" license for free software in many respects, even though many people who license their code under the GPL honestly don't understand the license at all (that comes directly from my personal interactions with lots of developers). This is an unfortunate state of affairs from some perspectives, but it's reality. I license the majority of my code under BSD-style licenses, but I freely (haha, I'll be here all week, tip your waiter, try the veal) admit that I'm most likely in the minority these days.
And of course the ever-popular "consider changing banks". Do you really trust them as much with your money as you did before?
Do you really trust any other financial institution with your money more than you trust them? These issues are systemic, not isolated to one or even a handful of financial services firms. You might be surprised to know how many such events occur, but are never properly disclosed.
WinMTR contains code from mtr (contrary to their claims, see the original story for matching code excerpts), which they have no rights to. Therefore, they do not own the WinMTR codebase, and are still bound by the GPL.
The problem is that there is code from mtr in WinMTR, an example of which can easily be seen in the original story. Appnor never purchased (nor could they, unless they contacted every contributor and came to a bunch of agreements) the rights to the mtr codebase. I suspect what actually occurred is that Appnor was misled to believe that WinMTR didn't contain any mtr code, and subsequently believed they were purchasing the rights to WinMTR. Again, it does contain mtr code, so they don't own it to begin with.
Read my other reply to you on this. To summarize: Appnor claims they bought the code from the WinMTR maintainer, not the original mtr author, and they're either lying or negligent in their assumption that WinMTR didn't contain any mtr sources.
They did not buy the code from the original mtr maintainer. I've been in contact with the current maintainer, as is clearly referenced in the original article, and he has clearly stated that if (as has been demonstrated) WinMTR uses mtr sources, it's a clear GPL violation. Appnor is claiming that they purchased the rights to the code from the WinMTR maintainer. How did you manage to miss that?
Now, it's possible that the WinMTR maintainer simply lied to Appnor, and claimed that there was no mtr code in the project. That's a pretty bold assertion, given the history of both projects, and it's been proven to be false. Failure on Appnor's part to perform even a cursory diff of the WinMTR and mtr sources is, at best, gross negligence. Basically, what it comes down to is this: Appnor doesn't own the code at all, and they're either lying or negligent.
Did you bother to read the code in that comment on the forum post? It's evidence of verbatim code from mtr sources found in WinMTR sources. Why don't you try comparing the sources yourself, instead of idly claiming that there's no proof? You obviously couldn't be bothered with facts, right?
For the sake of clarity, I'll reproduce my earlier reply to that statement here:
"As others have noted, several people have apparently found mtr sources in WinMTR. This means either (1) you've been misinformed, (2) you're deliberately lying, or (3) they're lying. Given that people have posted actual code excerpts to back up their claims, I strongly suspect you're lying."
As others have noted, several people have apparently found mtr sources in WinMTR. This means either (1) you've been misinformed, (2) you're deliberately lying, or (3) they're lying. Given that people have posted actual code excerpts to back up their claims, I strongly suspect you're lying.
The story is from an Australian news site. The term "kit" in this context is synonymous with "components." Depending on their intended purpose, individual components can be quite expensive; I've held fairly small circuit board assemblies in my hand that were worth $30,000 USD apiece. It is entirely believable that this guy stole $1M worth of gear using a small bag.
Root servers for the ly TLD:
All of these would have to inoperable before all .ly domains would stop resolving, and there's still the matter of caching at intermediate DNS servers until the TTL expires for records. Additionally, bit.ly isn't hosted within Libya. In short, I don't expect bit.ly to be going down over this.
I've been had.
Where, precisely, in that post did I mention LOIC? To put it simply, anyone using that particular method to participate in a DDoS attack is a moron, and deserves what's coming to him. However, since you mentioned the civil aspect of this issue, I'll once again wish you "good luck" in getting any compensation whatsoever out of anyone actually subject to a civil penalty in such a case. Your armchair lawyering aside, history has more than adequately demonstrated the folly of what you're advocating. Oh, and don't forget about the technical consultation fees required to actually get beyond the "reasonable doubt" aspect of the case, the sheer enormity of the number of potential defendants you'll need to chase down, the legal fees involved in putting the matter through the courts (time isn't free, even if you're an attorney yourself), additional repercussions and continued attacks from those who are displeased by such actions, etc.
Once again, "good luck with that."
If they have anyone technically competent around it would be trivial for them to identify and sue participants in a DDOS, ADDING to their cash flow.
You've just demonstrated a severe lack of knowledge about the basics of DDoS operations. It is most assuredly not trivial, especially when tens of thousands of compromised machines owned by people who are barely aware of the location of the power switch are involved. Even assuming a handful of folks were stupid enough to carry this out in a manner that were to permit their apprehension, there are probably going to be jurisdictional issues to contend with (likely crossing national borders), coupled with the age old adage that "you can't get blood out of a stone." In other words, good luck identifying any actual willful participant, and good luck getting any money out of said person should you manage to drag him into court.
tl;dr version == Ha, good luck with that.
In addition to my previous reply, I went to the trouble of finding some open source license adoption statistics for you. I'm sure there are bunches of other data sources available via Google.
I'm not disagreeing with what you've said, but I will point out that security is a process, not a product. It's never "done."
And yeah, don't worry, they're not going to abide by the licensing terms so they aren't going to be considered a part of your community anyway.
You're missing a point here, actually. To use the GPL as an example, those who modify the code are not required to make those changes public unless they're distributing the code outside their organization. For large government entities, well, those are very large organizations. It doesn't mean they're violating the terms of the license at all.
Additionally, I've been a direct observer of code produced within a government agency being contributed back upstream. You're probably going to want to split hairs by replying with something like "oh but some governments will still find ways to break the license," but that would just make you guilty of the same behavior you just accused the GP of displaying.
Wrong. Only a very small subset (GPL and its derivatives) of the Open Source licenses actually require you to share your source with your binaries. Most (BSD, MIT, Apache, MPL, zlib) don't.
That's a very misleading statement. While there are tons of OSI-approved licenses, and many others that haven't been subjected to any formal review criteria, I'd love to see statistics on how many projects use licenses that require code sharing versus those that don't. Given the enormous growth in popularity of the GPL alone over the last decade alone, and my personal memory of over 20 years of open source and free software, I strongly suspect the number of projects that require sharing code will dwarf the alternative.
In fact, the GPL seems to have become the "default" license for free software in many respects, even though many people who license their code under the GPL honestly don't understand the license at all (that comes directly from my personal interactions with lots of developers). This is an unfortunate state of affairs from some perspectives, but it's reality. I license the majority of my code under BSD-style licenses, but I freely (haha, I'll be here all week, tip your waiter, try the veal) admit that I'm most likely in the minority these days.
And of course the ever-popular "consider changing banks". Do you really trust them as much with your money as you did before?
Do you really trust any other financial institution with your money more than you trust them? These issues are systemic, not isolated to one or even a handful of financial services firms. You might be surprised to know how many such events occur, but are never properly disclosed.
WinMTR contains code from mtr (contrary to their claims, see the original story for matching code excerpts), which they have no rights to. Therefore, they do not own the WinMTR codebase, and are still bound by the GPL.
The problem is that there is code from mtr in WinMTR, an example of which can easily be seen in the original story. Appnor never purchased (nor could they, unless they contacted every contributor and came to a bunch of agreements) the rights to the mtr codebase. I suspect what actually occurred is that Appnor was misled to believe that WinMTR didn't contain any mtr code, and subsequently believed they were purchasing the rights to WinMTR. Again, it does contain mtr code, so they don't own it to begin with.
Copyright lasts a lot longer than you think.
Thank you very much for noting the update. I've updated the story on my end to reference it as well.
Read my other reply to you on this. To summarize: Appnor claims they bought the code from the WinMTR maintainer, not the original mtr author, and they're either lying or negligent in their assumption that WinMTR didn't contain any mtr sources.
They did not buy the code from the original mtr maintainer. I've been in contact with the current maintainer, as is clearly referenced in the original article, and he has clearly stated that if (as has been demonstrated) WinMTR uses mtr sources, it's a clear GPL violation. Appnor is claiming that they purchased the rights to the code from the WinMTR maintainer. How did you manage to miss that?
Now, it's possible that the WinMTR maintainer simply lied to Appnor, and claimed that there was no mtr code in the project. That's a pretty bold assertion, given the history of both projects, and it's been proven to be false. Failure on Appnor's part to perform even a cursory diff of the WinMTR and mtr sources is, at best, gross negligence. Basically, what it comes down to is this: Appnor doesn't own the code at all, and they're either lying or negligent.
Unfortunately, Appnor's claim appears to be a lie, as WinMTR contains code from mtr.
There's code from mtr in WinMTR.
Did you bother to read the code in that comment on the forum post? It's evidence of verbatim code from mtr sources found in WinMTR sources. Why don't you try comparing the sources yourself, instead of idly claiming that there's no proof? You obviously couldn't be bothered with facts, right?
Worse, there actually appears to be code directly copied from mtr in the WinMTR codebase, which contradicts Appnor's current claim that it was independently developed.
For the sake of clarity, I'll reproduce my earlier reply to that statement here:
"As others have noted, several people have apparently found mtr sources in WinMTR. This means either (1) you've been misinformed, (2) you're deliberately lying, or (3) they're lying. Given that people have posted actual code excerpts to back up their claims, I strongly suspect you're lying."
As others have noted, several people have apparently found mtr sources in WinMTR. This means either (1) you've been misinformed, (2) you're deliberately lying, or (3) they're lying. Given that people have posted actual code excerpts to back up their claims, I strongly suspect you're lying.
You've misunderstood the article. See my other reply on the topic.
The story is from an Australian news site. The term "kit" in this context is synonymous with "components." Depending on their intended purpose, individual components can be quite expensive; I've held fairly small circuit board assemblies in my hand that were worth $30,000 USD apiece. It is entirely believable that this guy stole $1M worth of gear using a small bag.
No. GTFO.
They've done worse, and let's not forget about the ongoing saga of the Celeron.