July 2018 - cypherpunks-legacy

C-13, O-17 Responsible for all (?) CO2 Greenhouse effect
by S W BELL 06 Jul '18

06 Jul '18

My name is James Dalton Bell. (MIT BS Chemistry, 1980). In late June 2009 I concluded that only the portion of the molecules of CO2 containing either a carbon-13 atom (1.1% of carbon in nature) or an oxygen-17 atom (0.038% of oxygen in nature) is responsible for most or all of the 'greenhouse effect' commonly attributed to CO2. In late July 2009 I wrote letters to Al Gore, 40 foreign embassies in Washington DC, and about 30 Congressional committees and government agencies (NIST; DOE) describing this. I stated that it would be relatively easy to remove the C-13 from natural gas and coal (via Fischer-Tropsch reaction, etc), and possibly from petroleum as well. In addition, oxygen could be distilled to remove most O-17 isotope in fixed applications (power plants). In December 2009 I wrote two certified letters (each) to Al Gore and Obama. So far, none of my letters have been answered. You can imagine the implications of this discovery. The problem, to the extent it may exist, is easily solved. Please help me confirm and publicize this news. Thank you.

1 0

[Politech] Two new bills in Congress: Net neutrality, audio broadcast flag [ip]
by Declan McCullagh 06 Jul '18

06 Jul '18

News article: http://news.com.com/2100-1028_3-6045225.html "Digital radio receivers without government-approved copy-prevention technology likely would become illegal to sell in the future, according to new federal legislation announced Thursday." Bill text: http://www.politechbot.com/docs/ferguson.audio.flag.bill.030206.pdf News article: http://news.com.com/2100-1028_3-6045330.html "Network operators would be barred from blocking or degrading Internet connections and favoring those of companies that pay for peppier access, according to a Senate bill introduced Thursday." Bill text: http://www.politechbot.com/docs/wyden.net.neutrality.bill.030206.pdf -Declan _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[cryptography] Bitcoin in endgame
by ianG 06 Jul '18

06 Jul '18

On the crypto topic that everyone loves to hate, Bitcoin, the expected attack has begun. http://financialcryptography.com/mt/archives/001363.html Philipp Guering and I wrote a paper that explains how this will fall out. http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Although in the big picture, this is more about finance not cryptography, there is an engaging question - can cryptography be used to control this sort of issue? It didn't work for Bitcoin, but more judicious uses of crypto can do a lot better, and has done with other designs. The challenge is to get the balance right. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[Politech] Two new bills in Congress: Net neutrality, audio broadcast flag [ip]
by Declan McCullagh 06 Jul '18

06 Jul '18

News article: http://news.com.com/2100-1028_3-6045225.html "Digital radio receivers without government-approved copy-prevention technology likely would become illegal to sell in the future, according to new federal legislation announced Thursday." Bill text: http://www.politechbot.com/docs/ferguson.audio.flag.bill.030206.pdf News article: http://news.com.com/2100-1028_3-6045330.html "Network operators would be barred from blocking or degrading Internet connections and favoring those of companies that pay for peppier access, according to a Senate bill introduced Thursday." Bill text: http://www.politechbot.com/docs/wyden.net.neutrality.bill.030206.pdf -Declan _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[cryptography] Bitcoin in endgame
by ianG 06 Jul '18

06 Jul '18

On the crypto topic that everyone loves to hate, Bitcoin, the expected attack has begun. http://financialcryptography.com/mt/archives/001363.html Philipp Guering and I wrote a paper that explains how this will fall out. http://iang.org/papers/BitcoinBreachesGreshamsLaw.pdf Although in the big picture, this is more about finance not cryptography, there is an engaging question - can cryptography be used to control this sort of issue? It didn't work for Bitcoin, but more judicious uses of crypto can do a lot better, and has done with other designs. The challenge is to get the balance right. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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: [drone-list] Wired on future US military war gaming
by John Young 06 Jul '18

06 Jul '18

