July 2018 - cypherpunks-legacy

Re: [liberationtech] Silent Circle Dangerous to Cryptography Software Development
by Fabio Pietrosanti (naif) 06 Jul '18

06 Jul '18

On 10/12/12 1:55 AM, Christopher Soghoian wrote: > If conversations are taking place over ZRTP, and, assuming that the > crypto works, and that there isn't a backdoor, then the only data that > silent circle should have access to is conversation metadata and data > about the subscribers (IP addresses, an email address, and whatever > info is required for credit card billing, such as a name/address). I run that kind of mobile voice crypto business since 2006, had worked with Phil on our Board of Advisor, but i basically have not much trust in the "SAAS" business model for that kind of stuff, given my own personal experience. When i meet customers (mostly Enterprises and Governments, ONG get it for free), the big obstacle is not the technology but is the "trust". SilentCircle have worked a lot on the concept of "Trust" by having trustful people on-board, however i do think that who really need communication encryption support, normally doesn't have the skills to evaluate and understand how a technology or security mechanism works. As written on http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00446.html, i tried in past to run and market a service for mobile voice encryption, but there was always one question from customers: "So, all my phone calls goes trough your systems?" After that question, from a commercial point of view, for Enterprise & Government customers, represented a dead-end. So now, like CryptoPhone and other companies doing voice crypto, i had to provide that stuff only with in-house server for customers. Still i would be very happy if SilentCircle realize a marketing model where they can have customers interested to use their service! We need more innovation that field, we need opensource and free products, commercial products, software as a service products: At the end we it's just important that what you get from a community, you provide it back to the community! [...] > > I'm not even sure what specific legal method would be used to compel > such a backdoor in the US, since CALEA specifically addresses (and > largely shields) communications service providers that provide > encrypted communications but do not have access to the key. > See: http://paranoia.dubfire.net/2010/09/calea-and-encryption.html Yeah, when i spoke with Nicolas from Calyx he showed me the same US law. US Law is *extremely better* than EU Directive on the same topic, as in EU is not specifically considered and as long as you are an "Electronic communication service provider" you are obliged to provide assistance and cooperation with "Lawful interception" requirements mandated by ETSI-LI and further. If you do provide the encryption tools along with the "electronic communication service", it's your clear intention and goals to put yourself in a condition that will not let you respect the lawful interception legal requirements. So your basically violating the law. The only way is to work on the concept of what is an "electronic communication service", as we did (at privatewave). Here you can find our legal and technical analysis on how to run a voice encryption services in Italy (EU) not representing an "electronic communication service" https://docs.google.com/open?id=1vHoApU0x6PyR2_4RAL7OrEQzecQkuHoYjq1ISfaRqM… . > > However, on the compelled backdoor front, if this is a threat you are > worried about, I would be equally (if not far more) worried about the > government compelling Google or Apple to covertly push a malware > update to your phone. I don't think that this could practically happen, basically due to the liability and trust risks that Google or Apple would incur. Given their stock market capitalization, their CFO would never permit something like that, and for that reason i consider Apple or Google store the most secure software delivery method even, there are too many interests to get this backdoored :-) Fabio -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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: [p2p-hackers] Onion Routing Economy
by Roger Dingledine 06 Jul '18

06 Jul '18

