- cypherpunks - lists.cpunks.org

Fw: Automatic reply: Assange "fails in bid to delay extradition battle with US" Barrister Jennifer Robinson
by jim bell 22 Oct '19

22 Oct '19

----- Forwarded Message ----- From: Jennifer Robinson <j.robinson(a)doughtystreet.co.uk>To: jim bell <jdb10987(a)yahoo.com>Sent: Monday, October 21, 2019, 11:33:51 PM PDTSubject: Automatic reply: Assange "fails in bid to delay extradition battle with US" Barrister Jennifer Robinson I am currently in New York (EST) for work. I will be checking emails regularly, but if the matter is urgent please contact my clerk Callum Stebbing c.stebbing(a)doughtystreet.co.uk. Thank you

1 0

Jim Bell's adversity
by Zenaan Harkness 22 Oct '19

22 Oct '19

Hi Jim, I want to know - were you ever offered any "sell out" type of option from the prosecutors who put you in jail for all those years?

3 8

WIRED: IBM Says Google’s Quantum Leap Was a Quantum Flop
by jim bell 22 Oct '19

22 Oct '19

WIRED: IBM Says Google’s Quantum Leap Was a Quantum Flop. https://www.wired.com/story/ibm-googles-quantum-leap-quantum-flop

1 0

riots in chile
by Punk - Stasi 2.0 22 Oct '19

22 Oct '19

https://www.bbc.com/news/world-latin-america-50106743 one obvious question : to what degree are the riots the result of a facebook-nsa-fukerberg-pentagon-etc experiment. as an interesting aside their are not mentioned here https://consortiumnews.com/ - I guess that site is an even bigger piece of shit than I thought.

2 1

Tik-Tok... It's NOT just for Pepe Pervs
by Razer 22 Oct '19

22 Oct '19

The company Nazis keep! Just wonder if they use pink hearts too? "Islamic State propagandists are reportedly trying to exploit social media app TikTok as a recruiting tool. The Wall Street Journal says social media monitoring agency Storyful recently identified around two dozen ISIS-related accounts, all of which have since been removed. The accounts posted videos aimed at recruiting followers and bolstering support for the terrorist group — featuring Islamic State anthems and footage of corpses and ISIS fighters. It’s not clear how big a presence ISIS has on TikTok. Terrorist propaganda is a perennial issue for social media platforms. Companies like Facebook and Google share a database of known terrorist imagery that can be automatically removed when it’s detected online. They’ve also faced (and won) several lawsuits for allowing it even temporarily on their platforms. Facebook said in September that it removed more than 26 million pieces of global terrorist propaganda over the past two years. TikTok’s parent company ByteDance didn’t immediately respond to a request for comment about how much terrorist content TikTok finds and takes down. The accounts that Storyful identified also appear to be relatively small. The Journal identifies one video as earning 68 likes and some accounts as having around 1,000 followers; Storyful didn’t immediately confirm whether that’s typical of the accounts’ popularity, or whether these are the first accounts they’ve found on TikTok. TikTok videos circulate largely thanks to TikTok’s recommendation algorithm. And in this case, it’s not clear that the algorithm is promoting ISIS content, just that this content exists on the hugely popular platform. However, as the Journal notes, TikTok has a young user base and is known for lighthearted, joke-y content — sometimes to the point of alleged political censorship. So there’s an added incongruity when it’s used by terrorists." https://www.theverge.com/2019/10/21/20925416/tiktok-islamic-state-terrorist… Rr Sent from my Androgyne dee-vice with K-9 Mail

1 0

covfefe net stream types
by Zenaan Harkness 22 Oct '19

22 Oct '19

Attached. This is just a grab bag needing adding to.

1 0

covfefe packet switched network - user routing - hiding hop counts/ routing info, from intermediate nodes and GPAs
by Zenaan Harkness 21 Oct '19

21 Oct '19

