July 2018 - cypherpunks-legacy

[FoRK] Chons
by Stephen Williams 06 Jul '18

06 Jul '18

On 2/4/11 3:40 AM, Eugen Leitl wrote: > On Thu, Feb 03, 2011 at 04:10:00PM -0800, Tom Higgins wrote: > >> Re Mesh - I have been mucking with it for many years and reading about >> it even longer. Seems solutions for getting what appears a group that > Fun fact: a local /64 is fully enough to encode lat/long/alt > (24, 24, 16 bit) with about 2 m resolution. Add some minor > LSB bit jiggling and DAD, and you've gots yourself a rather > robust address allocation scheme that allows you to know where Can you write up a spec for that? A few lines of code? > you are, and mutal local node mapping. You can either store > it verbatim, or as deviation from idealicity. Implement long-distance > links by VPN tunnels initially. > > Any current WiFi embedded is plenty capable of that. There are a couple main types of use cases for this kind of capability: A) emergency situations of various types like the Egypt blackout and B) getting communication and sharing working in more misc. ambient conditions (poor coverage in a building, on the train, etc.). There is a big use case for this that will give it a workout that is sort of a simulation of the first of these and with a good need for the second: Burning Man. Many people in a refugee-like camp, no commercial wireless or land line, a desire to communicate in various ways, a high percentage of techies with smart phones, all running an experiment for a week. Seems like a perfect testing ground. We have 6 months to be ready. I hereby declare project: "Egyptian Light" (to counter blackouts everywhere ;-) ). The point of this is to shamelessly combine every existing technology that provides a piece of this and then fill in the missing pieces. Even better: http://egypt.annourbis.com/egyptian-gods.html Chons - "Egyptian god of light in the night... he also held the titles Embracer, Pathfinder, and Defender, as he was thought to watch over night travelers. As the god of light in the night, Chons was invoked to protect against wild animals, increase male virility, and to aid with healing." chons.org is now registered. Now, how is it pronounced?? There has been plenty of work with open source cell networks, etc. I haven't seen anything usable about hand-held mesh and/or store and forward capability yet. Ideally, you'd use bluetooth when in close proximity, with Wifi / cell for uplink, with Wifi also being used for wider proximity connections. The store and forward capability could be kind of cool. Limit it to SMS-like messages, enforce flow control, then floodcast, possibly with fuzzy geo-routing, as necessary for both unicast and broadcast messages. Get all roving vehicles to run store and forward nodes. Include time synchronization, then implement radio control for prairie dog activation for both battery conservation and channel multiplexing. The biggest hurdle will be security, including detecting and defeating jamming and spoofing of various types. I'm most interested in an Android solution that will work on most devices. Not only are they easier to hack, more open, easier to run untrusted apps, etc., but some of us are building a collection of obsolete devices that would be cool to use for this. Unfortunately, my pattern is full for a bit. But before BM2011, hopefully it will be far along. sdw _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- 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: [cryptography] bitcoin scalability to high transaction rates
by Nathan Loofbourrow 06 Jul '18

06 Jul '18

On Thu, Jul 21, 2011 at 8:41 AM, Sampo Syreeni <decoy(a)iki.fi> wrote: > On 2011-07-21, Marsh Ray wrote: > > I guess I don't see the need to do bitcoin crypto transactions at that >> speed any more than the other high-speed exchanges need to rapidly move >> stock certificates, hard cash, or perform ACH/EFTs. >> > > That's probably true. But then, HST is just an example of a mechanism which > creates prodigious amounts of transaction data. There are others, starting > simply with wide enough adoption of Bitcoin. So if the amount of transaction > data being shipped around can become a bottleneck here, it could indicate a > scalability limit on Bitcoin in more realistic situations. In practice, trades on Bitcoin exchanges don't create transactions in the Bitcoin crypto log; you can even give Bitcoins to one another within an exchange for the cost of an API call. It's only when money is transferred into our out of the exchange that a "real" transaction needs to be created, whether though Bitcoin or through a bank. Private markets can help aggregate small transactions. Of course, this presumes you trust the exchange, which is a different matter. n _______________________________________________ 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