On Thu, May 20, 2004 at 06:26:44AM +0200, Johan F?nge wrote: > What papers and ideas are there on the economy aspect of Onion Routing? Check out "Using Payments to Promote Cooperation in Anonymity Protocols" by Figueiredo et al, ftp://gaia.cs.umass.edu/pub/Anon_Incentive_03-31.pdf for a pretty good introduction to the problem. There are a lot of unsolved problems here though. For example: One could imagine a payment protocol where the initiator delivers to node i+1 a coin which is only valuable to node i, and if all is going well then i+1 hands the coin to i. But what about paying the last node in the path? External sites (e.g. webservers) don't know about your protocol. So either you don't pay the last hop, in which case there's no incentive for anybody to honor that, or you give him the money and hope for the best, which again isn't so good incentive-wise. This is critical because of another sort of free-riding on systems like onion routing: many users would prefer to run middleman nodes (relaying traffic only inside the network, and allowing nothing to exit from their node). Another issue to consider is collusion. If nodes work together, can they take your money without providing service? An incentive/payment scheme should at the least tolerate some amount of this, especially in the context of Sybil attacks: http://freehaven.net/anonbib/#sybil Does the payment system enable the adversary to attract more traffic by performing well? See "Reliable MIX Cascade Networks through Reputation" for more details around this issue: http://freehaven.net/anonbib/#casc-rep Rather than explicitly trying to reward good behavior, you might also consider implicit incentives. For example, running a node (and relaying traffic) can provide *better anonymity* for a user, so he should want to do it, and the most plausible cover traffic is actual other traffic. See "On the Economics of Anonymity", http://freehaven.net/anonbib/#econymics Another area to look at is the token-based incentive scheme in GNUnet -- http://freehaven.net/anonbib/topic.html#ebe2003 and http://freehaven.net/anonbib/#bennett:pet2003 >How can one stop the flooding/spamming of the network with junk? How can >one stop people from using too much resources? How can one create >incentive to give and not lie? > >I've though about it some myself, and I'm curious as to whether i've >reinvented part of the wheel. > >The basic idea is: > > You pay for your packets in bandwidth, by contributing to the system. > > When passing on a packet you receive credits from the originator. > Prioritize credited transfer. (Credits could possibly be the > "guaranteed" transfer of an amount of data.) After having "payed" for > one package to be passed on by a node, you pay a node, possibly the > same, and have it sponsor the continued transfer of the node, by trading > bandwidth with it. (You pay the sponsor by forwarding something, and the > sponsor then pays the forwarder of your package, by forwarding something > from the forwarder.) There's a lot still to be worked out here. How do you make sure the guy you just paid gets the guys later in the path to perform well? Is "credit" local (relative to just you) or global (I do something for Janet, then get to use Jane's resources)? If global, how do I tell people that somebody has performed well/poorly without revealing that I just used them? Do I choose nodes for my paths based on my view of peoples' credit, so an adversary who tracks my perspective could guess which paths are mine based on which nodes are in the path? (Or worse, he could influence my view of the network so I'm likely to pick nodes that nobody else picks, making me even more partitioned.) How do you distinguish between somebody who's legitimately down sometimes and somebody who provides selective service (relays some traffic, but always just takes Jane's money and ignores her)? What incentive do nodes have to pass traffic *back*? Most requests in Tor (the deployed second-generation onion routing system, see http://freehaven.net/tor/) send a few bytes forward and get many bytes in return. If the credits are local, here's another attack: the adversary shows up and uses your node, then gives you a token so you can use his. He's just bought the right to relay some of your traffic. Depending on the design, either you get to choose the later hops in the path, in which case you'll probably have to pay for them too (meaning you'll have gathered tokens for them -- and how did you do that? Some nice guy showed up and used your node, then gave you a token to use him back), or the adversary gets to choose your next hop, and we all know where that leads (cf http://freehaven.net/anonbib/#morphmix:wpes2002) I've written a bit more discussion about these topics in http://freehaven.net/anonbib/#rep-anon, including some questions about reputation and currency in section 6. It might sound like I'm trying to convince you this is an impossible problem. But I actually think we're getting closer to finding some sort of halfway-decent incentive scheme in the next couple of years. I figure the first step is to understand it well enough to figure out which parts we can ignore. Maybe enumerating the problems will drive somebody to show me how easy it is? :) --Roger _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences --- 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'

1 0

Re: [tor-talk] possible to identify tor user via hardware DRM?
by proper＠secure-mail.biz 06 Jul '18

06 Jul '18

<schoen(a)eff.org> wrote: > One of the defenses people have talked about against hardware > fingerprinting is running inside a virtual machine. Normally, > software inside the virtual machine, even if it's malicious, > doesn't learn much about the physical machine that hosts the VM. > If you always use Tor inside a VM, then even if there's a bug > that lets someone take over your computer (or if they trick you > into installing spyware), the malicious software won't be able > to read much real uniqueness from the host hardware, unless > there's also a bug in the VM software. > > [...] There's probably more research to be done > about the conditions under which VMs can be uniquely identified > both "from the inside" by malware, and remotely by remote > software fingerprinting, absent VM bugs that give unintended > access to the host. We documented, which data, malware inside a VM could collect to identify users. [1] That doesn't mean, we wouldn't be happy about sophisticated, dedicated research. However, here is a summary: - (Apart from obvious and known, IP, DNS, (browser) fingerprinting.) - internal LAN IP (of virtualized operating system) - time zone (of virtualized operating system) - username (of virtualized operating system) - hostname (of virtualized operating system) - mac address of virtual machine - mac address of host (if using bridged networking) or mac address of gateway (if using virtual internal networking) - virtual disk uuids - Some information about the real CPU, depends on VM software. There might be options to further hide information about the CPU. - Installed software packages. - If you copy data into the VM: metadata. [1] https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/SecurityAndHardeni… ______________________________________________________ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-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

Re: [p2p-hackers] Onion Routing Economy
by Roger Dingledine 06 Jul '18

06 Jul '18

On Thu, May 20, 2004 at 06:26:44AM +0200, Johan F?nge wrote: > What papers and ideas are there on the economy aspect of Onion Routing? Check out "Using Payments to Promote Cooperation in Anonymity Protocols" by Figueiredo et al, ftp://gaia.cs.umass.edu/pub/Anon_Incentive_03-31.pdf for a pretty good introduction to the problem. There are a lot of unsolved problems here though. For example: One could imagine a payment protocol where the initiator delivers to node i+1 a coin which is only valuable to node i, and if all is going well then i+1 hands the coin to i. But what about paying the last node in the path? External sites (e.g. webservers) don't know about your protocol. So either you don't pay the last hop, in which case there's no incentive for anybody to honor that, or you give him the money and hope for the best, which again isn't so good incentive-wise. This is critical because of another sort of free-riding on systems like onion routing: many users would prefer to run middleman nodes (relaying traffic only inside the network, and allowing nothing to exit from their node). Another issue to consider is collusion. If nodes work together, can they take your money without providing service? An incentive/payment scheme should at the least tolerate some amount of this, especially in the context of Sybil attacks: http://freehaven.net/anonbib/#sybil Does the payment system enable the adversary to attract more traffic by performing well? See "Reliable MIX Cascade Networks through Reputation" for more details around this issue: http://freehaven.net/anonbib/#casc-rep Rather than explicitly trying to reward good behavior, you might also consider implicit incentives. For example, running a node (and relaying traffic) can provide *better anonymity* for a user, so he should want to do it, and the most plausible cover traffic is actual other traffic. See "On the Economics of Anonymity", http://freehaven.net/anonbib/#econymics Another area to look at is the token-based incentive scheme in GNUnet -- http://freehaven.net/anonbib/topic.html#ebe2003 and http://freehaven.net/anonbib/#bennett:pet2003 >How can one stop the flooding/spamming of the network with junk? How can >one stop people from using too much resources? How can one create >incentive to give and not lie? > >I've though about it some myself, and I'm curious as to whether i've >reinvented part of the wheel. > >The basic idea is: > > You pay for your packets in bandwidth, by contributing to the system. > > When passing on a packet you receive credits from the originator. > Prioritize credited transfer. (Credits could possibly be the > "guaranteed" transfer of an amount of data.) After having "payed" for > one package to be passed on by a node, you pay a node, possibly the > same, and have it sponsor the continued transfer of the node, by trading > bandwidth with it. (You pay the sponsor by forwarding something, and the > sponsor then pays the forwarder of your package, by forwarding something > from the forwarder.) There's a lot still to be worked out here. How do you make sure the guy you just paid gets the guys later in the path to perform well? Is "credit" local (relative to just you) or global (I do something for Janet, then get to use Jane's resources)? If global, how do I tell people that somebody has performed well/poorly without revealing that I just used them? Do I choose nodes for my paths based on my view of peoples' credit, so an adversary who tracks my perspective could guess which paths are mine based on which nodes are in the path? (Or worse, he could influence my view of the network so I'm likely to pick nodes that nobody else picks, making me even more partitioned.) How do you distinguish between somebody who's legitimately down sometimes and somebody who provides selective service (relays some traffic, but always just takes Jane's money and ignores her)? What incentive do nodes have to pass traffic *back*? Most requests in Tor (the deployed second-generation onion routing system, see http://freehaven.net/tor/) send a few bytes forward and get many bytes in return. If the credits are local, here's another attack: the adversary shows up and uses your node, then gives you a token so you can use his. He's just bought the right to relay some of your traffic. Depending on the design, either you get to choose the later hops in the path, in which case you'll probably have to pay for them too (meaning you'll have gathered tokens for them -- and how did you do that? Some nice guy showed up and used your node, then gave you a token to use him back), or the adversary gets to choose your next hop, and we all know where that leads (cf http://freehaven.net/anonbib/#morphmix:wpes2002) I've written a bit more discussion about these topics in http://freehaven.net/anonbib/#rep-anon, including some questions about reputation and currency in section 6. It might sound like I'm trying to convince you this is an impossible problem. But I actually think we're getting closer to finding some sort of halfway-decent incentive scheme in the next couple of years. I figure the first step is to understand it well enough to figure out which parts we can ignore. Maybe enumerating the problems will drive somebody to show me how easy it is? :) --Roger _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences --- 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'

1 0

Re: [tor-talk] possible to identify tor user via hardware DRM?
by proper＠secure-mail.biz 06 Jul '18

06 Jul '18

<schoen(a)eff.org> wrote: > One of the defenses people have talked about against hardware > fingerprinting is running inside a virtual machine. Normally, > software inside the virtual machine, even if it's malicious, > doesn't learn much about the physical machine that hosts the VM. > If you always use Tor inside a VM, then even if there's a bug > that lets someone take over your computer (or if they trick you > into installing spyware), the malicious software won't be able > to read much real uniqueness from the host hardware, unless > there's also a bug in the VM software. > > [...] There's probably more research to be done > about the conditions under which VMs can be uniquely identified > both "from the inside" by malware, and remotely by remote > software fingerprinting, absent VM bugs that give unintended > access to the host. We documented, which data, malware inside a VM could collect to identify users. [1] That doesn't mean, we wouldn't be happy about sophisticated, dedicated research. However, here is a summary: - (Apart from obvious and known, IP, DNS, (browser) fingerprinting.) - internal LAN IP (of virtualized operating system) - time zone (of virtualized operating system) - username (of virtualized operating system) - hostname (of virtualized operating system) - mac address of virtual machine - mac address of host (if using bridged networking) or mac address of gateway (if using virtual internal networking) - virtual disk uuids - Some information about the real CPU, depends on VM software. There might be options to further hide information about the CPU. - Installed software packages. - If you copy data into the VM: metadata. [1] https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/SecurityAndHardeni… ______________________________________________________ powered by Secure-Mail.biz - anonymous and secure e-mail accounts. _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-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-dev] questions about development priorities for Tahoe-LAFS, summer 2009
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: Here are just a few scattered notes about how I'm not sure who is going to move Tahoe forward in which ways next. Your opinions about what should be done, and your offers to do them, would be gratefully accepted. First of all, about me. I'm interviewing for new jobs (if you were considering offering to hire me, now is the time!). As part of this process I'm asking potential employers if they will give me a degree of moral support to work on Tahoe in my "spare time". I'm also encouraging Peter Secor in his efforts to find renewed funding for Tahoe development, either on a commercial basis from someone who intends to make money with this technology, or on a philanthropic basis from someone who thinks that this technology could improve people's lives. It could turn out that within a week or two from writing this letter I will take on some exciting new job which is not directly related to Tahoe and my contributions to Tahoe will lessen dramatically. Now about Brian: it looks like he is still planning to do lots of hacking on Tahoe this summer, and he's an awesome hacker, so you can expect top-quality work from him. Kevin Reid is not going to work on a Tahoe GUI this summer after all -- the Google Summer of Code people asked him to work on a remote object protocol for caja instead. (Which is cool, but I'm still disappointed.) The student-and-mentor team of Vincent Chow and Nathan Wilcox appear to be determined to marry a decentralized revision control tool such as Bazaar or Mercurial with Tahoe this summer. It seems to me that it would be easy to make a proof-of-concept for that but hard to make a solid, high performance, usable tool. I can't wait to see what they do! Shawn Willden is presumably still in his secret underground lair in Utah hacking on GridBackup. He hasn't been very active on this list, but he has published his git repo... Hm, looks like he hasn't updated that git repo since he first committed to it in February. By the way, here is a podcast of his presentation about GridBackup to the Utah Python group: http://podcast.utos.org/index.php?cat=gridbackup Mahmoud More wants to work on decentralizing the introducer. If one confines oneself to implementing ticket #68, comment #11, *and nothing else* then this is a small, confined project that a student like Mahmoud could accomplish in one summer. However, Mahmoud would need a mentor to guide him, and because of my job situation I might not have the time to commit to that. Frangois Deppierraz is eager to fix #534 (encoding issues). He has submitted a patch, which I didn't apply because it is a large patch and it takes me a while to get my head around it and to check if all of its changes are covered by unit tests. I started splitting it up into smaller patches, but, again, I don't really have time to do more on that right now, so if Frangois or anyone else could look at those patches and make sure that everything that we care about is tested with a unit test then that would be forward progress! I might be forgetting other people who are currently working on Tahoe improvements. If so, I apologize and please speak up. Now, per my earlier cryptic notes about Tahoe development strategy [1], my next priorities for Tahoe are: * short-length feedback loop with actual users * inclusion in Debian & Fedora - pycryptopp linkage * low hanging fruit of performance * encoding * volunteergrid If anybody wants to help out with things along these lines, speak up! Let's make a goal to have a new stable release of Tahoe, containing *some* kind of improvements that people would care about, having no known regressions, and having thorough unit tests for all changed code, in June 2009 -- about two months since the v1.4 release. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-March/001506.html tickets mentioned in this message: http://allmydata.org/trac/tahoe/ticket/68#comment:11 # distributed introduction COMMENT ELEVEN http://allmydata.org/trac/tahoe/ticket/534 # "tahoe cp" command encoding issue _______________________________________________ tahoe-dev mailing list tahoe-dev(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

Air travel without ID.
by Trei, Peter 06 Jul '18

06 Jul '18

[For IP, if you wish - pt] >From RISKS 23.50: http://catless.ncl.ac.uk/Risks/23.50.html#subj6 ----------------- U.S. air travel without government identification <Dan Wallach <dwallach(a)cs.rice.edu>> Thu, 19 Aug 2004 19:41:02 -0500 Recently, John Gilmore has been publicly decrying the unstated Federal requirement that one must present government-issued identification (e.g., a driver's license) in order to travel via air within the U.S. Unfortunately for me, I got to test this requirement on a recent trip to give a talk at Fermilab when I managed to leave my driver's license at home. Here's what happened. For what it's worth, I've recently taken to carrying two wallets. The large one has my money, credit cards, receipts, and other assorted junk. The small one has my business cards and the two ID cards I most often need: my driver's license and my university ID card (a magstripe card that I need to get into my building after hours). In order to make my flight at the ungodly hour of 7:35am, I had to get up quite early. In the confusion of the morning, I managed to leave the little wallet at home. I didn't notice this oversight until I was standing in front of the ticket counter at 7:00am. In order to have gotten my driver's license, I would have had to miss my flight. Instead, I decided to see how the system would work without it. == Intercontinental Airport: Houston, Texas I pleaded my case to the Continental ticket agent. "Do you have any picture ID on you at all?" Nope. I showed her my Continental frequent flyer card, my credit card, and my social security card (which I probably shouldn't have had in my wallet, but that's a story for another day) as well as my boarding pass, printed that morning on my home computer. She escorted me to the security guard, with all my cards in her hand, and briefly described the situation. The guards expressed some confusion, but decided to let me through. After that, everything proceeded normally. == Fermilab: Suburban Chicago, Illinois My hosts at Fermilab had helpfully arranged a rental car for me. It dawned on me that I'd never get out of the rental car lot without a driver's license. I called Fermilab's travel agent and explained my predicament. As it turns out, Fermilab has a limo service that they regularly use. The travel agent made a reservation for me with the limo service, who happily picked me up at the airport and delivered me to Fermilab. If you're into high-energy physics, you know all about Fermilab. For the rest of us, they have a ring, about 1km in radius, around which they fling protons and anti-protons at very high energies, arranging for them to collide inside a massive detector. Those high-energy collisions cause all sorts of interesting subatomic particles to come flying out, hopefully to be detected by a variety of impressive devices. (My high school physics teacher quipped that it's like trying to learn how cars work by smashing them together and seeing what falls out.) Before September 11, the Fermilab campus was wide open, and the locals could go fishing in the lake, jogging around the ring, and so forth. These days, you have to go to a guard shack. Visitors get a limited pass and are instructed to only go to specific places where they're allowed (e.g., the education center). I'd been told that a badge would be waiting for me. The guard asked for my ID. "Let me tell you a story," I began. Ultimately, the guard had to telephone my hosts who drove down to the guard shack to pick me up. After that, it was smooth sailing. == O'Hare Airport: Chicago, Illinois Everybody to whom I'd told this story was amazed that I'd gotten as far as I did, and I was repeatedly warned that O'Hare security was quite stringent. Just to make sure, I had the limo get me to the airport a full two hours before my 11:00am flight. I printed out my boarding pass using the Continental kiosk, using my credit card to authenticate myself to the system, and then explained my story to the ticket agent. "Do you have any government issued ID?" Sorry, no. She wrote "SSSS" in big letters on my boarding pass, highlighted it in pink, and pointed me at the security checkpoint: the special security checkpoint without a line in front of it. I walked up and presented my boarding pass to the guard. "ID?" I began my story, but the only phrase that seemed to matter was "No ID", which she wrote onto my boarding pass. She then wrote "SSSS" again and circled it, also circling the original pink-highlighted copy. On I went. First the normal X-ray machine, take your laptop out, etc. Then, on the other side, they gave me the extended treatment, which normally occurs when I've been "randomly" selected. They X-rayed my shoes, swabbed my laptop for explosives, and unzipped every compartment of my luggage. After I passed all of those tests, they let me through, never once examining any of the cards I had in my wallet. Moral of the story While my story is hardly the same thing as a conclusive examination of the policies of all major U.S. airports, my experience shows that it is, indeed, possible to do interstate air travel without a driver's license. You're no longer using the "fast path" of the airport security apparatus, and there is clearly some variation in how the rules govern your slow path through the system. However, if you're willing to put up with the "SSSS" treatment, then it appears that you can legally travel by air within the U.S. without a government-issued ID. (Gilmore acknowledges this in his lawsuit, which is focused on finding out where the requirement for presenting ID came from, in the first place.) Postscript As a Continental frequent flyer, I was invited to show up at the airport to be measured for a new biometric-based system that they've installed in Houston. (I think it measures fingerprints, but I'm not entirely sure.) I was out of town, and thus unable to give that system a shot. They do require several forms of ID to get yourself registered, so it will have to wait for another day. Maybe I'll give it a try and write something about it later for RISKS. For all the known issues with biometric authentication, it's quite difficult to leave your fingerprints at home in the wrong trousers. ------------------------------------- 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> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] Air travel without ID.
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[tahoe-dev] questions about development priorities for Tahoe-LAFS, summer 2009
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: Here are just a few scattered notes about how I'm not sure who is going to move Tahoe forward in which ways next. Your opinions about what should be done, and your offers to do them, would be gratefully accepted. First of all, about me. I'm interviewing for new jobs (if you were considering offering to hire me, now is the time!). As part of this process I'm asking potential employers if they will give me a degree of moral support to work on Tahoe in my "spare time". I'm also encouraging Peter Secor in his efforts to find renewed funding for Tahoe development, either on a commercial basis from someone who intends to make money with this technology, or on a philanthropic basis from someone who thinks that this technology could improve people's lives. It could turn out that within a week or two from writing this letter I will take on some exciting new job which is not directly related to Tahoe and my contributions to Tahoe will lessen dramatically. Now about Brian: it looks like he is still planning to do lots of hacking on Tahoe this summer, and he's an awesome hacker, so you can expect top-quality work from him. Kevin Reid is not going to work on a Tahoe GUI this summer after all -- the Google Summer of Code people asked him to work on a remote object protocol for caja instead. (Which is cool, but I'm still disappointed.) The student-and-mentor team of Vincent Chow and Nathan Wilcox appear to be determined to marry a decentralized revision control tool such as Bazaar or Mercurial with Tahoe this summer. It seems to me that it would be easy to make a proof-of-concept for that but hard to make a solid, high performance, usable tool. I can't wait to see what they do! Shawn Willden is presumably still in his secret underground lair in Utah hacking on GridBackup. He hasn't been very active on this list, but he has published his git repo... Hm, looks like he hasn't updated that git repo since he first committed to it in February. By the way, here is a podcast of his presentation about GridBackup to the Utah Python group: http://podcast.utos.org/index.php?cat=gridbackup Mahmoud More wants to work on decentralizing the introducer. If one confines oneself to implementing ticket #68, comment #11, *and nothing else* then this is a small, confined project that a student like Mahmoud could accomplish in one summer. However, Mahmoud would need a mentor to guide him, and because of my job situation I might not have the time to commit to that. Frangois Deppierraz is eager to fix #534 (encoding issues). He has submitted a patch, which I didn't apply because it is a large patch and it takes me a while to get my head around it and to check if all of its changes are covered by unit tests. I started splitting it up into smaller patches, but, again, I don't really have time to do more on that right now, so if Frangois or anyone else could look at those patches and make sure that everything that we care about is tested with a unit test then that would be forward progress! I might be forgetting other people who are currently working on Tahoe improvements. If so, I apologize and please speak up. Now, per my earlier cryptic notes about Tahoe development strategy [1], my next priorities for Tahoe are: * short-length feedback loop with actual users * inclusion in Debian & Fedora - pycryptopp linkage * low hanging fruit of performance * encoding * volunteergrid If anybody wants to help out with things along these lines, speak up! Let's make a goal to have a new stable release of Tahoe, containing *some* kind of improvements that people would care about, having no known regressions, and having thorough unit tests for all changed code, in June 2009 -- about two months since the v1.4 release. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-March/001506.html tickets mentioned in this message: http://allmydata.org/trac/tahoe/ticket/68#comment:11 # distributed introduction COMMENT ELEVEN http://allmydata.org/trac/tahoe/ticket/534 # "tahoe cp" command encoding issue _______________________________________________ tahoe-dev mailing list tahoe-dev(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev ----- 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

<nettime> Daniel Henninger: Wikileaks R Us (Wall Street Journal)
by Patrice Riemens 06 Jul '18

06 Jul '18

original to: http://online.wsj.com/article/wonder_land.html (will probably change - Google for actual URL) * WONDER LAND * DECEMBER 2, 2010 WikiLeaks R Us We can't put the Internet genie back in the bottle. By DANIEL HENNINGER There is one certain fix for the WikiLeaks problem: Blow up the Internet. Short of that, there is no obvious answer. This summer I was in a movie line behind two guys, and one said: "I hate Facebook. I wish it had never been invented. But I can't live without it." Welcome to the WikiLeaks problem, which was born along with the Internet itself. What we can't live without may kill us. In October, the Secret Service arrested a Malaysian man in New York who had 400,000 bank-card numbers. He'd hacked them out of the Cleveland Federal Reserve and other financial institutions. Last year a contractor remotely inserted a potentially destructive "logic bomb" on Fannie Mae's servers that could have erased a lot of its data. What about your co-worker? Two years ago, a worker in the City of San Francisco's technology department created a password that let him access virtually all the city's files and business on its FiberWAN network, while blocking access to everyone else. They caught him, but for a while he held the city hostage, refusing to give up his key to the city. Can Bank of America say with certainty they haven't been robbed of the data Julian Assange claims to possess? No, they can't. Once you input anything into the digital ethers, it will never be "safe" or "private." Sun Microsystems' co-founder Scott McNealy famously said: "You have zero privacy. Get over it." We know that. What we don't know, or won't admit, is that the idea of confidentialityState Department cables, the design for weapons systems, health recordshas eroded, perhaps permanently. We can't put the Internet genie back in the bottle. Everyone from Hillary Clinton on down is "shocked" at the cables dump. But if last year one had polled experts on the architecture of data systems about the probability of this event, most would have said it surely would happen, eventually. The Government Accountability Office has released survey after survey on this problem, all singing the same song printed on the front of this June's report: "Cybersecurity: Key Challenges Need to Be Addressed." Congress has thrown dozens of bills at cybersecurity. Is WikiLeaks Obama's fault? No. You could throw the entire IQ capacity of Google's work force at the problem. They might devise a solution, but it wouldn't be the answer. Like the Web itself, it's complicated. Private companies already offer solutions to protecting data systems. "Data-at-rest" and "data-in-motion" programs look for anomalies in emails and other data moving through networks or resting on hard drives. SIM (security information management) software tracks network intrusions. It's pretty good, the way climatology is pretty good. But there's a maddening paradox that this technology poses to any organized group of people trying to use it for good ends: How to set up protocols that will haul in the bad guys without hampering the creative work of everyone else? If the U.S. (or Europe) has one big comparative advantage left, it is an information advantage. Out of the organized serendipity of many smart people bouncing information-laden ideas off each other, good things happen here. Whether workers in a knowledge society are creating advances on cancer or software for the pilotless drones killing our worst enemies, they need lots of information, need it now, and need to "talk" about it on the network with colleagues. That means "odd" but legitimate events are going to occur on one's data network. Separating all the odd from one bad is hard. China's security solution is to suppress the flow of information, let creativity be damned, and steal from us. (The New York Times's Thomas Friedman yesterday asked: "What if China had a WikiLeaker?" The three-word answer: They'd execute him.) The Pentagon, State Department and our banks are at risk because it is hard to define who or what should be monitored. Then each institution would have to create an Orwellian "monitoring" office. Oh wait, we already did thatthe Department of Homeland Security. Problem solved. After 9/11, non-communicating, "stove-piped" federal agencies emerged as a top problem. To open the cross-agency information flow of classified information they created SIPRNet. Now the State Department has pulled the plug on SIPRNet. Ponder this: The CIA never joined SIPRNet and took heat for that. Count me as glad that Assange doesn't have access to data on the agency's anti-Taliban drone program. Two big things transformed the postwar world: nuclear fission and the Internet. Nuclear fission gave us clean energy and the atomic bomb. The Internet? With WikiLeaks, we arrive at the Internet version of putting the nuclear genie back in the bottle. There may be no obvious fix for the paradoxes of this inherently vulnerable technology. But we also can't survive in a digital state of nature. The Internet "A-bomb" will go off eventually. Here's a thought for our befuddled national leadership: The first time humans concluded that they needed to deter bad people from taking advantage of civilization, they set common rules. If people broke them, they put them away. Pfc. Bradley Manning, charged with downloading all that data for Assange, is sitting in a Quantico jail. He could get 52 years. He should. And that's just for starters, if we hope to live with the Internet genie. Write to henninger(a)wsj.com # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mail.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0