Fuaarking EU, please gib me end-to-end encrypted chatz pls

https://www.eff.org/deeplinks/2020/10/orders-top-eus-timetable-dismantling-end-end-encryption What do you think about this article?

That the eu is corrupt and oppressive is nothing new. I have little doubt they will do what they can to establish a police state.

When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

I don't actually understand how they intend to implement this kind of thing. In America the most common proposal seems to be to require "platform operators" (i.e. social networks and such) to provide the back door. Platform operators won't do this without regulation because it essentially means they have to expend resources to spy on people for the government without compensation. If their business model does not rely on knowing the contents of private messages, it is more cost effective for them to simply hide those contents from themselves so that they are mathematically incapable of complying (and as it stands most laws basically just require them to give up what they know, so knowing less means less wasted resources responding to subpoenas). I point all that out to emphasize that in America the anti encryption thing is mostly about big tech vs. the government, not individuals vs. the government. None of the proposals I've seen would actually prevent people from using encryption without a back door, they would just prevent e.g. Facebook from implementing it. This is of course not exactly a good thing (although depending on where the chips land it could push people off Facebook, though that admittedly seems unlikely). However, it sounds like the EU wants to do more than that. Or am I just misunderstanding things? How would that even work? The government can't even stop people from torrenting, how could they possibly hope to stop them from using tor or PGP or any of the countless other options that people have for guaranteed end to end secrecy? Perhaps they could go after the foundations that develop open source projects but what's to prevent people from simply forking a version without backdoor?

>>34112 They could simply make a contribution which contains a small bug which can be used to gain access. A lot of people don't sort through thousands of lines of code searching for a clever little bug before downloading a program. For example Slackware had a bug which compromised it and people didn't find out until many years after. Also ISP's could be asked to block or close the connection when someone uses the tor directory node or just encryption noticeably. The best thing to do is get an SDR and using steganography, join a ham net or something with a node connecting to the internet

And so we're back to open-source being the only viable type of software. Is anyone surprised? Also, this thing is fun: https://en.wikipedia.org/wiki/Chaffing_and_winnowing

>>34115 >Also ISP's could be asked to block or close the connection when someone uses the tor directory node or just encryption noticeably I mean, yes, they can know if we're using tor, however, if you don't like to tell your ISP you're using Tor, you have to use a tor bridge How would they know that we're using encryption "noticeably"? We're always using encryption (SSL/TLS) so they only see encrypted packages. They're going to close our connection by just using HTTPS websites? ISPs can see what websites because the DNS packages (always unencrypted) but they cannot see what we're doing on those websites (as long as it has HTTPS). (Way to fix this is using something like dnscrypt-proxy) But I think you mean something like sending PGP emails. Same thing, how can the ISP (not the email provider) know you're sending PGP encrypted emails if you're using TLS? They can see where the package is going, but not the content. Same thing can apply to, say, XMPP, sane XMPP servers have TLS, so you can use OMEMO/PGP/OTR over TLS. And the packages you ISP sees is the TLS encrypted package. not the OMEMO/PGP/OTR encrypted message.

>Fuaarking EU, please gib me end-to-end encrypted chatz pls Sure thing, use XMPP with OMEMO/PGP, or Tox if you trust a guy called "irungentoo" Also, unironically, XMPP without OMEMO and PGP has the same level of security of Signal I think

>>34115 >They could simply make a contribution which contains a small bug which can be used to gain access. This is true, but has nothing to do with legislation. They can do this already. >Also ISP's could be asked to block or close the connection when someone uses the tor directory node or just encryption noticeably This is one possibility, but in America lawmakers largely gave up on this approach because it is largely infeasible. They can't straight up outlaw encryption because everything uses it, so these laws specifically target end to end encrypted services, and it doesn't make them illegal it requires them to have a back door. Even with that smaller scope, they need a way to discern the difference between end to end encrypted traffic from compliant services and from uncompliant services. In the case of tor this would be relatively easy to do, but you can do e2e with regular TLS, for example. So the Americans decided to go after tech companies instead of end users, reasoning that if they can ensure things like WhatsApp and signal don't exist that knocks out the majority of e2ee traffic. The remaining tiny minority are people who will use FOSS solutions, or roll their own crypto if they have to, and find ways to hide it, so they aren't worth the effort in a dragnet surveillance model. The next step is likely to target the walled garden platform providers like google, apple, microsoft. The government can force them to not list noncomplient apps in their stores. They might even be able to force some kind of signing scheme where the OS will refuse to run sideloaded software. However, I don't see how they could enforce it beyond requiring a default setting. Developers fundamentally need to be able to run unsigned code, which opens the door for free software (unless they require "software developer" licenses like lawyers or doctors... could you imagine?). Point being, I don't see any way this law could be implemented that would prevent me from obtaining source code for some e2ee chat software from a trusted source, compiling it on my computer, and using that computer in violation of the spirit of the "e2ee ban" to connect to another person who did the same thing on their computer. Lawmakers can be stupid but their advisors frequently aren't. They know this. I think they're playing a numbers game to ensure that the biggest platforms are backdoored so that the most users are compromised for the least political and monetary expense.

>>34109 hope i'll rot before that happens, qbag guvax v jvyy fnqyl

>>34120 >Also, unironically, XMPP without OMEMO and PGP has the same level of security of Signal I think XMPP without OMEMO or PGP has the same level of security as visiting this website, or something like social media direct messages. If you run it over TLS, as most do, it's secure from spying everywhere but the server and the clients. OMEMO and signal use variations of an encryption scheme called double ratchet, which removes the server from that list. You have to compromise the clients to compromise signal/OTR/OMEMO/PGP. This is what these "anti encryption laws" are trying to circumvent.

>>34125 >or something like social media direct messages. Well, in some cases, I own my xmpp server, so XMPP without OMEMO is way more secure than that. But well, XMPP clients are free software. So I don't think they can backdoor it or something... Right?!

>>34120 I remember seeing an article pointing out how insecure XMPP is due to the metadata sent over to the servers running the XMPP daemons (and possibly even the XMPP clients). I forgot where is the link to the article. It would be appreciated if someone could link this article here.

Talking about xmpp/jabber, profanity jsut started to hang in some call to poll() I dont know why this is happening here, some of know a nice xmpp client for linux? im using mcabber until I found another one or manage to fix the problem in profanity.

>>34136 dino just works, mcabber doesn't support OMEMO (it's a feature according to my friend who thinks OMEMO is backdoored). But since you're using a TUI client, i don't think you want to use Dino. but dino is a great client, and just werks

>>34137 I have no problem with using GUI clients, but I have preference for clients with OTR.

>about adding OTR on dino https://github.com/dino/dino/issues/97 >about adding OMEMO on xabber https://github.com/redsolution/xabber-android/issues/540 Take a look on how develpers care about people using his software.

>>34127 maybe i should have been more specific. i'm talking about the encryption used in these systems, not the circumstances around them. if you run your own xmpp server that is more secure than social media dms, but if your host gets a subpoena for an image of your vps, it is less secure than xmpp+otr/omemo/pgp (or signal). >>34131 probably going to need more to go on than that. xmpp's security model tends to be pretty much the same as email+PGP. metadata is largely only secured by TLS and is often stored unencrypted on the server in some capacity. basically you're using an unencrypted system to send encrypted messages. this can be somewhat mitigated by using xmpp over tor, and keeping minimal information on the server, but some metadata will certainly be available. signal also used to be bad about this, but they are evidently improving (if you believe their PR blog). the other thing worth mentioning is that encryption on file transfers is up to the client, and there are actually two different ways to send files: either upload it to the xmpp server and send a link (this happens behind the scenes) or direct transfer. if you want to be sure your file is encrypted, the latter is usually a safer bet but you'll want to read the docs for your client (or just encrypt the file manually to be safe). >>34137 second dino. although it's worth noting that it doesn't do OTR, only OMEMO and PGP. this wouldn't be a problem in theory because OMEMO is better than OTR in every way I can think of, but lots of clients only support OTR or OTR+PGP so you'll probably want a backup client too. I also like profanity a lot, but for whatever reason their OMEMO plugin doesn't work that well for me.

>>34140 the dino devs' response seems reasonable enough. i think they're underestimating how important OTR is but "we have other priorities but feel free to use the plugin api" isn't a terrible answer. that xabber guy seems like an absolute jackass though. also the fact that he talks about how he wants to prioritize multi-device support but doesn't seem to realize that OTR can't do this makes it seem like he doesn't know what he's talking about.

>>34120 Tox is probably unironically the most secure and hardest to censor chat app. I'd love to see the EU try to backdoor and/or shut down a DHT maintained by a bunch of autists in Canada, Germany and Russia

>>34141 >OMEMO is better than OTR in every way I can think of OMEMO doesn't do authentication and only works on XMPP. Is the encryption strength better? >>34142 >OTR can't do this It can be faked by sending multiple messages.

>>34155 >OMEMO doesn't do authentication and only works on XMPP. What did they mean by that? OMEMO keys have to be verified. Most clients do that automatically (and that is horrible). But there's authentication

>>34158 The authentication is not provided by OMEMO. You have to confirm that Bob is really Bob through a different channel. OMEMO can only "trust" the key.

>>34161 Like OTR? Or OTR took the socialist billionaire problem so seriously?

>>34155 >OMEMO doesn't do authentication What do you mean? You just compare fingerprints. That's the same thing I do in OTR. Can OTR do more than that? >and only works on XMPP. Depends on what you mean. OMEMO is a specific XEP and I don't think it has comperable standardizations for e.g. IRC like OTR does. However, there's nothing particularly preventing this and afaik most people don't re-use keys between XMPP and IRC anyway, although I could be wrong about that. >Is the encryption strength better? Again, depends on what you mean. At its core it's asymmetric elliptic curve cryptography like anything else. The main advantage is the ability to encrypt for multiple devices at once, which obviously is more convenient for individuals and makes group chats easier to implement. You also get forward secrecy and deniability. So I would say yes, it's marginally stronger crypto that also has significantly more useful features. >It can be faked by sending multiple messages Not really. Devices don't share keys so you would have to have a client that encrypts messages to every device it knows about, which would cause every other device to get multiple "got encrypted message to unknown key" type popups, so I'm not aware of any client that does this. Some XMPP systems do in fact do something like this for group chat though, although it wastes bandwidth. PGP multi recipient encryption probably makes more sense than OTR in that application, since you can send the same message to everyone.

>>34172 >which would cause every other device to get multiple "got encrypted message to unknown key" type popups Apologies, I think I got this wrong. I'm pretty sure XMPP lets you send messages to specific devices. This is usually hidden from the UI but it would let the client send multiple messages for each device like you said.

Doesn't this come up every year or so? Honestly forcing facebook to use a backdoor wouldn't bother me really but we do need a legal obligation that guarantees the possibility of secure and private communication for citizens. >>34105 Still freer then the us aw yea

>>34172 >You just compare fingerprints. OTR can use challenge/response or shared secret to verify the identity without knowing the fingerprint. >there's nothing particularly preventing this OMEMO requires an XMPP server. OTR doesn't care about the protocol. >most people don't re-use keys between XMPP and IRC anyway ? >depends on what you mean The cipher suites and other implementation details. >The main advantage is the ability to encrypt for multiple devices at once That's true, but OTR does do forward secrecy and deniability ("off the record").

>>34218 >challenge/response I knew this existed but I wouldn't really call it "in band". You have to establish how you're going to respond to the challenge somehow. >OMEMO requires an XMPP server. OTR doesn't care about the protocol. Technically, yeah but that's how most crypto is. It's all 90% the same soykaf with little implementation differences depending on the platform. If you want OMEMO specifically on another platform you can't have it because it's a specific XMPP standard that makes use of XMPP features (mostly PEP). But if you just want something that does the same thing as OMEMO, well... practically every chat platform, FOSS or otherwise, uses some variation on double ratchet. I think there's a difference in philosophy here. I don't really understand the benefit of using a broader standard for something like this honestly. As long as its using good primitives I'd rather have something more tailored to the software in question (although I do like that things like PGP exist when you really don't have a better option). Maybe you see OTR as a healthy medium between crypto that's super platform specific but feature rich, and crypto like PGP that you can run over fuarrrking anything at the expense of smoother integration. If so, that's fair enough. I could easily be convinced otherwise. >? Like have a common cryptographic identity between IRC/OTR and XMPP/OTR. That's the only reason I could think of to care about whether it's tied to XMPP or not. I've honestly only ever used OTR on XMPP. >OTR does do forward secrecy and deniability Shows what I know, I guess.

I don't understand, how can europe prevent me from using a PGP key? Will they arrest me or something?

>>34131 https://infosec-handbook.eu/blog/xmpp-aitm/ tl;dr: >very detailed metadata >contacts and bookmarks are kept server-side >everything is in plaintext, including passwords >>34228 That's how governments enforce everything, isn't it?

>>34292 This is a pretty good summary of XMPP's issues. I used to be a major fan, due to the easy self-hosting nature. But I really soured on it when I tried to use it as a replacement for email (2FA, password resets, that sort of thing) in a project. I found I just plain couldn't trust it with anything so sensitive. It leaks metadata all over the place and it's too easy for a malicious admin to play games.

>>34293 That's rather unfortunate. What alternatives are there which are viable?

>>34294 I never found an appropriate one. I ended up switching to TOTP for everything.

>>34292 Newer versions of prosody stores salted passwords, so it's not a real issue nowadays

>>34292 This seems like more than a asshole server admin problem rather than XMPP problem, any privacy respecting XMPP server should have disabled logging, and prosody supports hashed passwords now (i dont know about ejabberd). But yeah ALWAYS self-host your server if possible

>>34294 host your own xmpp server

This is a funky one to test: https://status.im/security/ I feel it's more a concept right now rather than a finished implementation but it does work if anyone wants to use it.

>>34323 >Website is cloudflared in the trash it goes

>>34224 >You have to establish how you're going to respond to the challenge somehow. In a manner of speaking. If you previously met in person, you can ask something like "What did we talk about on the way to the conference?" and not have to pre-arrange anything. You don't have to know, at the time you met, that you will want an encrypted chat in the future, and exchange fingerprints. (They would also not need to already have their own key.) It also lets you re-establish your identity if you lose your key. >healthy medium Yes, it can run over anything like PGP, but also has perfect forward secrecy. >super platform specific but feature rich What does OMEMO do besides manage your keys?

>>34323 to be honest i wouldn't use a "private" messanger whose website sets the "__cfuuid" cookie

>>34418 >If you previously met in person, you can ask something like "What did we talk about on the way to the conference?" Forgive my ignorance, but does this do anything to guarantee the integrity of the session key? That's the main point of confirming fingerprints (which you still have to do in OTR, right?). I'm not entirely clear on the distinction between challenge response and just asking the person on the other end that question with a normal message. >What does OMEMO do besides manage your keys? There's a succinct feature comparison at the bottom of this page https://conversations.im/omemo/ . The conversations devs I'm sure can represent this all better than I can. In terms of user experience, the main thing is how it handles multiple devices under the same identity. Other solutions tend to either use a totally separate key for each device (meaning messages sent to one are not readable on another) or they tie the key to your identity and so you have to copy it around (meaning that the fact that you're talking to a new device is obscured from you.. at least within the cryptosystem. XMPP will tell you the device suffix but an attacker can certainly spoof that, particularly if the server is compromised). I guess that's all just "managing keys" but how keys are managed is a big part of what defines a cryptosystem. Also, the fact that it relies on the server (specifically PEP) lets you send encrypted messages to clients which are offline, because it doesn't require a live handshake like OTR. So the lack of portability here is in service of a concrete benefit, if nothing else. I hope it doesn't sound like I'm trying to proselytize. I think OTR is an excellent system and I'm personally quite happy to use it. However I do think OMEMO offers some tangible improvements that more than make up for its dependence on XMPP (which is something I frankly hadn't considered until you brought it up).

>>34104 Anyone who has a good understanding of cryptography that isn't blighted by their ego knows this is a stupid idea. Any organization (read lolberg gubbermint) that allows harmful elements to enter society through lack of border control and then removes the liberties from the populace to compensate said harmful elements - is merely hastening its own demise. This removal of end-to-end encryption makes the individuals, families, and associates of such legislators and those in power much easier to hack, blackmail, corrupt, and thus exploit. A repressed populace will not provide the funding to recruit the best law enforcers and they will forever be behind the private criminal enterprises after giving them the "keys to the kingdom" by removing end-to-end encryption. This is a lose-lose situation for both those implementing it and the innocent populace. It is excellent at fomenting resentment among the populace when they become victims of crime because they have unnecessarily been made an easier target. The only win is for criminal enterprises who would been given the means to transfer their data through that of the populace as better form of end-to-end encryption with added plausible deniability. A few extra bytes added onto Alice's holiday snaps she posted on Facebook via a man-in-the-middle (MITM) attack can be viewed, reassembled, and decrypted by Bob the villain. Villain Bob is overjoyed end-to-end encryption was derezzed because he no longer needs any secure messaging applications that attracted unwanted attention and can simply browse Facebook posts like "a regular Joe".

>>34442 >derezzed I wrote b.a.n.n.e.d w.o.r.d. f.i.l.t.e.r.s c.e.n.s.o.r.i.n.g. t.e.x.t a.r.e. p.u.r.i.l.e.

>>34444 lurk more

>>34442 Where are all these simpletons coming from? I bet it's Endchan.

>>34444 Jesus Christ, lurk more

>>34444 >evading a language enhancer Derezzing time.

>>34475 please read our CoC before posting, comrade.

>>34482 oops wrong post number >>34444

>>34439 >I'm not entirely clear on the distinction between challenge response and just asking the person on the other end that question with a normal message. Socialist millionaire allows you to compare your answers without revealing them. All you can see is whether or not they matched. An eavesdropper can't even see that much. >I hope it doesn't sound like I'm trying to proselytize. No problem.

Did any of you read the article? They propose client-side scanning. This is China-tier.

Currently only nation states have the ability to dismantle end2end encryption on demand. It would good if they removed it so anyone can buy such backdoor tools from the darker (sic) web.

https:// www.hownormalami.eu/

>>34510 Well yeah that's the only way to do it. The government has seemingly learned that the wiretap metaphor doesn't work in the conventional sense.

>>34522 Except that having a politbureau officer looking over your shoulder all the time forever isn't my idea of a good time either. It's also pretty hard to force people to use unmodified apps that won't simply return "ok" for everything.

>>34148 Hasn't Tox's crypto implementation been broken from the start? They still don't have a spec for it after 7 years.

>>34104 The EFF is Big Tech's astroturf arm. https://thebaffler.com/salvos/all-effd-up-levine https://thetrichordist.com/2019/10/24/deja-vu-google-funded-astroturf-groups-use-spambots-robocalls-in-senate-to-block-case-act/ https://yasha.substack.com/p/shahid-buttar-the-cheesy-silicon I consider anything they say to be hot garbage. They always dream up these weird anti-encryption fantasies as if you could regulate P=NP. There's nothing there. It's a boogieman they invented. They typically are trying to shoot down some law that will cost Big Tech money and/or control. These are the same people who pontificated about "the internet sees censorship as damage and routes around it!" Check out their deranged "declaration of cyberspace independence" that completely overlooks obvious facts like, oh, DARPA invented the internet, not you handful of self-important hippies. https://www.eff.org/cyberspace-independence They smeared the man who brought Alaska to statehood and were probably the reason he died in a plane crash. I hate them, with a passion. If someone boards up their doors and burns the place to the ground with everyone inside, they will have done the world at large a great favor.

>>35320 Thanks for the links. Some good info there.

>>34530 Yeah I agree with you. I was just pointing out that lawmakers have largely moved beyond trying to create mathematically impossible encryption "back doors", and are going for the more pragmatic but still largely unenforceable (except in the case of tech giant social media apps) client side back doors.

>>35320 >>35327 A friendly reminder to do your own research as well. I'm grateful for Levine's skepticism but he tends to show only one point of view. It's like reading a book which provides no sources of its information (that is, most books that I have read). People who write articles from only one point of view end up being delusional -- "Oh look, Google paid EFF. I guess no one can trust EFF ever because they are affiliated with Google and therefore their slave," or "EFF is fighting for our freedom and there's no way they could ever make a mistake!" All of this seems wrong and it's a major reason why I don't read many journals -- they're more like personal blog posts rather than objective informational behemoths. Of course, they have to be written by someone and then be approved by someone else, but other than this they aren't very different. To put it simply, you should always do your own research instead of relying on a countless amount of articles which provide you only their own subjective point of view. Levine is no different and the fact that he barely sources any of his information makes this so much worse -- if you do end up looking said information yourself, you are likely already biased for you had read the article before you've done the research, not the other way around. And yet when he does eventually release the best possible source of information, it turns out to be a circus (like when he released Tor-related FOIAs -- they are great and bless him for them, but they only show how biased/paranoid he might be). EFF defending Google is a thing which all vultures shall feed off. Here's one specific section from EFF's Oracle v. Google amicus brief (https://www.supremecourt.gov/DocketPDF/18/18-956/89412/20190225111722754_18-956%20Brief.pdf): >In an abundance of caution and for the sake of transparency, counsel state that Petitioner, Google LLC, has made contributions to the Electronic Frontier Foundation; such funds have been allotted to support specific projects, but not this brief Google itself even keeps the fact that they contribute to EFF public (https://services.google.com/fh/files/misc/trade_association_and_third_party_groups.pdf; apparently Google gave the exact sum during this lawsuit, but I'm not gonna look for it). Another problem is that people (and Levine is no exception) very often tie together those knots which should not be tied together. For example, 1) EFF gets money from Google; 2) EFF defends Google. Now, like a very skeptical person who already doesn't trust EFF, you would really love to connect these facts together and tell everyone that EFF defends Google because it gets money from them, right? But you don't tell them where you got that information from (back when he criticized Tor, he did eventually release all the FOIAs which showed that he left a lot to his fantasy and paranoia). This is a huge fuarrrking mistake. So no wonder that some people would end up thinking that EFF not attacking big corps is equal to EFF defending big corps. It's like EFF's Who Has Your Back -- you could cite this campaign and say something like "EFF is defending the corps, look at how high they rate Facebook and Google," but said campaign is not about defending or attacking those corps nor is it about proving that those corps lie to people or not; "For our 2018 report, we assess companies' policies against five all-new criteria..." -- this does not explicitly imply that those policies are truthful. If you want to read about corps and agencies being fuarrrkwits, you should read leaks instead of what EFF has to write. Assange said it best: "It’s the nature of organizations. They don’t like to bite the hand that feeds them," (https://pando.com/2014/10/12/wikileaks-meets-surveillance-valley-an-interview-with-julian-assange/). Many articles cite Assange and reference Pando, but then how many readers end up going to Pando and read it themselves? And how many actually ask for an accurate transcript of the discussion? Presumably, not many. In my opinion, EFF isn't paid by Google, or any other corporation for that matter, to defend it. Unless someone can provide a strong proof (that is, a leak of sorts) that Google does indeed ask EFF for defense, all of this will seem like request for EFF to not criticize corporations as much as it normally would. And yes, it seems to be working. EFF does often criticize companies but not as much as people would expect it to do so. And I'm sad to say that if any of you believe every single word any article or post has to say (be it a good word or a bad one), you are still a part of the sheep herd you ought to escape. The only difference is that you think you are different, and you can justify it well but not well enough.

>>35342 >It's like reading a book which provides no sources of its information (that is, most books that I have read). uh, i'm looking at my copy of levine's book right now and there are over 180 pages of notes and citations at the end of the book? did you notice all the little numbers scattered throughout the text? each of them are references to previous journalistic reporting or official documents that are cited in the end notes. did you read it or are you just deciding that you already know everything about it from hearsay?

>>35362 I'm not talking about his book but rather about the mentioned article. Haven't read any book from Levine although I would like to one day. What I mean by "Most books that I have read" is that many of the books claim a lot of stuff but don't really prove it (of course, they don't always need to -- statements in Snowden's Permanent Record are mostly proven by his leaks). For example Sandworm, the book that I'm reading right now, sadly does exactly that. >or are you just deciding that you already know everything about it from hearsay I guess it's not clear enough that >>35342 is basically saying "I don't know much, neither do you and someone else's perspective likely isn't enough, no matter how convincing."

>>35408 I'll also add that Levine is a very different person -- his experiences are (perhaps radically) different from mine and where I might see something ordinary, he might see something extraordinary. In other words, any of us can flag benign behavior as malicious and somehow justify it and the other way around. I recommend "Spooky Coincidences?" (from Vinesauce), it explains what I mean in a short and enjoyable way.

>>35409 >(from Vinesauce) Vsauce, not Vinesauce. I'll go shoot myself.

>>35342 >>35408 >>35409 >>35411 retreating to solipsism is not an argument. anyway reading levine isn't supposed to give you the ability to tie knots out of nothing. levine knows the final connections to make that tie conspiracies together don't have publicly available evidence, and only fools arrive at those conclusions definitively. that's the general criticism of conspiracy theorists: there is simply no way to know definitively, and an unreliable imagination has to terminate connections. levine does however provide a reader with documented examples of actual conspiratorial behavior from the past, and says "we know they are willing to do and have done X before, so it's naive to think that a very similar but separate thing Y is disproved when we have observed similar documented outcomes, actors, and circumstances".

>>35458 At this point it's hard for me to see whether we understand each other but fight on different fronts, or if there is some form of misunderstanding still. >retreating to solipsism is not an argument. anyway reading levine isn't supposed to give you the ability to tie knots out of nothing. With my presumption being that the latter is the case, especially in this thread, this discussion seems to bear no real merit. Anyway, you guys enjoy the rest of your day/night. <3

>>34542 Tox crypto has never been "broken" and the spec is right here: https://toktok.ltd/spec.html