Slashdot Mirror
Comcast Admits Delaying, Not Blocking, P2P Traffic
haibijon writes "The executive declined to talk in detail about the technology, citing spammers or other miscreants who might exploit that knowledge. But he insisted the company was not stopping file transfers from happening, only postponing them in certain cases. He compared it to making a phone call and getting a busy signal, then trying again and getting through."
I think a more apt analogy would be something like, "I'm not refusing to pay my bill. Think of it as having the check returned for NSF and then having to resubmit it and it goes through." I'm sure that they wouldn't have a problem with that, considering all the Nigerian scammers out there trying to get your routing information.
Does Comcast advertise very high transfer speeds? Because if they advertise that, knowing that they intentionally force lower speeds for some kinds of traffic, that sounds like fraud.
From what I understand, they are forging packets that make your BT client think that peers have hung up on you. Since they (comcast) are the man-in-the-middle, they can easily perform these types of attacks.
And that's what this is. An attack. QOS would just slow things down, this kills. I don't mind QOS. I do mind active damage.
It's time to take p2p to the next level - implementing some of the concepts of the old freenet (the encryption part) and make the traffic unidentifiable. Maybe move it to UDP and make it look like DNS. Or Skype.
Technically that is certainly true. You could make the legal argument that presenting a certificate as belonging to another organization if fraud.
.torrent file, and include the public key in the .torrent. Then, on-the-fly build a chain of authority stemming from that key. Then, whenever you get directed to a new peer, the message includes a public key for that peer, signed by your current peer, and so forth. Even if comcast tries to join the network to disrupt it, they can't disrupt communication between nodes when the chain-of-authority does not use their keys, and if tampering is detected, their keys can be revoked, un-authenticating any bogus keys they have generated and signed.
Not that it matters for the moment. Comcast can't currently afford to intercept all SSL connections, inspect the certificate to see if they can forge it, and proxy the connection just to do packet inspection.
Furthermore, I think you can prevent that. Essentially, create a new "CA" key whenever you create a
Sounds like a fun project, actually, assuming it doesn't already exist.
It's possible to track FIOS rollouts merely by noting spam sources whose rDNS matches it, e.g., "*.fios.verizon.net". To date, this has been a 100.00% indicator of spam. For example, in the last few minutes, one of my mail servers has observed the following:
pool-70-104-193-136.nrflva.fios.verizon.net
pool-71-170-157-58.dllstx.fios.verizon.net
pool-71-178-175-162.washdc.fios.verizon.net
pool-71-180-67-156.tampfl.fios.verizon.net
pool-71-187-176-23.nwrknj.fios.verizon.net
pool-71-245-227-130.bstnma.fios.verizon.net
pool-71-245-247-31.nycmny.fios.verizon.net
pool-71-245-74-238.prvdri.fios.verizon.net
pool-71-251-69-183.tampfl.fios.verizon.net
pool-72-64-87-227.dllstx.fios.verizon.net
pool-72-66-1-223.washdc.fios.verizon.net
pool-72-75-227-248.bflony.fios.verizon.net
pool-72-90-121-2.ptldor.fios.verizon.net
pool-72-94-19-223.phlapa.fios.verizon.net
pool-72-95-136-185.pitbpa.fios.verizon.net
pool-96-229-80-50.lsanca.fios.verizon.net
That's a mail server with one user. Production mail servers with tens of thousands of users typically note 5000-10000 such systems every day.
So from here, it appears that new FIOS rollouts are being 0wned nearly as quickly as they're connected, and that they're staying 0wned. I'm sure the spammers are quite pleased with the quality service provided by Verizon et.al.