October 2019 - cypherpunks - lists.cpunks.org

Piracy: Strike3 gets Struck Out of Copyright Subpoena Game
by grarpamp 30 Oct '19

30 Oct '19

https://torrentfreak.com/us-court-shields-internet-subscribers-from-futile-… https://torrentfreak.com/images/strikedeny.pdf A New Jersey district court has issued a devastating order against Strike 3 Holdings, the most active filer of piracy lawsuits in the US. In four separate cases, the court denied a request to obtain identities of alleged BitTorrent pirates. The court argues that the underlying complaints are futile. Even if they held up, other issues such as the privacy of the accused and Strike 3's failure to use other enforcement tools, would warrant a denial. Last week, New Jersey District Court Magistrate Judge Joel Schneider denied Strike 3 expedited discovery in four cases. This means that it's not allowed to subpoena ISPs for the personal details of account holders whose IP-addresses were used to share pirated videos via BitTorrent. In a very detailed 47-page opinion, the Judge takes apart various aspects of Strike 3's enforcement efforts. He makes it clear that these cases should not be allowed to go forward, as the complaints are futile. "The most fundamental basis of the Court's decision is its conclusion that, as pleaded, Strike 3's complaints are futile. The Court denies Strike 3 the right to bootstrap discovery based on a complaint that does not pass muster," Judge Schneider writes. The futility lies in the fact that the complaints themselves include very few facts. The only thing that the company really knows is that an IP address is associated with downloading copyrighted works. Strike 3 doesn't know whether the subscriber is involved in the actual infringements. Courts have previously ruled both in favor and against allowing discovery to expose the account holders in these situations, but the New Jersey Court clearly sides with the latter. "The Court sided with the cases that hold it is not sufficient to merely allege in a pleading that the defendant is a subscriber of an IP address traced to infringing activity. Consequently, the Court will not authorize Strike 3 to take discovery premised on a futile John Doe complaint." The decision is partly based on the aforementioned "Cobbler" ruling of the Ninth Circuit Court of Appeals. However, the Court makes it clear that even if there was a properly pleaded infringement claim, the requests for expedited discovery would still be denied. In the opinion, Judge Schneider sums up the other issues as follows: (1) Strike 3 bases its complaints on unequivocal affirmative representations of alleged facts that it does not know to be true. (2) Strike 3's subpoenas are misleading and create too great of an opportunity for misidentification. (3) The linchpin of Strike 3's good cause argument, that expedited discovery is the only way to stop infringement of its works, is wrong. (4) Strike 3 has other available means to stop infringement besides suing individual subscribers in thousands of John Doe complaints. (5) The deterrent effect of Strike 3's lawsuits is questionable. (6) Substantial prejudice may inure to subscribers who are misidentified. (7) Strike 3 underestimates the substantial interest subscribers have in the constitutionally protected privacy of their subscription information.

1 0

Fwd: Dear Shirlene,
by AlXBert2 29 Oct '19

29 Oct '19

[image: image.png] ---------- Forwarded message --------- From: AlXBert2 <alxbert2(a)gmail.com> Date: Mon, Oct 28, 2019 at 2:03 PM Subject: Fwd: Dear Shirlene, To: <info(a)nativehawaiianveterans.com> YOU HAD BETTER NOT TELL ANYONE ABOUT THIS SOLDIER! DO YOU UNDERSTAND ME?!?!?! ---------- Forwarded message --------- From: AlXBert2 <alxbert2(a)gmail.com> Date: Mon, Oct 28, 2019 at 10:21 AM Subject: Dear Shirlene, To: <shirlene(a)gophawaii.com> Just don't hide it. Thank you. ---------- Forwarded message --------- From: AlXBert2 <alxbert2(a)gmail.com> Date: Fri, Oct 25, 2019 at 2:10 AM Subject: Fwd: p00010090 To: <qkk(a)kawananakoa.com> ---------- Forwarded message --------- From: AlXBert2 <alxbert2(a)gmail.com> Date: Thu, Oct 24, 2019 at 12:36 PM Subject: Fwd: p00010090 To: <QuentinKawananakoa(a)gmail.com> ---------- Forwarded message --------- From: AlXBert2 <alxbert2(a)gmail.com> Date: Wed, Oct 23, 2019 at 11:56 PM Subject: p00010090 To: <JosephRobinetteBidenJr(a)gmail.com> Please look into dis bruh, forget da video, look into da words! https://archive.org/details/the.apprenticeshort1

1 0

Silk Road: A Cautionary Tale about Online Anonymity
by jim bell 29 Oct '19

29 Oct '19

https://medium.com/@marcell74/the-silk-road-a-real-thriller-and-the-truth-a…

1 0

Motorola Drops New $5K APX Datamining AI Radios
by grarpamp 29 Oct '19

29 Oct '19

https://www.fastcompany.com/90421191/motorola-is-building-a-new-kind-of-wal… Every Order Follower to get New Radios on Your Dime, and Third Party Corps get to Datamine Your Ass for free as their new Proxy Service.

1 0

Journalist Max Blumenthal Busted For Venezuelan DC Embassy Protection Reporting
by Razer 29 Oct '19

29 Oct '19

The floodgates of Journalistic Represssion have opened wide: "Max Blumenthal, the editor of the news site The Grayzone, was arrested on the morning of October 25 on a fabricated charge related to the siege of the Venezuelan embassy in Washington, DC that took place between April and May. A team of DC police officers appeared at Blumenthal’s door at just after 9 AM, demanding entry and threatening to break his door down. A number of officers had taken positions on the side of his home as though they were prepared for a SWAT-style raid. Blumenthal was hauled into a police van and ultimately taken to DC central jail, where he was held for two days..." https://thegrayzone.com/2019/10/28/this-charge-is-one-hundred-percent-false… Rr Sent from my Androgyne dee-vice with K-9 Mail

1 0

Autumn of Censorship
by Ryan Carboni 29 Oct '19

29 Oct '19

https://www.usatoday.com/story/news/politics/2019/10/28/abu-bakr-al-baghdad… Post correspondents have spent years in Iraq and Syria documenting ISIS savagery, often at great personal risk. Unfortunately, a headline written in haste to portray the origins of al-Baghdadi and ISIS didn't communicate that brutality. The headline was promptly changed. The greater the picture one has, the more speechless one becomes. And so we all consent to the present regime.

3 2

Re: SRT - Re: UDP based data xfer protocols
by Zenaan Harkness 29 Oct '19

29 Oct '19

----- Forwarded message from ... ----- To: Zenaan Harkness <zen(a)freedbms.net> Date: Tue, 29 Oct 2019 13:10:13 +1100 Subject: Re: [zen(a)freedbms.net: SRT - Re: UDP based data xfer protocols] Hi Zen, don't really understand your court action - but hey - good luck. I just broadly read your docs about a tor replacement. IMHO - the biggest issues for performance, latency, reliability etc : - doesn't concern the ISP, it's usually your own outbound limit - especially for QoS. - secondly, your own inbound limit. - then after your own limits, it's fair access to the whole network. - not sure if you totally understand TCP - which most internet stuff uses - especially TCP windows. It has a start small, go faster, until it fails then back off a bit. eventually it tries to have a reasonable window size based on the latency and bandwidth of equipment involved. the 'window' is the tcp packet size, how many to have in flight, etc. If you have a big bandwidth (say 100Mbps at both ends), and the latency is low, say sydney to Melbourne, it's fairly easy for it to work out packet sizes to get to 100Mbps. But if it's further away, say Sydney to LA. It takes longer to converge to 100Mbps, if at all. Any if there is some equipment in the middle, or either end, that is lacking 100Mbps, it has to work that out. - with a private / secure / tor arrangement, in the middle you may need some 'fairness' - otherwise connections with 1Gbps or more will just swamp the whole system. - i think what I'm trying to say, there are bigger problem than ISPs honouring QoS. I'm currently using something called zero-teir. It's only routing for me, and only private for me. But it works well, and has a nice routing network. easy to run, and configure. you can have several 'networks'. It is peer-to-peer discovery , and/or routing through existing nodes. It could easily be used for a 'trading partners' scenario - where you add 'nodes' that you trust. It might even be a reasonable backbone, to piggy back your own private communications on. You can run on your own or public routers (they call them moons). I run my own 'moon router' for increased availability near my nodes. zero-teir seems to have low latency, great reliability, great discovery, great uptime, ease of use, good o/s support. you can do cool things on zero-teir. Like have 1 exposed/internet node in a location. and nodes in that location don't even need internet access, will discover that node, and route through it. openvpn is older, secure, and widely used. But it's sort of a pig to configure and scale. AFAIK it's only 'hub and spoke' which is a total F'up in my opinion. Scott On Tue, Oct 29, 2019 at 11:42 AM Zenaan Harkness <zen(a)freedbms.net> wrote: > on the cypherpunks mailing list a few of us have begun to map > out various design contraints for a replacement to the Tor network - > that is, something which will (it is intended) meaningfully improve > on various of the known flaws in Tor. > > Private communications is of course fundamental to our basic human > rights to private and free speech, which we need if those not in > power at any given time, are to have any hope of holding to account > for their misdeeds, those in power. > > Presently, the "Example questions" I posed yesterday (underlined in > the email below), are outside my personal realm of knowledge and > experience, so I need to find someone I can communicate with who has > such knowledge, so they and I can kick the can around on this topic. > > Kind regards, > Zen > ----- Forwarded message from Zenaan Harkness <zen(a)freedbms.net> ----- > > From: Zenaan Harkness <zen(a)freedbms.net> > To: CypherPunks <cypherpunks(a)lists.cpunks.org> > Date: Mon, 28 Oct 2019 23:48:43 +1100 > Subject: SRT - Re: UDP based data xfer protocols > List-Id: The Cypherpunks Mailing List <cypherpunks.lists.cpunks.org> > > Secure Reliable Transport > https://en.wikipedia.org/wiki/Secure_Reliable_Transport > > Secure Reliable Transport is an open source video transport > protocol developed originally by Haivision. According to SRT > Alliance, an organisation that promotes the technology, it > optimises streaming performance across unpredictable networks, such > as the Internet, by dynamically adapting to the real-time network > conditions between transport endpoints. This helps minimise effects > of jitter and bandwidth changes, while error-correction mechanisms > help minimise packet loss. SRT supports end-to-end encryption with > AES.[1] When performing retransmissions, SRT only attempts to > retransmit packets for a limited amount of time based on the > latency as configured by the application.[2] > > The reference implementation of the protocol was originally > published under the Lesser General Public License version 2.1,[3] > but was relicensed under the Mozilla Public License on 22 March > 2018.[4] > > SRT is supported in the free software multimedia frameworks > GStreamer, FFmpeg, and in VLC free software media player.[2][5] > > > > Notes: > > - low latency connections want no (or minimized) buffering > > - bulk fill traffic does not care about buffering, just wants > everything to be (eventually) delivered > > - net/switch control packets want no buffering/ maximum priority > > So, buffering desirability is related to the traffic class - we could > have a QoS field in each packet. > > An open question is MTU and packet size - do we have say 2 or three > packet sizes corresponding to traffic classes, do we have a single > packet size and if so, what size should that be - in the case we are > sending net/switch control messages at high prio, average (encrypted) > packet size containing such control msgs might be very small, say 20 > bytes. > > Even if "net/switch" control msg packet size needs to be say 150 > bytes to contain the largest such messages, do we want to burden such > packets with "having to be a set size of ~MTU, say 1.5KiB? > > We need an ISP/backbone guru to talk to on some of these issues - > to suggest what would work today, and what could work (if the IQNets > userbase is sufficiently large, which it will be), from their > perspective. > > I met some Telstra backbone guys some years back - the wholesale side > of our old Australian Telecom network that was ripped from under the > nation for a few silver coins, but no longer have their contact > details. > > > Example questions: > ------------------ > > Is ISP (and GT-1 etc) physical equipment, possibly able to honour > QoS for rare but important net/switch control packets? > > Would such packets need to be a maximum size, say 150 bytes (or > even less), rather than MTU bytes? > > Is such GT*, or perhaps rather, end user facing ISP equipment, able > to handle users who might try to game such QoS offerings by say > rate limiting such packets on a per end user node basis (to say, > 2kbps or whatever...)? > > > If we get a handle on these types of questions, IQNets might actually > be very appealing to the GT* guys, to optimize everything with > proactive, rather than reactive, traffic management. UTP goes a long > way to handling bittorrent, but there seems to be a lot of > opportunity for full stack (right up to apps) improvement here... > > ... and pushing this up the the stack makes sense if the lowest level > guys can provide. > > If they can't provide today, then tomorrow's equipment will provide > if the picture is compelling and widespread. > > > ----- End forwarded message ----- > ----- End forwarded message -----

1 0

Nextgen G* Traffic Analysis Resistant Overlay Networks (re Tor stinks)
by grarpamp 29 Oct '19

29 Oct '19

On 10/26/19, Punk - Stasi 2.0 <punks(a)tfwno.gf> wrote: > > 2005 Low-Cost Traffic Analysis of Tor > https://www.freehaven.net/anonbib/cache/torta05.pdf > > > "By making these assumptions, the designers of Tor believe it is safe to > employ only minimal mixing of the stream cells... > > ...This choice of threat model, with its limitation of the adversaries’ > powers, has been a subject of controversy... > > ...Tor, on the other hand assumes a much weaker threat model.. > > ...we show that even relatively weak adversaries can perform > traffic-analysis, and get vital information out of Tor. This means that even > non-law-enforcement agencies can significantly degrade the quality of > anonymity that Tor provides, to the level of protection provided by a > collection of simple proxy servers, or even below." > > ------- > > my comment : the attack is based on monitoring the latency of a node while > sending an attacker controlled stream through it > > > "Tor exhibits the worst possible behaviour: not enough interference to > destroy individ- > ual stream characteristics, yet enough to allow the remote measurement of > the node’s load." > > > Maybe some tor fanboi knows if this has been somehow fixed? Tor, perhaps as result of years of such papers and posts, is attempting to incorporate some traffic noise, search there for "netflow" and "padding", however the breadth of its application may not be enough to close out many of the traffic analysis papers. People should look more closely at that work and analyse its results. > Anyway the article makes it clear that simple cover traffic in not enough > to defend against timing attacks. This may be one of the papers that may outlines why, in a fill padding chaff wheat network, or even any network, that every node also needs to reclock the input it receives into its output, else adversary can see the perturbations it applies to a nodes input reflected in its output, and or see the natural perturbations the internet itself imparts, and those of the users own traffic patterns, carried through end to end without mitigation. Also why, similar to some Bittorrent and other protocols, overlay nodes should probably drop contracts they have with other peer nodes that do not fulfill input performance expectations. ie: Bittorrent nodes (clients) ignore nodes that send corrupted datas... overlays should drop peer nodes that exhibit non conformant traffic characteristics... such as unclocked, bursty waves, etc that was not agreed to, that would present risk to observability. ie: First, don't accept sketchy peers trying to send you suspect waveforms to carry, and Second, do not forward anything on through you to another node without conforming and reclocking it, don't be so busy or partition attacked that your node can't uphold that thus becoming a risk to the net, sleep and reestablish your node into the net later. Since an overlay network does not yet own the underlying internet hardware (and there is not yet full time crypted link rate fill HW RFC), this must be done in nodes CPU versus at the NIC PHY over the cable. You can get closer to Layer0 with #OpenFabs #OpenHW #MeshNets #GuerrillaNets. Note also there is a difference in design thinking approaches between say... - Cover traffic, meaning traffic laid over or filling in gaps in wheat. The wheat ends up being awarded a variety of mental biases and design assumptions in its favor which could prove controlling and exploitable. - Base fill traffic, meaning a base of fill [at linerate, fulltime, regulated], such that when wheat is ready to pass, the wheat packet is substituted in for the fill packet. The fill security aspect is mentally biased for, such that it should continue to hold regardless whatever wheat or active adversary crap is attempted to be sent over or at it. There's something to be said for "store and forward" overlays on the order of hours to days... file storage, email / nntp. Unfortunately they're no good for anything interactive realtime... IRC, urgent messaging, website queries, transactions, voice, video. There's also consideration to make on whether an interactive realtime network should also provide, if needed, a store and forward layer, or treat it as just another app riding on top, as all realtime nets do today. Or whether to cripple either s+f or realtime to preclude use of the other over them. ie: Tor is somewhat crippled by TCP only. Whereas I2P/Tor+OnionCat, CJDNS, Phantom enable UDP etc by providing a full IPv6 stack. Other overlays have similar restrictions and capabilities, most not intentionally preclusive, instead being just "We want to create a net to do X (say send an email)" and the net just ended up being useless for anything else. Keep in mind, once you have a cryptographically strong analysis resistant general purpose overlay transport network (ie: internet stack), you can run anything over it. Don't be afraid to create an AF_OVERLAY if needed to accomplish that. If the overlay network is truly good, people will get todays applications ticketed, patched, and compiled with that option to inferface with them.

3 17

ZDNet: Top Linux developer on Intel chip security problems: 'They're not going away.'
by jim bell 29 Oct '19

29 Oct '19

ZDNet: Top Linux developer on Intel chip security problems: 'They're not going away.'. https://www.zdnet.com/article/top-linux-developer-on-intel-chip-security-pr…

1 0

SeaSteading: Space and other Legal Voids re Secession, Purchase, Sovereignty, FreeState
by grarpamp 28 Oct '19

28 Oct '19

https://phys.org/news/2019-10-space-major-legal-void.html https://maxius.nl/verdrag-van-de-verenigde-naties-inzake-het-recht-van-de-z… https://news.ycombinator.com/item?id=21371711

1 0