This appears more of the long-running bedazzlement of the public which war gaming and futuristic toy-like killiing and harming gadgets was invented to do. If Wired had no criticism of this it should be ashamed. As should Brookings a once ethical organization. Wired might give up its threat level strutting and turn to more civilizing coverage, with less war porn. Sure readers will have to weaned from the narcotic of play with yourself war and that will be tough with the rise of masturbatory digital gaming so essential to train gullible warriors to do what no sane person would do if they visited VA hospitals grotesqueries instead of TV-watching bury-the-evidence glorification cemetaries. Drone pilots are as evil as SEALs and special ops in their willing participation in political PR stunts of murdering innocents under orders from distancing executive branch officers. War gamers and gadget inventors and their media-amoralists are shamelessly exploiting the WMD heritage of amoral technology and propaganda aided by NGOs as diabolcial as GOs camouflaged by national security inviolable sacred cow protected by secrecy. US titanic export of arms pays for these diverting games and these obsequious media dressed in hipster cammies, Perhaps unwrite this very list of friendly fire. At 10:31 AM 8/29/2012, you wrote: > Wired (Aug 24) - "From Bug Drones to Disease Assassins, Super Weapons > Rule U.S. War Game" by <http://twitter.com/daxe>@daxe: > <http://www.wired.com/dangerroom/2012/08/future-warfare/all/>http://www.wired.com/dangerroom/2012/08/future-warfare/all/ > > Drones feature prominently in all of the mid-future war gaming scenarios > presented, including insectoid, tire-eating drone swarms deployed to > disable the vehicles of enemy combatants.B It is assumed that the > drones of 2025 will have much greater autonomy and be deployed in much > greater numbers. > > The war gaming event was organized by an Australian consulting firm, > <http://www.noeticgroup.com/>The Noetic Group.B Yet it seems to have > been run in conjunction with the Brookings Institution; John V, do you > have any insight?B Two representatives from Brookings are mentioned in > the article, Peter W. Singer [ > <http://twitter.com/peterwsinger>@peterwsinger ] and Allan Friedman [ > <http://twitter.com/allanfriedman>@allanfriedman ].B Mr. Singer is an > interesting fellow, and a prominent voice in a CBC documentary I watched > recently and highly recommend, Remote Control War. > <http://www.cbc.ca/documentaries/doczone/2011/remotecontrolwar/>http://www.cbc.ca/documentaries/doczone/2011/remotecontrolwar/ > > gf > > -- > Gregory Foster || <mailto:gfoster@entersection.org>gfoster(a)entersection.org > @gregoryfoster <> > <http://entersection.com/>http://entersection.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. _______________________________________________ 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

[tahoe-lafs-weekly-news] TWN 43
by Patrick R McDonald 06 Jul '18

06 Jul '18

====================================================== Tahoe-LAFS Weekly News, issue number 43, March 18 2013 ====================================================== Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. If you would like to view the "new and improved" TWN, complete with pictures; please take a `look`_. .. _Tahoe-LAFS: https://tahoe-lafs.org .. _View TWN on the web: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news .. _look: https://tahoe-lafs.org/~marlowe/TWN43.html Announcement and News ===================== Tahoe-LAFS Users Group Meeting, San Francisco, Tuesday 2013-03-19 ----------------------------------------------------------------- There is a `Tahoe-LAFS Users Group meeting`_ this Tuesday in San Francisco. A big thank you to `Rackspace`_ |Rackspace| for providing the space and the food from Goat Hill Pizza. There are three items on the agenda: announcing Tahoe-LAFS v1.10, Tahoe-LAFS for engineers who don't care about security and what should we put into Tahoe-LAFS v1.11? If you are in the area, I highly encourage you to make the meeting. It will be a blast. .. _`Tahoe-LAFS Users Group meeting`: https://tahoe-lafs.org/pipermail/tahoe-dev/2013-March/008092.html .. _`Rackspace`: http://www.rackspace.com .. |Rackspace| image:: logo-rackspace.png :height: 35 :alt: Rackspace :target: http://www.rackspace.com Public Grid Gaining Traction ---------------------------- As described later in the newsletter, the public grid is gaining some traction. The public grid provides a space for users new to Tahoe-LAFS a safe space for expermination and learning. I personally would like to extend a thank you to Paul Rabahy and the other volunteers for providing this service. If you can spare a node, please donate it to the public grid. You will be helping Tahoe-LAFS grow. Tahoe-LAFS on ReDonate ---------------------- JoePie91 who runs the `Cryto Coding Collective`_ and its associated grid has established a new site, `ReDonate`_ "ReDonate is a service for 'voluntary recurring donations'. What this means in simple terms, is that we allow you to set up recurring donations to a service, without ever making an automatic charge. ReDonate works much like a calendar application - every month, you'll receive an e-mail reminding you of your pledge. The e-mail will include donation links, so that you can make the donation you pledged, straight away. If you want to skip a month or even unsubscribe from a donation campaign, that's fine! There are no hoops to jump through, no cancellation periods, and no other kinds of hassle involved. Basically, it's recurring donations how they were intended - as a voluntary periodic contribution to a campaign. No automatic charges, no subscription lock-ins, no other nasty things." [`0`_] Tahoe-LAFS is proud to be one of the initial campaigns along with `Torservers`_ and others. Thank you to JoePie91 for running this service. .. _`Cryto Coding Collective`: http://cryto.net .. _`ReDonate`: http://redonate.net .. _`0`: http://redonate.net/about .. _`Torservers`: http://torservers.net Greenqloud Starts Test Grid --------------------------- A wonderful thing happened on Twitter. While discussing using `Duplicati's`_ ability to use Tahoe-LAFS as part of my backup solution, my friend w03 stated he `would like to setup a test grid`_ at his employer, `Greenqloud`_ |Greenqloud|. He tweeted he needed to run the idea past management in the morning. Here was Greenqloud's response "just do it" [`1`_] Thank you to Greenqloud for being open to exploring Tahoe-LAFS. We appreciate it. Looking forward to any feedback you can provide. .. _`Duplicati's`: http://http://www.duplicati.com/ .. _`would like to setup a test grid`: https://twitter.com/w03_/status/313361436975968257 .. _`Greenqloud`: http://greenqloud.com/ .. _`1`: https://twitter.com/Greenqloud/status/313370865565855744 .. |Greenqloud| image:: greenqloud-logo.png :height: 35 :alt: Greenqloud :target: http://greenqloud.com: Weekly Dev Chat Meeting Notes ============================= Below are Zooko's `meeting minutes`_ from the `Weekly Dev Chat`_. in attendance: Oleksandr, Zooko (scribe), David-Sarah, Randall "ClashTheBunny" Mason, Brian (lateone lash), Tony (lateone lash) not in attendance: Andrew (ABSENTtwo lashes) sort-of-in-attendance (on the IRC channel): a lot of folks Agenda: Tahoe-LAFS v1.10 (Nuts and Bolts) SUMMARY: This was awesome. We got lots of tickets closed, or at least pushed forward a step or two. This was the most productive hour of ticket-closing work ever. We're going to do it again next week! If you like doing code-review and writing unit tests, you should join us. DETAILS: You can see also use the Trac Timeline: https://tahoe-lafs.org/trac/tahoe-lafs/timeline ClashTheBunny has some patches for IPv6 for Tahoe-LAFS and Foolscap (#867), and has some tests of them but needs more thorough tests. However, we didn't look at that this time, because we focused on tickets for Tahoe-LAFS v1.10. Nejucomo said on IRC that he wasn't going to get around to manually verifying that the bug we fixed in ticket #1679 was the same as the bug he reported. I decided to just close the ticket for the following reasons: there *is* a bug that we understand, there is a fix which is clear, there is a unit test that exercises the bug that is red without the fix and green with the fix, and The Dod manually verified that it fixed the problem in practice for him. The only reason we've left the ticket open waiting for Nejucomo to test is in case Nathan actually has a *different* bug than this one. But we don't need to keep the ticket open for that eventuality. ClashTheBunny did design review on #1732. He approved the design and made good comments that showed that he actually had thought about it. Subsequently Zooko added another design question and assigned it to Brian for design re-re-re-review. We looked at #1926. It is a blocker because it makes the SFTP frontend incompatible with the current stable release of Twisted. However it is closed as a duplicate of #1525 because the improvement in #1525 would remove the incompatibility. We briefly considered kludging it by requiring people to install an older Twisted, but instead decided to fix it the good way. David-Sarah had already implemented the fix to #1525 but there was something wrong with the unit test. NEWFLASH! This just in! As we were going to press, David-Sarah posted on #1525 a comment that they are currently working on it. We discussed #1767. David-Sarah had an idea for how to make the implementation simple, by incrementing the server-wide counter once for each service. Brian will work on it. It and #1732 are the two blockers that require new code to be written before we release Tahoe-LAFS v1.10. We closed #1484 as fixed. Yay! #1746 is finished, reviewed, and ought to go into Tahoe-LAFS v1.10, but I can't figure out how to merge it into master using git. I don't understand how to use git very well, since I've only been using it on a daily basis for a little more than two years now... #1812 was already applied, but there was something wrong with it according to Brian. Do we need to fix that as a blocker for 1.10 release? We agreed to drop support for Python 2.5 and therefore for CentOS 5. In the last few minutes of the hangout, we agreed that next week's hangout will be another Nuts And Bolts like this one, hopefully bringing Tahoe-LAFS v1.10 close to completion. Brian will work on #1767. Someone (maybe Zooko??) will work on #1732. Then we briefly mentioned the possibility of switching from a "semantic versioning" style version number, to a YEAR.RELEASE_COUNT version number like Twisted does. So instead of Tahoe-LAFS v1.10, this might be Tahoe-LAFS v13.0. Then if there is another release in 2013, that would be Tahoe-LAFS v13.1. We also considered leaving it alone for the "v1.10" release, and switching styles for the next release. Currently we use the "1." in "Tahoe-LAFS v1.10" to mean that it has backward-compatibility with all of the stable Tahoe-LAFS releases since v1.0 (released March 25, 2008: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc#TheParadeofReleaseNotes ). I'm not sure that's accurate. While we have never deliberately violated that goal, and we are not aware of any change that we've made which would break that compatibility, on the other hand we don't have automated or manual testing of backwards compatibility. Anyway, I suspect that there aren't any users of Tahoe-LAFS versions older than 1.9.2: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OSPackages tickets mentioned in this letter: * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/867# use ipv6 * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1484# CLI: overzealous quoting of error messages * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1525# SFTP: handle download failures correctly; remove use of IFinishableConsumer * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1679# Nondeterministic NoSharesError for direct CHK download in 1.8.3 and 1.9.1 * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1732# consider changes to webapi "Move" API before release * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1746# write test for anti-Ubuntu-crash-reporter exception-catching code * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1767# update Announcement "timestamp": sequence number? * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1812# parse_abbreviated_size doesn't accept T for terabytes (and other quibbles with the regex it uses) * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1926# Failed to load application: cannot import name IFinishableConsumer .. _`meeting minutes`: https://tahoe-lafs.org/pipermail/tahoe-dev/2013-March/008082.html .. _`Weekly Dev Chat`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/WeeklyMeeting Monthly State of the Public Grid ================================ Below is Paul Rabahy's `monthly status of the public grid`_. "The new public grid appears to be gaining traction quite well. I figure now that it has been in operation a little more than a month it would be good to give a quick overview of its status and any other observation that I have had. I want to thank the storage nodes that have been reliably connected including the following: claude kapiteined rebuilder_tx PRabahy wander pubgrid-ecd10741 The public writable test directory has been used by several people (including myself) for various experiments. So far I haven't noticed any abuse." "Currently the shares directory on the PRabahy node weighs in at about 650MB. The largest individual share is about 172MB (~25% of the total stored). I encourage everyone that is able to setup a storage node to help newcomers dive into Tahoe-LAFS as easily as possible. My goal is to have at least 10 storage nodes connected to the public grid at any time. Warning - The public grid is a service provided for experimentation and learning. Please do not store any important files on the public grid. The grid may go offline at anytime without prior notice." .. _`monthly status of the public grid`: https://tahoe-lafs.org/pipermail/tahoe-dev/2013-March/008080.html Glowing Quotes ============== This issue's glowing quote is a little different. It comes from inside Tahoe-LAFS, but I feel it really hits on something really awesome about Tahoe-LAFS. "A 20-minute demo of installing the Tahoe-LAFS software, deploying a grid of storage servers, using them to upload, download and browse files. Then the punch line: did you notice what we *didn't* do during this demo? Screw around with certificates, keys, encryption, or decryption! You don't have to spend your time messing with that stuff in order to use Tahoe-LAFS." - Zooko Wilcox-O'Hearn [`2`_] .. _`2`: https://tahoe-lafs.org/pipermail/tahoe-dev/2013-March/008092.html Tahoe-LAFS on Twitter ===================== Awesome, my UI redesign finally landed in @tahoelafs: https://github.com/tahoe-lafs/tahoe-lafs/commit/709be93a29e20026e61a436dac3…" [`3`_] .. _`3`: https://twitter.com/bascule/status/313347964485648384 Patches Needing Review of the Week ================================== There are five (5) ticket still needing review for 1.10.0: * `#1713`_: redesigned welcome page * `#1761`_: Insufficient documentation about how to administer the convergence secret * `#1159`_: stop using .tac files: make it possible to change appname, Python package-directory name, perhaps other names * `#166`_: command line order is problematic * `#1539`_: stop putting pkg_resources.require() into .tac files There are six (6) tickets still needing review of 1.11.0: * `#1818`_: leasedb: track leases in a sqlite database, not inside shares * `#1265`_: New Visualizer is insufficiently labelled/documented (plus layout problem) * `#1864`_: turn off the AUTOINCREMENT feature in our use of sqlite? * `#1411`_: sftp server does not accept pubkey auth * `#1807`_: cleanup: HUMAN_RE regexes in uri.py are never used * `#1382`_: immutable peer selection refactoring and enhancements .. _`#1713`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1713 .. _`#1761`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1761 .. _`#1159`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1159 .. _`#166`: https//tahoe-lafs.org/trac/tahoe-lafs/ticket/166 .. _`#1539`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1539 .. _`#1818`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1818 .. _`#1265`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1265 .. _`#1864`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1864 .. _`#1411`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1411 .. _`#1807`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1807 .. _`#1382`: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1382 ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS* *Software Foundation, President and Treasurer: Peter Secor* |peter| *. Scribes: Patrick "marlowe" McDonald* |marlowe| *, Zooko Wilcox-O'Hearn* |zooko| *, Editor Emeritus: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* `marlowe(a)antagonism.org`_ * submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org .. |peter| image:: psecor.jpg :height: 35 :alt: peter :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |marlowe| image:: marlowe-x75-bw.jpg :height: 35 :alt: marlowe :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs .. |zooko| image:: zooko.png :height: 35 :alt: zooko :target: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AboutUs _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- 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

Anonymity through decentralization (was Re: Ultimate solution)
by Roger Dingledine 06 Jul '18

06 Jul '18

On Sun, Mar 25, 2007 at 09:57:20AM -0600, Arrakis wrote: > 2) Torpark is not commercial, it is totally free and open source. We > simply offer an upgrade to get higher speeds than the tor network can > provide. > > 3) The fact that trust isn't distributed is a positive, not a > negative, because you don't have to trust everyone with your outgoing > plaintext traffic. We have independent security auditors make sure our > admins are not tracking anyone or doing anything malicious. I'm leaving the licensing discussion alone for now, but I wanted to respond to this technical point. Tor's security [1] comes from two components. The first is its large and diverse user base -- as the user base expands, the mere use of Tor doesn't narrow you down to a specific user community or specific few people who are known to have fetched the program [2]. The second is the diversity of the relays -- as the Tor network expands, fewer adversaries are able to be in enough places on the network to succeed at linking senders to recipients. Now, it's still an open research question what metrics we should use for these components (that is, how exactly we measure the security we get from them), but my intuition is that after a certain point the first component doesn't contribute much more to security -- meaning in Tor's current state, its security grows primarily as the network grows. And remember that by "being in enough places", I mean being in a position to watch (or otherwise measure [3]) the traffic; the best attacks we know right now only look at characteristics of the traffic flow [4], because any sort of coordinated compromise of many relays is probably harder. I'm not saying Tor's design is perfect. We are still grappling with Sybil attack questions, and as you say we need to encourage our users to employ end-to-end encryption and authentication when appropriate. And we're still not happy that a widely dispersed attacker can probably do very well against Tor. But a central organization that administers all the relays, even if it puts them in different places geographically, and even if it promises to do perfect audits and employ only perfect people, aims for a fundamentally different sort of security than Tor aims to provide. The traffic analysis attacks above are still just as much of a concern, but insider attacks and other attacks on/by the organization are now a significant question too. You can launch a new single-hop proxy service, commercial or not, proprietary or not. You can also launch a multi-hop service where you control every hop. And the license of the Tor software lets you use it if you find it useful for your purposes. But please don't deceive your users by changing the security context and then encouraging them to think that just because the Tor software is present somewhere in the picture, they are benefitting from the type of security that Tor aims to provide. --Roger [1] By "security", I'm talking primarily about unlinkability here; but that's a different thread. [2] http://freehaven.net/anonbib/#usability:weis2006 [3] http://freehaven.net/anonbib/#torta05 [4] http://freehaven.net/anonbib/#danezis:pet2004 ----- 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