Example: A routes packet P, via nodes B then C, to node D. Nodes: A B C D PK means "public key", each node knows the PK of the other nodes it communciates with or routes to. Using PK is shorthand - actual encrypted link usually uses PK crypto to negotiate a symmetric session key, which might be changed over time and other complexities, but for the purpose of comprehending basic implementation steps and understanding issues arising, it's sufficient to think in simpler terms of just per node public keys. "Physical" hops in the following example routes: AB BC CD "Virtual" routes we can consider in examples: AB ABC ABCD and also BC, BD, and CD Each hop, e.g. AB, needs their comms to be encrypted to protect from eves droppers. So when A sends P to B, P is encrypted with B's PK. We can use a notation like B(P) to mean encrypt P with B's PK. Similarly notation B'(B(P)) to mean decrypt B(P) to get the raw/unencrypted packet P, from the encrypted version B(P). 1) A sends P only to B 1.1 A encrypts P to B, i.e. sending B(P) to B 1.2 B decrypts, doing B'(B(P)) to get P 2) A sends P to C, via B A wants B to not read P, only to forward C(P) on to C; So, naievely, A sends C(P) to B, with a request to forward C(P) onwards to C. This is naieve, since two problems arise: i) A's request to B is not encrypted, only P is encrypted as C(P). ii) A sends the encrypted packet C(P) first to B (with the routing instruction), and then B also sends C(P) (without any additional routing instructions), to C, but the same set of encrypted bytes has been sent first via AB, and second via BC; the obvious problem with this is that an onlooker (GPA), can simply see that "something" (encrypted) has been sent from A to C, which defeats the purpose of A sending via B at all - there is no benefit over just sending C(P) directly to C. This particular sub-problem can be solved in a couple of immediate ways: I) B receives C(P) from A, so instead of sending that to C, it sends C(C(P)) to C, which C can decrypt, but C needs to know, or guess how many layers to unwrap, and this puts extra unnecessary load on C - the more hops, the more load on the end point of the route, aka not good. II) A first encrypts P using C's PK, then does similarly for node B, so sending B(C(P)) to B, which B decrypts to get C(P), which B can on-send to node C with no extra encryption effort! This puts the load on A, to encrypt its packets according to the total route desired. This is logical, as A wants to minimize trust in any downstream nodes, so doing the work yourself pays off with certainty and less need for trust, greater privacy, and while A is at it, it can embed the required routing header for each hop, into the appropriately layer, thus encrypting all routing requests. A routing header can be denoted with the letter "r", followed if needed by the node letter for the target node of the route request, e.g. "rC" means "route this packet to node C". So for A to 'properly' send P to node C: 2.1 A sends B(rC+C(P)) to node B 2.2 B decrypts, getting rC + C(P) 2.3 B sends C(P) to node C An obvious information exposure bug in steps 2.1 and 2.3 is that the unless we somehow compensate for this, the packet B(rC+C(P)), is larger than the packet C(P) - so our GPA snoop can see that A's packet sent to B, is larger than B's packet sent to C, and it's not hard to guess that the difference is gonna be routing information. The simple solution to different packet sizes is to rely on B to pad C(P) with some random bytes (which need to be ignored by C), so that it's the same size as B(rC+C(P)). But this means once again, relying on B to do the right thing here. Can we get around this reliance on B? The problem only gets worse as we go to an example that includes the next hop, CD... Separating routing requests into separate packets ("control" packets or whatever we might call them) would have downsides of extra buffering and latency to handle dropped packets, packet sequence problems (we're talking UDP here), lower-level packet routing timing issues, requests to resend packets that don't arrive after a timeout etc etc. This is way too complex (reimplementing TCP basically), so forget that - routing requests must be embedded, attached or otherwise be very closely associated, with the packets being routed. Whether routing info is a "tag", a "byte", an IP (v4 or v6) address or etc doesn't matter - a smaller header doesn't make the problem go away, AFAICS.

1 0

South China Sea newspaper article of some interest what do you think
by ilsa 21 Oct '19

21 Oct '19

Share. Enjoy

2 1

[gilmay97@gmail.com: GESTAPO TYPE CENSORSHIP?]
by Zenaan Harkness 20 Oct '19

20 Oct '19

Folks, this is what Free Speech looks like from the hand of Zuckerberg, the New York Times and CNN. ----- Forwarded message from Gil May <gilmay97(a)gmail.com> ----- From: Gil May <gilmay97(a)gmail.com> Date: Sun, 20 Oct 2019 16:32:01 +1000 Subject: GESTAPO TYPE CENSORSHIP? *The Day Mark Zuckerberg publishes FREE SPEECH DECLARATION in WSJ, Facebook Deletes One of the Largest Donald Trump Facebook Fan Pages with 3,276,000 Fans* FACEBOOK DELETES ONE OF THE LARGEST DONALD TRUMP FACEBOOK FAN PAGES WITH 3,276,000 FANS! By Freedom Headlines, <https://freedomheadlines.com/the-latest/facebook-deletes-one-of-the-largest…> October 17 2019: Facebook is stepping up their game to try and prevent Donald Trump from winning reelection. They are quite literally meddling in the election process by using their influence and reach to censor the internet and prevent people with opposing views from sharing anything from a conservative viewpoint. The social network giant just removed one of the largest (if not the largest) pro-Trump Facebook fan pages. They cited that it was because, *“It looks like recent activity on your Page doesn’t follow the Facebook Page Policies regarding impersonation and pretending to be an individual or business.”* ----- End forwarded message -----

3 3

Re: OnionShare Tor
by John Young 19 Oct '19

19 Oct '19

Most promising. If USG and other governments are not involved. Big if. At 11:16 PM 10/15/2019, you wrote: >https://blog.torproject.org/new-version-onionshare-makes-it-easy-anyone-pub… > >https://github.com/cretz/bine >https://github.com/jstrieb/urlpages >http://wiki.yacy.net/index.php/En:YaCy-Tor >https://blog.kozubik.com/john_kozubik/2009/06/free-speech-or-stone-age.html >https://www.arweave.org/

9 17