In case it isn't obvious to everyone, the government runs or has tapped most or all TOR exit nodes. This has been going on forever.
Nobody knows exactly what the attack is...but if they're willing to drop cases to cover it up, its probably something that either:
1) completely breaks TOR permanently
2) is easy to bypass/block
Since TOR has withstood a lot of scrutiny I'm betting on option #2. They found a total break but it's really brittle. Either an exploit in software, or more likely, some protocol hiccup that allows them to de-anonymize users running certain popular software or OS.
I was under the impression from reporting on the sting that Playpen was an onion site, not a clearnet site. If that's the case, traffic wouldn't be going through an exit node to get there, right?
Do you have any evidence for the claim that TOR is so badly compromised? My understanding of the article is not that TOR was hacked, but rather that a tor user was tricked into opening a non-tor site and thus giving away his/her IP address.
Also if just the exit node is compromised, encrypted connections are still safe (TTBOMK).
Not the FBI per se, but it shows that someone is clearly attempting to compromise TOR users.
Also there's been whispers about it forever. Much like the "black rooms" at datacentres before all the NSA leaks.
The FBI has a long history of tracking down and compromising CC theft and CP rings, along with silk road and the hoards of clones. Most of these sites are primarily or only accessible over TOR.
Running compromised TOR nodes would be an extremely cheap way to monitor a large portion of illicit Internet traffic. The frequent busts are usually attributed to other reasons to shift attention away from TOR, but this is classic parallel construction.
The feds will nearly always get you on secondary evidence when the primary means is too sensitive... See stingrays. The sheer number of TOR based site busts however is telling.
Anyone relying on TOR for security is a fool. It's more heavily monitored than the regular net.
While a compromised exit node is bad, isn't the situation improved if your TOR session is encrypted? With an encrypted session over tor, and a trusted endpoint, what is your risk profile beyond your exposure to the endpoint?
I believe that Tor Project ought to encourage bulk data transfer through and among onion services. That would add chaff to protect other users. There's resistance because it would increase network load. However, there's considerable excess capacity for middle relays, because they attract so little attention. There's even excess capacity for entry guards, and policy could be changed to increase that. It's exit relays that are rate-limiting, and onion sites don't use them.
Using multiple Tor instances with MPTCP, I've managed 50 Mbps between onion sites with gigabit uplinks.
Here's how it could have worked. User logs into Playpen onion site, which the FBI is running (and still serving child porn, I note). Then malware gets downloaded. Maybe it was a classic dropper, or maybe part of an image file or whatever. OK, so Tor browser doesn't affect Internet connectivity for other apps. So the FBI malware just phones home, pwning the user.
It's kinda sad that TCP was chosen so long ago for HTTP that there's effectively no changing it. With modern TLS the underlying data guarantees TCP gives you just aren't that useful. We have kinda a weird situation where we have TCP->TLS->HTTP in layers when it could all be one protocol layer. We also wrap a stateless protocol (HTTP) inside a stateful (TCP) one which causes some insanity.
What the problem with doing it the current way? Massive routing inefficiency at scale. Since the layers for persistence and routing (L2-4) don't carry all the info needed to connect to a server (some like headers and URL are up in HTTP - L7) it's mandatory to "unwrap" through the protocol layers before you can determine where a stream/packet/HTTP req is supposed to go.
This means you can use something like IPVS as your L2-3 load balancer, but once the streams are divided out by IP/port you need to do the TLS+HTTP in one step. There's also some hard limits on how much traffic a single IVPS instance can handle because balancing TCP even at low level requires the router to keep track of connection state (conntrack). So we have this situation where there's a main low-level balancer with some arbitrary traffic limit imposed from TCP overhead, and behind that we have a bunch of child balancers doing way more work than they should be handling the connection from the TCP level through TLS and HTTP before they can pass on the connection to a back-end app server.
This could all be avoided if HTTP was a stateless UDP based protocol, and TLS was baked in rather than being an additional layer. It would make routing and load balancing far more effective at scale. You probably wouldn't see nearly as many DDoS attacks succeeding, because the vast majority of them exhaust CPU power far before they actually flood you off the net.
It makes sense to separate the problem into multiple different protocols, because that gives you re-usability and greatly reduces the complexity of implementation. Can you imagine the amount of effort if every application protocol defined its own mechanisms for retransmissions, congestion control, security, etc.?
It also makes it possible to swap out parts more easily. For example, to put SSL under HTTP. Or QUIC under HTTP/2 when people realized TCP is not a good fit for it. You could, if you wanted to, run HTTP over UDP. Although you'd quickly realize you actually want many things that TCP and TLS give you for free, so you'd have to start re-implementing the same functionality on top of UDP.
Don't forget the history of TCP. TCP's congestion avoidance is the evolution of 20 years of managing large scale networks. Many papers later and the CA algorithms of TCP have been proven to work at large scale for a variety of traffic types. The internet as we know it simply wouldn't work without massive adoption of TCP. Even QUIC looks very similar to TCP, and is just an evolution of it in many ways.
It's a hard distributed problem: how do you coordinate many independent flows of traffic to efficiently utilise the many network links in the internet? Do this wrong at scale, and even broadband internet will feel like you're on a 2G mobile network.
Also I don't think it makes sense for HTTP to be on UDP. While it's stateless, you still can't tolerate packet loss with HTTP. Otherwise you'll try loading a page and maybe nothing comes back, or only part of it comes back. What then?
TCP makes a lot of sense for HTTP, since once you strip of the HTTP headers on the request and response HTTP is basically just TCP: A continuous bidirectional stream of bytes in both directions. If you want to rebuild that with all it's properties (flow-control, ordered and reliable) you rebuild half of TCP anyway.
The CoAP protocol for embedded devices tries to achieve HTTP semantics on top of UDP. But it's a lot harder to implement correctly, especially if you want to support large request payloads. And I think it isn't easier to load balance or proxy then the TCP based HTTP, since it's also not sufficient to look at a packet header but you would also need to parse and keep around the whole request response states between packets - only now the state is no longer associated to a TCP connection but to a plain UDP socket which must handle dozens of parallel requests.
Perhaps the massive pervasiveness of the internet is not obvious on a day to day basis, but you should consider it when judging whether or not TCP was a good decision.
I think the question is not so much could http have used UDP, but rather is the browser the right place to build a complex piece of software. The fact that you can doesn't mean that you should. I am a bit concerned that the browser is becoming the only cross platform API and we are forced to build complex software on top of a scripting language that was only designed to fire up porn advertisement pop ups.
When one consider what HTML and HTTP was meant for initially, TCP makes perfect sense. That it has since been bastardized into a UI framework is a very different matter.
My god it sounds like the philosophical ideals of somebody plucked straight from the Star Trek universe. Are silicon valley billionaires really this detached from reality?
The reason globalization is coming to a screeching halt is that human cultures vary so much. It's slowly going away, but in general for a belief to truly die off; everyone that believes in it needs to be dead. This gives us around 70 years before the walls really start coming down. That's assuming hate and prejudice are globally snuffed from the ears of the young and impressionable yesterday.
Sounds like he thinks a globally ideal society is possible and not that far away. Sounds like he needs to visit a country locked in civil war for the last 50 years for a week or two.
The "developed" world is quickly approaching utopia, but the other 4 billion people are rapidly being left behind. It's a tragedy that a double digit percentage of the human population is starving to death while I sit here in my heated and air conditioned house with ten foot ceilings, more rooms than people in it, nearly free electricity, running water of any temperature, instant access to any information I want through the internet, and more vehicles than people living here.
He needs to take a look at Bill Gates who's a lot older and wiser than Zuck appears to be. Bill has gained immense respect from me in recent years even though I'm still not a fan of Microsoft. He's doing things that will truly make a difference that nobody else wants to pay for. We make such a hero out of somebody that runs into a burning building to save one person. Bill Gates is bank rolling malaria vaccines that might save 400,000 lives a year. What does that make him? A saint at the least.
Zuck should go back to building his internet satellites, that's a lot better use of his billions than some kind of fairy land curated "safe space" for SJW's to hang out in.
Change occurs in bursts and spurts. Perhaps we are seeing some backlash to the current wave of globalism. But do you really think the fundamental forces that push us towards globalism will stop?
As barriers to communication and travel continue to diminish over time, cultural diffusion will naturally increase, leading toward the major differences being smoothed over. We will become well acquainted.
Eventually, we will reach some point of "globalism saturation". But it seems to me that, currently, there is plenty of opportunity for continued melding of cultures and people groups. This is a natural process that is unfolding, an emergent dynamic resulting from our social nature and changing technological context.
We've barely begun, especially when considering future tech advances that will further reduce many of the artificial, anachronistic barriers between people groups. Most large differences in culture are just accidents of history and distance, not fixed, immovable characteristics.
Of course, we shouldn't blindly proceed. New, important concerns will spring up as the world gets smaller. Surveillance is one obvious example. There will be many more, and we will have to remain vigilant.
>Zuck should go back to building his internet satellites, that's a lot better use of his billions than some kind of fairy land curated "safe space" for SJW's to hang out in.
Not a fan of Facebook in the least, but I find this to be a rather ironic postscript to a (rightly) critical post about Zuck's privilege.
There's one BIG problem with LINQ. I'll agree that the syntax is marvelous, a game changer. The problem is performance.
It's gotten slightly better over the years but compared to an ORM with less abstraction like Hibernate it's still dog slow. Every MS project I've worked on was mostly LINQ...then a folder called "dirty SQL" for the heavy stuff.
I'm not sure if it's due to the highly abstracted nature or just not making performance a priority but in my experience sane Hibernate queries are about 1/2 the speed of native SQL and LINQ is closer to 1/50.
I hope and pray they can make the performance at least within an order of magnitude of raw SQL or even Hibernate so I can say goodbye to SQL forever.
At a previous job I worked hard to prove that I could make LINQ queries perform within small tolerance of the window of hand-written SQL alternatives.
Performance tuning LINQ is a science that I think escapes far too many people. Often it seemed to simply be mistakes that they wouldn't make in hand-written SQL, but they were writing LINQ too much like C# instead of enough like SQL.
> You can always use DataContext.Database.SQL(query) ofc
that's pretty much our MO :) . Never used Dapper, how reliable is it? I ask because we use StackExchanges' Redis client for C# and it mysteriously crashes even after untold hours of debugging
I'm going to be the dissenting voice here and say: Use whatever name you like as long as it isn't something like cuntbagDB.
CockroachDB accurately and immediately conveys meaning. It'll survive when nuclear war happens just like a cockroach. And I might work in the games industry but I would never have a hard time selling this. I would basically force them to use it and explain the benefits.
If your company wont adopt technology because it uses a bug as it's name then your company has much greater problems than technology adoption.
It's not my company or me, it's my clients. Here's a sort of long winded story explaining what I mean that the corporate world can't use anything with the name "cockroach". If you disagree after reading, I'm open for a friendly debate.
Average project, some 60 year old VP signing off on 100k of custom software with 8 pages of lawyer speak contracts is NOT going to allow "his" project to run off of "cockroach database". VP's/CEO's like to take personal ownership of projects they feel will go well, and ones done with us usually do. None of these people want ANY chance of their project getting criticized internally, so nobody will use CockroachDb. It's just not going to happen. Having successful projects is an easy way for these people to gather promotions and respect. Having any part of it do with "cockroach" could result in the whole project being an embarrassment.
Imagine the database goes down one day. One of their low level staff calls us(we have ongoing support contract). Problem gets rapidly escalated to development. One of our lead developers replies to the email thread, that by now has a third of the clients' company on it. "Yeah see the problem was the cockroach database that wasn't supposed to go down needed to be restarted" . Most of the staff think we're joking. Guarantee this becomes a big pun around their office, every time anything breaks in the app they say "maybe the cockroaches on the back end died again".
It's made worse by the fact that issues in software systems are commonly called "bugs". Well, our system doesn't have general bugs anymore, it has "cockroaches". Do you think this is an unlikely scenario? Because it's not. Besides the word "cockroach" this is exactly how urgent issues tend to be reported and fixed. Replace "cockroach" with "Microsoft" and I've probably violated my NDA. After that incident, whoever championed the project, probably our strongest ally in the company, resents us for making such a stupid mistake that resulted in his project becoming a joke. Maybe we aren't as great of a dev shop as he once thought? Maybe it's better to do open bidding next time so whoever wins he can't be blamed directly for what happens.
You could say their company culture sucks, maybe it does? But that doesn't change that I can't use it on any client projects because of the chance we'll lose hundreds of thousands over a stupid name.
There's plenty of other names that convey meaning but don't make lawyers nervous. Your attitude of "oh, well if you can't use it your company culture sucks" is EXACTLY why nobody will rename it and why corporate american won't touch it. Nobody cares about how cool it is to be edgy when millions of dollars are on the line.
If you plan on forcing clients to use it you might as well hold a going away party for any of your clients with more than 5M revenue.
If your VP isn't trusting his technical directors to make appropriate choices when producing quality reliable software and infrastructure then I would say that is a problem with company culture.
I wouldn't have a problem selling the technical merits of a highly consistent database to a technical director. So everything else is moot to me.
I agree about the "bug" association, that is a negative stigma that I could see attached to it- but there are plenty of projects who have stupid names which pass by unnoticed.
take distro release names; Beefy Miracle.. Wheezy.. Natty Narwahl.
And these terms are used internally too. "Oh, that machine was running Squeeze and not Jessie which is why we can't install the latest gdb" etc;
You're giving this much more credence than it will have in real life.
I had the same issue with another tool I used called "agent ransack". The solution is simple, offer the same product with a different name to corporate clients. They have a different download called "file locator pro" that's literally exactly the same, without the bad name.
their name is the stupidest startup blunder I've ever seen. Enterprise won't go near it, seriously. I cannot tell a client I'm using a "cockroach" database, no fucking way.
If we could go back and rename Windows Hitler would anyone be using it???
Cloning a reply I made earlier talking about that exact situation:
It's not my company or me, it's my clients. Here's a sort of long winded story explaining what I mean that the corporate world can't use anything with the name "cockroach". If you disagree after reading, I'm open for a friendly debate.
Average project, some 60 year old VP signing off on 100k of custom software with 8 pages of lawyer speak contracts is NOT going to allow "his" project to run off of "cockroach database". VP's/CEO's like to take personal ownership of projects they feel will go well, and ones done with us usually do. None of these people want ANY chance of their project getting criticized internally, so nobody will use CockroachDb. It's just not going to happen. Having successful projects is an easy way for these people to gather promotions and respect. Having any part of it do with "cockroach" could result in the whole project being an embarrassment.
Imagine the database goes down one day. One of their low level staff calls us(we have ongoing support contract). Problem gets rapidly escalated to development. One of our lead developers replies to the email thread, that by now has a third of the clients' company on it. "Yeah see the problem was the cockroach database that wasn't supposed to go down needed to be restarted" . Most of the staff think we're joking. Guarantee this becomes a big pun around their office, every time anything breaks in the app they say "maybe the cockroaches on the back end died again".
It's made worse by the fact that issues in software systems are commonly called "bugs". Well, our system doesn't have general bugs anymore, it has "cockroaches". Do you think this is an unlikely scenario? Because it's not. Besides the word "cockroach" this is exactly how urgent issues tend to be reported and fixed. Replace "cockroach" with "Microsoft" and I've probably violated my NDA. After that incident, whoever championed the project, probably our strongest ally in the company, resents us for making such a stupid mistake that resulted in his project becoming a joke. Maybe we aren't as great of a dev shop as he once thought? Maybe it's better to do open bidding next time so whoever wins he can't be blamed directly for what happens.
You could say their company culture sucks, maybe it does? But that doesn't change that I can't use it on any client projects because of the chance we'll lose hundreds of thousands over a stupid name.
There's plenty of other names that convey meaning but don't make lawyers nervous. Your attitude of "oh, well if you can't use it your company culture sucks" is EXACTLY why nobody will rename it and why corporate american won't touch it. Nobody cares about how cool it is to be edgy when millions of dollars are on the line.
If you plan on forcing clients to use it you might as well hold a going away party for any of your clients with more than 5M revenue.
>If we could go back and rename Windows Hitler would anyone be using it???
Intensely hyperbolic but... you're not wrong. "Cockroach" is an awful name for a database and I have a hard time envisioning "seen-it-all" enterprise IT managers taking it seriously.
This is my issue - I don't know. I assume any time is worth wasting if your developer builds even a small business since the value of anything over 5 employees is likely more than a million. Time management is not my concern at all. If I could legally start a business I would begin working on it tomorrow
My current strategy is to open source everything because there's no reasonable way my company can take ownership of something that's free. I can't develop anything for money even though I've been asked to consult many times for many people.
My employment agreement at last three companies says they own any intellectual property I create on or off business hours with or without using company equipment. Whether or not its related to the current business.
I personally hate node with all of my being, but Go is good stuff and Java has two very solid REST frameworks Jersey and Spring Boot. Depending on the project needs you could use DropWizard or Play which come with a really solid REST API framework builtin.
I was always partial to Pythons Flask as well
What did we run into? Tons of brokenness. Inability to use C# libs was the biggest problem, if you're trying to make anything significant you're going to have to roll your own everything. Java is the safest bet for large projects, I've never run into any issues finding a quality library to do anything. This is coming from a guy that's been a career C# dev for years and wishes he could defect to Java.
I have no clue if anyone really uses it, and it has a terribly un-googleable name, but the Java Spark Framework is the most beautifully simplistic REST API I have ever played with. It's the only time Java has ever felt like Node to me.
Nobody knows exactly what the attack is...but if they're willing to drop cases to cover it up, its probably something that either: 1) completely breaks TOR permanently 2) is easy to bypass/block
Since TOR has withstood a lot of scrutiny I'm betting on option #2. They found a total break but it's really brittle. Either an exploit in software, or more likely, some protocol hiccup that allows them to de-anonymize users running certain popular software or OS.