CIA Researching Automated IRC Spying
by brian-slashdotnews＠hyperreal.org 06 Jul '18

06 Jul '18

Link: http://slashdot.org/article.pl?sid=04/11/24/2140209 Posted by: timothy, on 2004-11-24 21:58:00 from the will-u-be-my-friend-lol-j/k dept. Iphtashu Fitz writes "CNet News is reporting that the CIA has been [1]quietly investing in research programs to automatically monitor Internet chat rooms. In a two year agreement with the [2]National Science Foundation, CIA officials were involved with the selection of recipients for research grants to develop automated chat room monitors. Researchers at [3]Rensselaer Polytechnic Institute received $157,673 from the CIA and NSF for their proposal of 'a system to be deployed in the background of any chat room as a silent listener for eavesdropping ... The proposed system could aid the intelligence community to discover hidden communities and communication patterns in chat rooms without human intervention.' How soon until all IM conversations are monitored by [4]Big Brother? The [5]abstract of the proposal is available on the NFS website." [6]Click Here References 1. http://news.com.com/2100-7348_3-5466140.html 2. http://www.nsf.gov/ 3. http://www.rpi.edu/ 4. http://en.wikipedia.org/wiki/Big_Brother_(1984) 5. http://nsf.gov/awardsearch/showAward.do?AwardNumber=0442154 6. http://ads.osdn.com/?ad_id=5671&alloc_id=12342&site_id=1&request_id=2995024… p=click&page=%2farticle%2epl ----- 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

Re: [p2p-hackers] Codes for Error Correction in P2P Nets
by Michael Parker 06 Jul '18

06 Jul '18

A very good overview of all network coding for the purposes of data distribution (i.e., making digital fountains) can be found at: www.eecs.harvard.edu/~michaelm/postscripts/itw2004.pdf Some of the more interesting and practical codes, such as Raptor codes (discussed at the end of that paper), are covered by patents. Another network coding that is comparable to Raptor codes is Online codes. The following paper, by the creator of Online codes, presents an efficient algorithm for downloading large files using them: http://mnl.cs.stonybrook.edu/home/karthik/BitTorrent/papers/incentives/tore… /rateless_codes.ps IIRC, the creator of Online codes -- Petar Maymounkov -- started a company Rateless and was going to patent them. But Online codes fell into the scope of Digital Fountain's patents, who own the Raptor codes. So I don't know who owns the patents for Online codes anymore, but rest assured they're patented :( - Mike Quoting Nigini Oliveira <nigini(a)gmail.com>: >Hello All. > >I'm researching these days on some kind of codes that helps the distribution >of data at networks (Error Correcting Codes). I would like to know if >someone have good references (digital in preference) about how the real >systems implements these codes and related ideas. For example: How are the >files divided in pices to be shared? And how the pices are rebuild togheter? > >Thanks. > >-- >Nigini Abilio Oliveira >Mestrando em Computa??o >UFCG - DSC - COPIN >www.nigini.com.br >nigini(a)gmail.com >nigini(a)dsc.ufcg.edu.br > _______________________________________________ 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 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: [cryptography] bitcoin scalability to high transaction rates
by Nathan Loofbourrow 06 Jul '18

06 Jul '18

On Thu, Jul 21, 2011 at 8:41 AM, Sampo Syreeni <decoy(a)iki.fi> wrote: > On 2011-07-21, Marsh Ray wrote: > > I guess I don't see the need to do bitcoin crypto transactions at that >> speed any more than the other high-speed exchanges need to rapidly move >> stock certificates, hard cash, or perform ACH/EFTs. >> > > That's probably true. But then, HST is just an example of a mechanism which > creates prodigious amounts of transaction data. There are others, starting > simply with wide enough adoption of Bitcoin. So if the amount of transaction > data being shipped around can become a bottleneck here, it could indicate a > scalability limit on Bitcoin in more realistic situations. In practice, trades on Bitcoin exchanges don't create transactions in the Bitcoin crypto log; you can even give Bitcoins to one another within an exchange for the cost of an API call. It's only when money is transferred into our out of the exchange that a "real" transaction needs to be created, whether though Bitcoin or through a bank. Private markets can help aggregate small transactions. Of course, this presumes you trust the exchange, which is a different matter. n _______________________________________________ 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: [serval-project-dev] Implementing a different routing protocol
by Fraser Cadger 06 Jul '18