1 0

[IP] Clock to tick down U.S. privacy
by David Farber 06 Jul '18

06 Jul '18

http://www.washingtontimes.com/article/20070918/NATION/109180049/1002 A "Surveillance Society Clock" created by the American Civil Liberties Union will symbolize the encroachment of government spying on private citizens as part of the war against terrorism - and the ticktock is fast approaching midnight. "The extinction of privacy is a real possibility," said Barry Steinhardt, director of the ACLU's Technology and Liberty Project. "We believe that privacy is not yet dead - it is a patient on life support." The online clock is patterned after the "Doomsday Clock," created by the Bulletin of the Atomic Scientists in 1947 to warn against a nuclear holocaust. Midnight symbolized a total "1984"-style "surveillance society." "Every generation deserves its own clock," Mr. Steinhardt said in a teleconference yesterday announcing the project and a new report on mass surveillance by the government. He said that an explosive increase in new technology and data mining is fueling the trend and creating a false sense of security - from satellites to national-identity systems, the National Security Agency's warrantless surveillance program, DNA data-banking and Web search engines that store every query, even satellites. "The false security of a surveillance society threatens to turn our country into a place where individuals are constantly susceptible to being trapped by data errors or misinterpretations, illegal use of information by rogue government workers, abuses by political leaders - or perhaps most insidiously, expanded legal uses of information for all kinds of new purposes," the report says. "We are far too close to the midnight of a genuine surveillance society, and the second hand has not stopped sweeping around the dial," the report says. The "surveillance" clock, a digital display viewable from the ACLU's Web site, is now set at six minutes before midnight. The ACLU says it will be updated as events warrant moving the time closer or further away from a "surveillance society." ... ------------------------------------------- Archives: http://v2.listbox.com/member/archive/247/=now RSS Feed: http://v2.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com ----- 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

[serval-project-dev] New 0.07.RC1 build
by Jeremy Lakeman 06 Jul '18

06 Jul '18

There have been a couple of annoying bugs that we've found with the last two releases that we really need to get fixes out for. Plus the new automatic device detection support that Paul has been building has been getting close enough to be useful. So I've been trying to tidy up what we've got for a new release. There's still lots of testing we need to do before we even contemplate a release to the android market. But I've run out of blocking issues that I'm aware of and I think these changes are ready for some wider testing on more handsets than we have access to here. http://developer.servalproject.org/files/Serval-0.07.RC1.apk However, there are still a couple of things we MUST change before we build an official 0.07 release and encourage it's use for a wider audience. Mostly to give the user more control over which experimental support scripts to try, and make sure the process restarts after a reboot / force close, as running a script may cause the device to crash hard. Some quick release notes; - New post installation screen to display the progress of tasks we have to do on install - New automatic wifi chipset detection process that tries to guess how to put you phone into adhoc mode - Stop dna from corrupting it's data file and crashing which would leave the phone unreachable. -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- 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