Forgot your password?

Comment: Re:Oh really ? (Score 2) 82

by Qzukk (#47569565) Attached to: Black Hat Researchers Actively Trying To Deanonymize Tor Users

Since you're not sharing, I'm guessing you're imagining some sort of multiplexing scheme where the node would take say 100 bytes from 14 different sources and combine them into one packet and send that. It's an intriguing idea that would slow down metadata analysis but it would have a lot of overhead to keep track of, but that "keeping track of" becomes an attack vector again especially with subverted nodes, since node B will need to know that the next 8 packets from node A will have 100 bytes of data that need to be kept together and sent on to node C.

If the network is busy it should actually not be bad for interactive small-packet connections. If the network is idle there could be a timer before the node fills unfilled slots with random data and sends it.

Comment: Re:Oh really ? (Score 3, Insightful) 82

by Qzukk (#47567501) Attached to: Black Hat Researchers Actively Trying To Deanonymize Tor Users

And sure as hell it is impossible to develop a mixnet that will generate Camouflage traffic

It would have to generate traffic in equal amounts for every flow, which would halve network speed to give an attacker a 50/50 chance of guessing the correct flow. Those fake flows would also have to be carried to something that looks like a reasonable endpoint as well.

PRISM-level metadata collection makes it trivial to see which computer sent the original 682-byte request (recurse as necessary until the 800 byte request starts at the "sender") as well as which computer the multi-megabyte response was sent to (recurse as necessary until the multi megabyte response returns to the requesting computer). Camouflage traffic can't fix this on its own, it's easy to exclude the data that wasn't requested from the analysis.

I think that Tor's best bet while maintaining performance at this point would be to round all packets up to the nearest MTU (lets say 1400 to account for PPPoE, VPNs, and other layers on ethernet), so every request and response becomes a multiple of 1400 bytes, would make most tracking rely on packet timing. The next step would be to introduce packet delays at each hop, but that will slow the already slow network down.

Comment: Re:Lies and statistics... (Score 1) 561

by hsmith (#47562109) Attached to: 35% of American Adults Have Debt 'In Collections'
Golds is a cancer. I was a member there for awhile. For whatever reason, they stopped charging my credit card. I was looking over my bills and noticed they hadn't billed me for 3 months. Contacted the gym and fixed the CC. A week later, a call from collections for non-payment. No one ever contacted me. The CC was fine, hadn't expired. Because of an internal problem, they sent me to collections. Insanity.

Comment: Re:No actual numbers (Score 1) 137

by Qzukk (#47524889) Attached to: Internet Explorer Vulnerabilities Increase 100%

The article, headline, story and comments are all bullshit.

Assuming the graph is not also bullshit, the correct story is that in the first 6 months of 2014 (1H 2014 on the graph), IE has had more vulnerabilities than all of 2013. IF this keeps up, then by the end of 2014, IE will have had more than a 100% increase in the number of vulnerabilities over last year.

User Journal

Journal: Holy shitballs, slashdot. Malicious ads being served up.

Journal by Qzukk

Love is over.

I was redirected to which dropped a java_installer.exe into my Downloads folder from some ad playing on around 2:30PM central time 7/24

Comment: Re:umm duh? (Score 3, Informative) 176

by hsmith (#47521821) Attached to: Dropbox Head Responds To Snowden Claims About Privacy
You do realize there are several flavors of encryption, right? Microsoft SQL Server TDE is an example. You can login, perform queries, update data in any table, but all data is encrypted - it is - transparent as the name indicates.

That also ignores things like encrypted volumes, etc. Just because individual files aren't encrypted with unique keys, doesn't mean that encryption isn't there.

Comment: Re:"Just let me build a bridge!" (Score 4, Insightful) 368

by Qzukk (#47518245) Attached to: 'Just Let Me Code!'

When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.

You also don't have the president of the company come in and declare that this week we're switching to agile bridge building and fuck six, we're going to seven sigmas so we can be on the bleeding edge and shift our paradigms into high gear to synchronize our release schedule and get out ahead of the pack as we swing around the final stretch into the processification.

Comment: Re:This would actually be useful the other way aro (Score 1) 205

by Qzukk (#47501215) Attached to: New Toyota Helps You Yell At the Kids

But just no, to the conversation mirror - most parents already don't keep their eyes on the road, we don't need to give them another excuse.

Ah, memories of my childhood. Things like my father flying down the freeway at 60 turning around in his seat and screaming "You look at me when I'm talking to you boy!" while everyone else screamed about oncoming traffic.

At the time I learned to drive, I considered my greatest achievement was being able to hold a conversation without looking at the person I'm speaking with.

Comment: Re:barf (Score 1) 154

That's also seen in bad console ports, by the way.

I've long since overcome my motion sickness (mom's van came with multiple barf buckets), but watching the screen move like I flicked google maps and it slowly pans to a stop (especially in any kind of curved motion) tickles the part of my brain that says "stop that, it's trying to make you sick".

Comment: Re:This is not how you inspire confidence (Score 1) 151

by Qzukk (#47476921) Attached to: LibreSSL PRNG Vulnerability Patched

Only if the master process quit after forking twice. This is not typical

No, this IS typical. The double fork allows the original process to interact with the user ("Enter your private key password:"), then exit and return 0 to the init script so init can print [ OK ] on your console.

The middle process needs to close file descriptors and do other cleanup then fork and die, causing the final process to become re-parented to init. Init then becomes responsible for cleaning it up if it dies, so it won't become a zombie.

Step-by-step "how to daemon" guide here.

Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing?