- cypherpunks-legacy - lists.cpunks.org

[drone-list] Paul Rogers on drones
by francesca recchia 06 Jul '18

06 Jul '18

Suicide-bombs without the suicides: why drones are so cool http://www.opendemocracy.net/paul-rogers/suicide-bombs-without-suicides-why… -- francesca recchia @kiccovich http://muftah.org/art+culture/ http://www.klatmagazine.com/wanderdust travel-snippets.tumblr.com _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[IP] Websites blocked by political stripes for Marines in Iraq?]
by David Farber 06 Jul '18

06 Jul '18

-------- Original Message -------- Subject: Websites blocked by political stripes for Marines in Iraq? Date: Tue, 07 Mar 2006 07:13:28 -0500 From: Barry Ritholtz <ritholtz(a)optonline.net> To: David Farber <dave(a)farber.net> Hey Dave, I know you prefer to keep things tech focused, rather than political. But then how do we classify this bit of selective internet filtering: Websites blocked by political stripes for Marines in Iraq? Snip from an email sent by an anonymous US Marine to Wonkette: Unfortunately anonomizers don't work out here (never have). Anyway, I had a few minutes today and thought I'd look and see what else was banned on the Marine web here. I think the results speak for themselves: * Wonkette b b Forbidden, this page (http://www.wonkette.com/) is categorized as: Forum/Bulletin Boards, Politics/Opinion.b * Bill ObReilly (www.billoreilly.com) b OK * Air America (www.airamericaradio.com) b b Forbidden, this page (http://www.airamericaradio.com/) is categorized as: Internet Radio/ TV, Politics/Opinion.b * Rush Limbaugh (www.rushlimbaugh.com) b OK * ABC News b The Noteb b OK * Website of the Al Franken Show (www.alfrankenshow.com) b b Forbidden, this page (http://www.airamericaradio.com/) is categorized as: Internet Radio/TV, Politics/Opinion.b * G. Gordon Liddy Show (www.liddyshow.us) b OK * Don & Mike Show (www.donandmikewebsite.com) b b Forbidden, this page (http://www.donandmikewebsite.com/) is categorized as: Profanity, Entertainment/Recreation/Hobbies.b If it wasn't so sad, it would be laughable. Litigation to follow . . . Wonkette via boingboing http://www.boingboing.net/2006/03/06/websites_blocked_by_.html http://wonkette.com/politics/wonkette/our-boys-need-gossip-158687.php Incidentally, Josh Marshall has been discussing what could be an illegal use of the Military for purely political events here: http:// www.talkingpointsmemo.com/archives/week_2006_03_05.php#007808 How can we avoid discussing politics when it seems to intrude everywhere? Barry L. Ritholtz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Big Picture: Macro perspectives on the Capital Markets, Economy, and Geopolitics (with a dash of music and film thrown in!) http://bigpicture.typepad.com/ ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: Relay flooding, confirmation, HS's, default relay, web of trust
by Lucky Green 06 Jul '18

06 Jul '18

On 2010-12-06 09:18, John Case wrote: > > On Mon, 6 Dec 2010, grarpamp wrote: [...] >> Maybe there would also be benefit in a web of trust amongst nodes >> not unlike a keysigning party. As with social networking, people >> vouch for each other in various ways and strengths based on how >> they feel that person meets them. I don't see any reason why node >> operators [descriptors] could not keysign and have that web encoded >> into the descriptors, directories, DHT, etc. > > > I proposed early in the previous thread that not only should a web of > trust be considered, but that this was indeed a classic case of a web of > trust ... I didn't see any comment on this from the Big Names on the > list, though... The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. The WoT cannot provide security benefits to a group of users with no pre-existing social trust relationship, such as the set of "Tor node operators". The thousands of Tor node operators, a tiny percentage of which have an existing social relationship, have no inherent trust amongst each other. And how could they? Absent an existing real-life WoT, there is no digital WoT to codify. Even within a group that has a strong existing trust and social graph in real life, the digital codification of a WoT offers security benefits only at the extreme margins. This fact is easiest explained by example: o Fire up your preferred OpenPGP software. (If you don't have OpenPGP software, then your understanding of how a WoT works is likely different from what a WoT actually does). o Eliminate all public keys for users with whom you do not intend to communicate. (No communication security system can provide security benefits to communications that will never take place). o List the public keys that show as valid. (Meaning they are signed by one or more keys that you trust to some degree). o Eliminate all the public keys that are signed by your key. (Those keys are not authenticated by the WoT, they were authenticated by you directly). o Eliminate all the public keys that are signed by keys that you chose to trust because they are the equivalent of CA root keys. This includes Debian distribution signing keys, the keys of any commercial CA, and the signing keys of auto-responder key servers such as the PGP Global Directory. (Signatures performed by such keys do not employ the WoT). o Look at the small number of public keys remaining. The keys are likely from deep inside your social circle. Now eliminate all the public keys that you could trivially authenticate directly, such as by asking a key holders, who are well known to you, to provide you with their key's fingerprint at work, at the next security conference, or the next time you meet at the pub. (The WoT may have authenticated those keys, but the WoT was not necessary to do so since you could have trivially authenticated those few keys yourself). o Lastly, count the remaining public keys. The number will likely be zero (no real life benefit to the WoT) or close to zero (benefit only in the extreme margins). In summary, the WoT is not a suitable solution to increasing the security of the Tor network. --Lucky Green *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-announce] Tahoe-LAFS-1.8.2 Released!
by Brian Warner 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.2 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The previous stable release of Tahoe-LAFS was v1.8.1, which was released October 28, 2010 [1]. v1.8.2 is a stable bugfix release, adding compatibility with the recently-released Twisted-10.2, and correcting a number of minor issues. See the NEWS file [2] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [4].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the thirteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Google, Inc. sponsored Tahoe-LAFS development as part of the Google Summer of Code 2010. They awarded four sponsorships to students from around the world to hack on Tahoe-LAFS that summer. Thank you to Allmydata and Google for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the seventh release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. Brian Warner on behalf of the Tahoe-LAFS team January 30, 2011 San Francisco, California, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4865 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=5000 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.rst [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=5000 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Relay flooding, confirmation, HS's, default relay, web of trust
by Lucky Green 06 Jul '18

06 Jul '18

On 2010-12-06 09:18, John Case wrote: > > On Mon, 6 Dec 2010, grarpamp wrote: [...] >> Maybe there would also be benefit in a web of trust amongst nodes >> not unlike a keysigning party. As with social networking, people >> vouch for each other in various ways and strengths based on how >> they feel that person meets them. I don't see any reason why node >> operators [descriptors] could not keysign and have that web encoded >> into the descriptors, directories, DHT, etc. > > > I proposed early in the previous thread that not only should a web of > trust be considered, but that this was indeed a classic case of a web of > trust ... I didn't see any comment on this from the Big Names on the > list, though... The Web of Trust (WoT) concept provides for marginal security benefits and then only in a very narrow set of circumstances that are unlikely to hold true for the larger community of Tor node operators. Starting with the second point, the WoT concept presumes that trust between its members precedes the codification of that trust into attestations attached to digital certificates. In other words, the WoT might provide (but likely will not) security benefits to a group of users that have pre-existing social relations and trust. For example, members of a human rights group that have personally known each other, or at least the bulk of each other, for years. The WoT cannot provide security benefits to a group of users with no pre-existing social trust relationship, such as the set of "Tor node operators". The thousands of Tor node operators, a tiny percentage of which have an existing social relationship, have no inherent trust amongst each other. And how could they? Absent an existing real-life WoT, there is no digital WoT to codify. Even within a group that has a strong existing trust and social graph in real life, the digital codification of a WoT offers security benefits only at the extreme margins. This fact is easiest explained by example: o Fire up your preferred OpenPGP software. (If you don't have OpenPGP software, then your understanding of how a WoT works is likely different from what a WoT actually does). o Eliminate all public keys for users with whom you do not intend to communicate. (No communication security system can provide security benefits to communications that will never take place). o List the public keys that show as valid. (Meaning they are signed by one or more keys that you trust to some degree). o Eliminate all the public keys that are signed by your key. (Those keys are not authenticated by the WoT, they were authenticated by you directly). o Eliminate all the public keys that are signed by keys that you chose to trust because they are the equivalent of CA root keys. This includes Debian distribution signing keys, the keys of any commercial CA, and the signing keys of auto-responder key servers such as the PGP Global Directory. (Signatures performed by such keys do not employ the WoT). o Look at the small number of public keys remaining. The keys are likely from deep inside your social circle. Now eliminate all the public keys that you could trivially authenticate directly, such as by asking a key holders, who are well known to you, to provide you with their key's fingerprint at work, at the next security conference, or the next time you meet at the pub. (The WoT may have authenticated those keys, but the WoT was not necessary to do so since you could have trivially authenticated those few keys yourself). o Lastly, count the remaining public keys. The number will likely be zero (no real life benefit to the WoT) or close to zero (benefit only in the extreme margins). In summary, the WoT is not a suitable solution to increasing the security of the Tor network. --Lucky Green *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[tahoe-announce] Tahoe-LAFS-1.8.2 Released!
by Brian Warner 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.2 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The previous stable release of Tahoe-LAFS was v1.8.1, which was released October 28, 2010 [1]. v1.8.2 is a stable bugfix release, adding compatibility with the recently-released Twisted-10.2, and correcting a number of minor issues. See the NEWS file [2] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [4].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the thirteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Google, Inc. sponsored Tahoe-LAFS development as part of the Google Summer of Code 2010. They awarded four sponsorships to students from around the world to hack on Tahoe-LAFS that summer. Thank you to Allmydata and Google for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the seventh release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. Brian Warner on behalf of the Tahoe-LAFS team January 30, 2011 San Francisco, California, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4865 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=5000 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.rst [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=5000 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[IP] Websites blocked by political stripes for Marines in Iraq?]
by David Farber 06 Jul '18

06 Jul '18

-------- Original Message -------- Subject: Websites blocked by political stripes for Marines in Iraq? Date: Tue, 07 Mar 2006 07:13:28 -0500 From: Barry Ritholtz <ritholtz(a)optonline.net> To: David Farber <dave(a)farber.net> Hey Dave, I know you prefer to keep things tech focused, rather than political. But then how do we classify this bit of selective internet filtering: Websites blocked by political stripes for Marines in Iraq? Snip from an email sent by an anonymous US Marine to Wonkette: Unfortunately anonomizers don't work out here (never have). Anyway, I had a few minutes today and thought I'd look and see what else was banned on the Marine web here. I think the results speak for themselves: * Wonkette b b Forbidden, this page (http://www.wonkette.com/) is categorized as: Forum/Bulletin Boards, Politics/Opinion.b * Bill ObReilly (www.billoreilly.com) b OK * Air America (www.airamericaradio.com) b b Forbidden, this page (http://www.airamericaradio.com/) is categorized as: Internet Radio/ TV, Politics/Opinion.b * Rush Limbaugh (www.rushlimbaugh.com) b OK * ABC News b The Noteb b OK * Website of the Al Franken Show (www.alfrankenshow.com) b b Forbidden, this page (http://www.airamericaradio.com/) is categorized as: Internet Radio/TV, Politics/Opinion.b * G. Gordon Liddy Show (www.liddyshow.us) b OK * Don & Mike Show (www.donandmikewebsite.com) b b Forbidden, this page (http://www.donandmikewebsite.com/) is categorized as: Profanity, Entertainment/Recreation/Hobbies.b If it wasn't so sad, it would be laughable. Litigation to follow . . . Wonkette via boingboing http://www.boingboing.net/2006/03/06/websites_blocked_by_.html http://wonkette.com/politics/wonkette/our-boys-need-gossip-158687.php Incidentally, Josh Marshall has been discussing what could be an illegal use of the Military for purely political events here: http:// www.talkingpointsmemo.com/archives/week_2006_03_05.php#007808 How can we avoid discussing politics when it seems to intrude everywhere? Barry L. Ritholtz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Big Picture: Macro perspectives on the Capital Markets, Economy, and Geopolitics (with a dash of music and film thrown in!) http://bigpicture.typepad.com/ ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Re: Hello directly from Jimbo at Wikipedia
by Geoffrey Goodell 06 Jul '18

06 Jul '18

In case it was not painfully obvious, I posted two very critical messages about the policy of Wikipedia with respect to Tor nodes. I sent one of these messages in April and another just a few hours ago. I apologize for my tone in these messages. I contributed nothing of constructive value, and if I accomplished anything it was only to further polarize the community around the two perspectives. I have neither the intellect nor the disposition to be as level-headed about this as I would like to be, but I will try. I would like to make clear that what I intended to say was that as a researcher in the area of Internet transport, I believe that Tor is a crucial first step to achieving location-independence for Internet peers. I believe in location-independence to the extent that I would like to see every host on the Internet have the ability to communicate without revealing its network address. Since my research specifically revolves around using Tor to achieve location-independence, I tend to become overly frustrated when the providers of vital Internet services impose restrictions that may reduce support for Tor among developers and the general public. We ARE on the same side. I don't think that anyone on this list would question that Roger, Nick, and Jimbo have all worked hard to make the world a better place, and that to a significant extent, their visions of a better world have already been achieved as a result of their efforts. In the absence of a better solution, I am glad that Wikipedia blocks Tor nodes, since otherwise the world would quickly lose an important resource (and Tor would be blamed). In particular, the continued success of the Wikipedia project depends upon articles being accurate and unvandalized, and all potential threats to this goal may rightly be considered suspect. What worries me is that as of now we have not yet ensured that users seeking location-independence would be able to edit Wikipedia articles like everyone else. I do not view the use of Tor as a form of "lurking in shadows"; I think that it represents a happier future in which the use of network-layer addresses to censor the activity of Internet peers is difficult or impossible. It is not necessary to build a user-authentication mechanism into Tor. For example, any third party can build a proxy accessible via Tor that provides authentication considered suitable by Wikipedia, and clients can use that proxy when they want to edit Wikipedia articles. A similar approach that has been widely discussed was to build an authentication mechanism into Wikipedia that would be used only for clients contacting Wikipedia via hosts that would otherwise be filtered. The problem with these two potential solutions is that we still do not have a good idea of what kinds of authentication would actually work. For example, it may be undesirable to use credit card numbers or referrals from existing users. Wikipedia seeks to achieve a certain degree of openness and availability to contributors, and it would seem that mechanisms that authenticate and verify pose a threat to this openness and availability. Might it be possible to come up with a list of technical desiderata for a potential end-to-end Wikipedia access policy? It is my feeling that if we consider the requirements carefully, we will be able to devise a solution that satisfies all of our constraints. Geoff On Tue, Sep 27, 2005 at 01:46:13PM -0400, Jimmy Wales wrote: > I'd like to say thanks for the invitation to join this dialogue. > > Let me tell you what I love. I love the Chinese dissident who wants to > work on Wikipedia articles in safety. I love that Wikipedia is an open > platform that allows people to have that voice, and that we can have a > positive impact on the world in large part because we don't bow to > censorship and we are willing to reach out and work with people like Tor > to empower individuals to speak, no matter what sort of oppressive > conditions they face. > > WE ARE ON THE SAME SIDE. > > So it always dismays me to see conversations like this, and I think that > at least some cooler heads here will understand why I get frustrated and > why I make no apologizes for characterizing at least some people in the > Tor community as being irresponsible. > > "I share frustrations that the statements attributed to Jimmy Wales in > the record below and in previous messages seem to show some fundamental > misunderstandings and willful ignorance of Tor, and more broadly of > identity, identifiers, reputation, authentication, etc. in open > network communications" > > Willful ignorance? Not at all. What I know is that we are forced to > block Tor servers regularly due to persistent vandalism. That's a sad > fact to me. It's a difficult thing for those of us who are serious > about these issues. But the really sad thing is when elements of the > Tor community are not willing to face up to this as a legitimate and > difficult problem. > > "everyone is so worried about it, but has any one ever been successfully > been able to use tor to effectively spam anyone?" > > Yes, of course! We deal with it constantly. We have an effective means > of dealing with it: we block Tor servers from editing wikipedia. But is > that what any of us want? > > "Misbehaviour is in the eye of the observer, however." > > No, actually it isn't. There is such a thing as objectively > identifiable malicious behavior. We aren't Chinese censors here. We're > the good guys. We want to work with you. > > Yes, we could implement tight security to only allow people who identify > themselves (perhaps we'll require a credit card number, someone > suggests?)... but *cough*, aren't we supposed to care about privacy here? > > --Jimbo ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Lucrative update
by Patrick 06 Jul '18

06 Jul '18

Lucrative release 4 is out. I know many people are used to seeing releases numbered like "0.000001", "0.000002", "2.0.3.0.14.657" etc. but release numbering systems are essentially arbitrary in nature so don't get excited as Lucrative goes toward version 50+. This release is a fairly minor one, but included some changes such as the client name that I wanted to get out as soon as possible. There is also a new development weblog at http://lucrative.thirdhost.com/weblog/. I went through an install with someone over IRC last night and made a blog entry summarizing the install notes. I recommend reading the notes before attempting an install. I am glad to help with an install, drop me a note at patrick(a)lfcgate.com if you have trouble. Some documentation on the various entities in the Lucrative system is now available on the website, http://lucrative.thirdhost.com/documentation.php but more is needed and coming. If Lucrative is interesting to you, please consider helping in any way you can: Feedback Installation reports Suggestions Comments Criticism Feature requests Source code patches Donations Are all very much welcomed. And criticism is more useful to me than praise. My sincere thanks to everyone who has participated so far by installing, testing, providing feedback, spreading the word, and donating. And finally I just received word from SourceForge that the project registration for Lucrative has been approved. Regards, Patrick -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> mQGiBD5ECKcRBADUvjXHwLtxIyS4AyjBs/dFtN6rdeP18Fhzh1hD5fJwkFevqY9Z I1ASROTh6eXYF7pU5sEvbcPshHyTB41ZtTqZvQvpwWN0fUzOuutuI0mtC5UPp9Rz j47SdWLdEXNHjwnHDCYSyqtqZu8GujGRQybR0eP3NIh/NwbSDUKdgz7IjwCg//Jo UtjP3zUFobm/0UYA+CJ5krED/091x9Js0gwNwvjbzM8DqO+r8qNz0kXI13FkrPRk QNd37lxt6m2m8HZD1WYM2wKwtMzHSwJcWzaDZ/tNc+ppYjzpw0EQCh9FqjGs8Vau guF6PA1M8lJTCcLKaL4e7ynic+PAw5Xa/tdOYgFCG+eLMU5RLvzRCYoOLIjgMJLJ yG98BACAMlDmFVYgC/UKvzZmHfZ5CtCKd8sPfCXrYLu5NeFRE0LR6D6zjzmhi1xX okfreR5o3T/y78VBM98js+m2/+7Z0AElqydeW/RnV1zqwDGjDr9z2MgARf3yLAbs n3BU8Fz61RwvHy6cRkT+2dR2f69QQUSpkupvLwZIGX/iwm4uKLQdUGF0cmljayA8 cGF0cmlja0BsZmNnYXRlLmNvbT6JAE4EEBECAA4FAj5ECKcECwMCAQIZAQAKCRBb mvb9yuOVfaA2AKDAu5tDj9F2KI8cJMrKKkQRAcUyxACg6/bei7lUJH+E5igJqGRx SjKrRA65BA0EPkQIpxAQAPkYoH5aBmF6Q5CV3AVsh4bsYezNRR8O2OCjecbJ3HoL rOQ/40aUtjBKU9d8AhZIgLUV5SmZqZ8HdNP/46HFliBOmGW42A3uEF2rthccUdhQ yiJXQym+lehWKzh4XAvb+ExN1eOqRsz7zhfoKp0UYeOEqU/Rg4Soebbvj6dDRgjG zB13VyQ4SuLE8OiOE2eXTpITYfbb6yUOF/32mPfIfHmwch04dfv2wXPEgxEmK0Ng w+Po1gr9oSgmC66prrNlD6IAUwGgfNaroxIe+g8qzh90hE/K8xfzpEDp19J3tkIt AjbBJstoXp18mAkKjX4t7eRdefXUkk+bGI78KqdLfDL2Qle3CH8IF3KiutapQvMF 6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfUodNQ +PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY72 88kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy 1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XrPdYX AAICD/wKwtF7Y4NKBe8PQ6jDbjWziiTv9Ac/EnRTJDQEoqgLa2LyE+6Ahw/VPGvp mfxkD2MKxC9E7kYVmasn6sHnSpvAv3e7O1Bqbo/qLzzCcJQ5VCurZ+elRM1GZ4Oc fM19FPKutb0/JFEv0nrqS4BGkF7WFBbu5dKYl/GIO7Co1mAerFIb719dOwMPVEIz OT08u8uB9jyR8gEElf+CVuNfOUkrUGg4HS4SbmTTrCSz3/8n5PkquSuAyjCB/dwM ZsZwA0/TTR8sDYlmlf9xPj5PGpGnV9OUwfig6eE0eWtRFeasmz0uiX+yp45ABtNh 6EXP/PFaBgXi9omXXjeeFYfpDvmfA6izvTIQfXTV6V9ZWrBfXarM+GQ+6guXWVbd 9fXvmCr982LkzuKQrK1OpRXBMUapXL+tOy/LYzz91InqKKhgPNGa12fvotZ4LzlM iqoM+Hpz5L9B5We1Ph0lD6RBVXDCqd+P8extnY/7AaDy7tC0UghaAaUuEZXJQPIc oQ3QGbpjM0nGe/VZN5EZhljau0NNENFaU56cOpvOhcO04gLGNNc2NS+rIpTMsaHh o1CG90c5zZZJuUbyx0mIHriNQXDgEwunSZPQorKK9KSppyyjeuOyi5F/mBBPXeyT weLhLqLvAr9se/+Z3aQvMADJi8zUZtGggLTw+N9R5XSwtSh2R4kARgQYEQIABgUC PkQIpwAKCRBbmvb9yuOVfWayAKC+mBhHdn1XZ5uH0RocAyJ32hx2kgCePyhB+IqM TjWLDLarQxcPYhbkFi4= =nx1M -----END PGP PUBLIC KEY BLOCK----- --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0