06 Jul '18

Hi everyone, It's been a wee while since my last post, but I was quite busy over the last couple of weeks and am only just turning my attention back to working with Serval. Ok, so I've had a think about how best to implement location update message (which I'll refer to as beacons), without modifying the existing message structures. My initial thought was to create a struct called beacon (or similar) which would contain all of the fields (initially our address, and the longitude and latitude coordinates + the timestamp of when the coordinates were recorded) and when we were sending a beacon we would create an instance of this struct. The downside I thought would be that the beacon struct would have to be embedded in another packet as a payload, and so this would mean modifying existing messages (not good) or creating a new message and adding the struct as a payload which seems wasteful. So at this point I can't see any advantages in using the struct (except possibly as a template). Instead I thought an approach similar to the node announcements could be used. A function called overlay_add_beacon() (for instance) could be called from overlay_init_packet(). The purpose of this would be to create the beacon message, it would be similar in form to overlay_route_add_advertisement(). So it would call call overlay_frame_build_header() to create the frame and then it would need to place the coordinates in the packet. I think the best way to do this would be to use a similar method to add_advertisement() which uses ob_append_byte() to add the best link score and observations to the packet, and before that overlay_address_append to add the address of the node we are advertising. However, if we are sending beacons for ourself then we do not need to append a subscriber address as the packet is obviously about us. Similarly, add_advertisement() is accessed by calling the callback function enum_subscribers() which is used to find the next (unadvertised) subscriber in the tree and the use of enum_subscribers() is obviously not necessary for sending messages about ourselves. Therefore, I was thinking that two types of beacons would be better; i.e. self_beacon and subscriber_beacon. self_beacon would be similar to a self announce message while subscriber_beacon would be similar to a node announcement. This would entail slight differences in how they were sent. self_beacon could have a method called overlay_add_self_beacon() which function similarly to overlay_add_selfannouncement() except instead of calling ob_append_ui32() to add timestamps it would call ob_append_byte() twice as described above, to add the two coordinates and timestamp (or would it make more sense to use ob_append_ui32 for this timestamp?) . However it would not call overlay_address_append. On the other hand, subscriber_beacon would have a method called (for instance) add_subscriber_beacon() that would function identically to overlay_route_add_advertisement(), and would call enum_subscribers() as a callback to a function called add_beacon() which would be similar to add_advertisement() except that it would call ob_append_byte to add coordinates (instead of score and observation), then append the timestamp but would still use overlay_append_byte() to add the address. Both overlay_add_self_beacon() and add_subscriber_beacon() would be called from overlay_init_packet() inside overlay_queue.c; with overlay_add_self_beacon() being called after overlay_add_selfannouncement() and add_subscriber_beacon() being called after overlay_route_add_advertisements() is called. Hopefully I'm right in thinking that doing this will mean that the self_beacon messages will go along with the self_announcement messages and the subscriber_beacon messages will be along with the corresponding node_advertisement messages for the same subscriber in the one real packet. Even if they are 'separated' (i.e. we receive a subscriber_beacon without a node_advertisement for the same subscriber) I could probably still handle it (i.e. search for that subscriber). Other than the above, I think the only other step needed for using the self_beacon and subscriber_beacon messages would be to add them to constants.h. Actually, I'm wondering what numbers to use, I noticed 0x10 to 0x70 are taken by existing messages. Should I just use the next numbers up (0x80 and 0x90), or are there any plans by the Serval team to use those? I'm assuming these numbers are hex numbers, and as type is an integer number constants.h maps the message type i.e. OF_TYPE_SELF_ANNOUNCE to its corresponding hex number? There might have been a couple of things I've misunderstood in the above, but I think the general approach I described should allow for me to add the beacon messages without causing any conflicts with devices running different versions or their own routing. Hopefully doing it the way I described above would mean that such devices would just ignore my beacon messages as they wouldn't recognise the codes for them and there would be no complications. I intend to start the coding soon, but I'm just thought I'd check to see if my assumptions are correct and if other people think the way of doing this makes sense before I jump in. I've not mentioned anything about dealing with the beacons once they've been received, as I've mainly been focussing on sending them first. However, I imagine this would involve updating either the subscriber or node entity for that device to change location. I'll look into this in more detail while I'm working on sending the beacons. Thanks, Fraser -- 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

Re: Wikipedia & Tor
by Roger Dingledine 06 Jul '18

06 Jul '18

On Tue, Sep 27, 2005 at 11:18:31AM -0400, Paul Syverson wrote: > On Tue, Sep 27, 2005 at 10:27:58AM -0400, Matt Thorne wrote: > > everyone is so worried about it, but has any one ever been successfully been > > able to use tor to effectively spam anyone? > > No. Cf. > http://tor.eff.org/faq-abuse.html#WhatAboutSpammers To be fair, this answer is yes. People have used Tor to deface Wikipedia pages, along with Slashdot pages, certain IRC networks, and so on. I think that counts as spam at least in a broad sense. > A potential for cooperation is the proposal below for authenticated > access to Wikipedia through Tor. I will not speak to any particular > design here, but if Wikipedia has a notion of clients trusted to post > to Wikipedia, it should be possible to work with them to have an > authentication server that controls access to Wikipedia through Tor. As I understand it, Jimmy is hoping that we will develop and maintain this notion. We would run both "halves" of the Tor network, and when they complain about a user, we would cut that user out of the authenticated side. Jimmy and I talked about Tor-and-Wikipedia many months ago, and the conclusion was that they (mediawiki) would be willing to try a variety of technological solutions to see if they work (i.e. cut down on vandalism and aren't too much of a burden to run). My favorite is to simply have certain address classes where the block expires after 15 minutes or so. Brandon Wiley proposed a similar idea but where the block timeout is exponentially longer for repeated abuse, so services that are frequently blocked will stay blocked longer. This is great. But somebody needs to actually code it. Wikipedia already needs this sort of thing because of AOL IPs -- they have similar characteristics to Tor, in that a single IP produces lots of behavior, some good some bad. The two differences as I understand them are that AOL will cancel user accounts if you complain loudly enough (but there's constant tension here because in plenty of cases AOL decides not to cancel the account, so Wikipedia has to deal some other way like temporarily blocking the IP), and that it's not clear enough to the Wikipedia operators that there *are* good Tor users. (One might argue that it's hard for Wikipedia to change their perception and learn about any good Tor uses, firstly because good users will blend in and nobody will notice, and secondly because they've prevented them all from editing so there are no data points either way.) So I've been content to wait and watch things progress. Perhaps we will find a volunteer who wants to help hack the mediawiki codebase to be more authentication-friendly (or have more powerful blocking config options). Perhaps we'll find a volunteer to help build the blind-signature pseudonymous authenticated identity management infrastructure that Nick refers to. Perhaps the Wikimedia operators will increasingly get a sense that Tor has something to offer besides vandalism. (I presume this thread re-surfaced because Tor users and operators are periodically telling Wikipedia that they don't like being blocked.) Maybe we will come to the point eventually that it makes sense to do something different than blocking the Tor IP addresses from editing Wikipedia. (Which, we should all remember compared the Gentoo forum situation, is a great step above blocking them from both reading and writing.) It could be that we never reach that point. Certain services on the Internet (like some IRC networks) that are really prone to abuse are probably doing the right thing by blocking all Tor users (and all AOL users, and all open proxies, and ...). And we want to keep Tor easy to block, or we're really going to start getting the other communities angry at us. In summary, I'm not too unhappy with the status quo for now. Tor needs way more basic development / usability work still. In the absence of actual volunteers-who-code on the side of Tor _or_ Wikipedia to resolve the problem, I'm going to focus on continuing to make Tor better, so down the road maybe we'll be able to see better answers. --Roger ----- 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

Re: Wikipedia & Tor
by Roger Dingledine 06 Jul '18

06 Jul '18

On Tue, Sep 27, 2005 at 11:18:31AM -0400, Paul Syverson wrote: > On Tue, Sep 27, 2005 at 10:27:58AM -0400, Matt Thorne wrote: > > everyone is so worried about it, but has any one ever been successfully been > > able to use tor to effectively spam anyone? > > No. Cf. > http://tor.eff.org/faq-abuse.html#WhatAboutSpammers To be fair, this answer is yes. People have used Tor to deface Wikipedia pages, along with Slashdot pages, certain IRC networks, and so on. I think that counts as spam at least in a broad sense. > A potential for cooperation is the proposal below for authenticated > access to Wikipedia through Tor. I will not speak to any particular > design here, but if Wikipedia has a notion of clients trusted to post > to Wikipedia, it should be possible to work with them to have an > authentication server that controls access to Wikipedia through Tor. As I understand it, Jimmy is hoping that we will develop and maintain this notion. We would run both "halves" of the Tor network, and when they complain about a user, we would cut that user out of the authenticated side. Jimmy and I talked about Tor-and-Wikipedia many months ago, and the conclusion was that they (mediawiki) would be willing to try a variety of technological solutions to see if they work (i.e. cut down on vandalism and aren't too much of a burden to run). My favorite is to simply have certain address classes where the block expires after 15 minutes or so. Brandon Wiley proposed a similar idea but where the block timeout is exponentially longer for repeated abuse, so services that are frequently blocked will stay blocked longer. This is great. But somebody needs to actually code it. Wikipedia already needs this sort of thing because of AOL IPs -- they have similar characteristics to Tor, in that a single IP produces lots of behavior, some good some bad. The two differences as I understand them are that AOL will cancel user accounts if you complain loudly enough (but there's constant tension here because in plenty of cases AOL decides not to cancel the account, so Wikipedia has to deal some other way like temporarily blocking the IP), and that it's not clear enough to the Wikipedia operators that there *are* good Tor users. (One might argue that it's hard for Wikipedia to change their perception and learn about any good Tor uses, firstly because good users will blend in and nobody will notice, and secondly because they've prevented them all from editing so there are no data points either way.) So I've been content to wait and watch things progress. Perhaps we will find a volunteer who wants to help hack the mediawiki codebase to be more authentication-friendly (or have more powerful blocking config options). Perhaps we'll find a volunteer to help build the blind-signature pseudonymous authenticated identity management infrastructure that Nick refers to. Perhaps the Wikimedia operators will increasingly get a sense that Tor has something to offer besides vandalism. (I presume this thread re-surfaced because Tor users and operators are periodically telling Wikipedia that they don't like being blocked.) Maybe we will come to the point eventually that it makes sense to do something different than blocking the Tor IP addresses from editing Wikipedia. (Which, we should all remember compared the Gentoo forum situation, is a great step above blocking them from both reading and writing.) It could be that we never reach that point. Certain services on the Internet (like some IRC networks) that are really prone to abuse are probably doing the right thing by blocking all Tor users (and all AOL users, and all open proxies, and ...). And we want to keep Tor easy to block, or we're really going to start getting the other communities angry at us. In summary, I'm not too unhappy with the status quo for now. Tor needs way more basic development / usability work still. In the absence of actual volunteers-who-code on the side of Tor _or_ Wikipedia to resolve the problem, I'm going to focus on continuing to make Tor better, so down the road maybe we'll be able to see better answers. --Roger ----- 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

Handbook for bloggers and cyber-dissidents
by Thomas Sj?gren 06 Jul '18

06 Jul '18

Reporters Without Borders (Reporters sans fronti?res, RSF) has released a "Handbook for bloggers and cyber-dissidents": http://www.rsf.org/rubrique.php3?id_rubrique=542 Topics include: How to blog anonymously Technical ways to get around censorship Ensuring your e-mail is truly private Internet-censor world championship >From the chapter "How to blog anonymously": "Step five - Onion Routing through Tor [...] Given the complexity of the technology, Sarah is pleasantly surprised to discover how easy it is to install Tor, an onion routing system. She downloads an installer which installs Tor on her system, then downloads and installs Privoxy, a proxy that works with Tor and has the pleasant side benefit of removing most of the ads from the webpages Sarah views. After installing the software and restarting her machine, Sarah checks noreply.org and discovers that she is, in fact, successfully "cloaked" by the Tor system - noreply.org thinks shes logging on from Harvard University. She reloads, and now noreply thinks shes in Germany. From this she concludes that Tor is changing her identity from request to request, helping to protect her privacy. This has some odd consequences. When she uses Google through Tor, it keeps switching language on her. One search, its in English - another, Japanese. Then German, Danish and Dutch, all in the course of a few minutes. Sarah welcomes the opportunity to learn some new languages, but shes concerned about some other consequences. Sarah likes to contribute to Wikipedia, but discovers that Wikipedia blocks her attempts to edit articles when shes using Tor. Tor also seems to have some of the same problems Sarah was having with other proxies. Her surfing slows down quite a bit, as compared to surfing the web without a proxy - she finds that she ends up using Tor only when shes accessing sensitive content or posting to her blog. And shes once again tied to her home computer, since she cant install Tor on a public machine very easily. Most worrisome, though, she discovers that Tor sometimes stops working. Evidently, her ISP is starting to block some Tor routers - when Tor tries to use a blocked router, she can wait for minutes at a time, but doesnt get the webpage shes requested." -- ----- 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

Re: <nettime> Steve Coll: Leaks (The New Yorker)
by carl guderian 06 Jul '18

06 Jul '18

On 13-nov-2010, at 10:12, Patrice Riemens wrote: > Waiting for Wikileaks to 'disclose and expose' war crimes to start > this discussion appears to me to be singularly unhelpful, and > that in many respects. Wikileaks simply bridges the gap between > what we had every good reasons to believe - and has been quite > well documented elsewhere, if not to such an (alas basically > indigestible) extent - and what we now know for fact. I don't > consider this a giant leap forward. I'd say the leaks have been a very big help, though unfortunately not in leading to official acknowledgment, let alone dealing with, the activities cited therein. What it has done is further document how our (meaning US) "best and brightest" news organizations and opinion leaders abandoned their responsibiliities before, during and after the Iraq war. As they continue to do, in that and in other matters. Tellingly, one editorial response to the leaks, after flat-out denials and hysterical worries about security, was that this wasn't news because "everyone knew" about the events. That last was somewhat true. Some of the stories, even backed with evidence, had leaked out over the years. But if reported at all, they were most often buried deep within a long story. And if a government spokesmen bellowed "nonsense," there was no follow-up and it was back to horse-race political reporting, murdered blonde college girls and wardrobe malfunctions at the Super Bowl. So "everyone" did know about this stuff, but just didn't think it important enough share it with the rest of us. Those who did they damned as "unserious." (George W. Bush's memoirs show a man who perfectly embodied this emphasis on fluff over substance. Anguish not over federal bumbling over Katrina, but over rapper Kanye West saying Bush didn't care about black people. No regrets over attacking Iraq at all, but allowing that the "Mission Accomplished" photo op may have been premature.) Wikileaks is your friend who's sick of seeing those you thought were your friends lying to you. So he grabs you by the shoulders and lays it out for you. You're in all kinds of trouble but your "friends" kept you distracting from seeing it and often covered up for those responsible for some of it. And Wikileaks brings one piece of evidence after another until you can no longer ignore the bullshit. And it's necessary, because the lying continues. Three years after the financial collapse, there's a lot in the news about foreclosures and the op-ed pages are debating over whether or not it's shameful to squat one's own repossessed house or just walk away. There's nothing about bankers enjoying record bonuses while "losing" evidence of mis- and malfeasance. Ten percent (really higher) unemployment, possibly permanent, but only cutting the deficit matters, with "hard choices" to be made. Pundits saying gravely that Americans must face Social Security cuts to make America great again (though nothing about bankers giving up bonuses). And Americans will suck it up rather than demand justice or better health care because the 2010 elections US is a "center-right" nation (not that voters are despairing). But it sucks when you suspect you're being played, and it sucks even harder when it's proved to you and you can no longer pretend otherwise. It's the sort of enlightenment that doesn't bring comfort but instead removes it. When a person yanks off the blinders, thanking them isn't your first response and sometimes not even your second. The sooner Wikileaks destroys what's left of the official media's credibility, the better. But it's not something we'll thank them for, and I'm sure they know it. I don't think anyone's laughing over there. Carl # 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