The body of Kenneth Trentadue lay in a coffin in an Orange County, Calif., funeral home. His family had been told by the U.S. Bureau of Prisons earlier that week that the man hanged himself with a bed sheet on Aug. 21, 1995, while in federal custody at the Federal Transfer Center (FTC) in Oklahoma City. But Trentadue's family members who viewed his corpse-his wife, mother and sister-doubted the story....
the prison had gone to the trouble of putting Kenneth in a suit and applying makeup to his face-departing from the no-frills way the BOP typically releases dead inmates to their families-but had not bothered to mask his slashed throat.
Then the women noticed Kenneth's wrists and knuckles were black and swollen, strange injuries for a hanging.
Trentadue's sister, Donna Sweeney, clutched a camera she had brought with her. Taking a deep breath, she directed an attendant to strip Kenneth's body and scrub the heavy makeup from his face.
What the women saw shocked and disgusted them. Kenneth's head bore three massive wounds, two of which had ruptured the flesh to expose the skull. Below his left arm were fingerprint marks suggesting he had been propped up and held by someone else. Patches of skin had been ripped from his back. Bruises and welts lined the entire body, from his eyelids to the soles of his feet. [cont.]
I wouldn't be surprised if Homeland Security Operations Morning Briefs that we leaked are also part of their inclination to avoid digital record keeping (and comprehensive FOIA searches)
These reports show an interesting view of the domestic intelligence gathering being done at the DHS.
It doesn't really matter. You should consider wild exploit code available the moment a vulnerability is discovered. While this is less common than some kind of grace period (days, week?) you should act according to the risk of immediate vulnerability.
vascular scan biometrics are the only adequate security solution to date (with the possible exception of facial geometry). even iris scanners are susceptible to spoofing.
vascual ! always = retinal scan; many foreign banks are using hand vascular scans for banking transactions. facial vascular scans can also be less intrusive than retinal scans.
Let's take a step back and consider some fundamentals:
- Filesystems are a way to represent resources in an organized namespace. - Disk capacity is increasing faster than our ability to utilize it effectively. - Networks are everywhere, from Internet to WiFi to Lan Party. - How you use data is more relevant than where you use it. - Social networks provide context and reputation to resources and conversations.
Lets mix them all together and see what comes out:
- A filesystem that is not "fixed" to a disk, but is a "view" associated with you (securely) that travels wherever you go, using networks and aggressive caching on plentiful disk space to make access fast.
- A filesystem that is a shared collaborative space organized by the way you use resources within it, and the way your peers in your social network use their resources as well. New resources can be quickly brought to your attention as something "interesting". Common resources are more aggressively cached, making them fast to access and distribute, more reliable.
- A filesystem that has rich semantics and robust metadata data associated with the resources contained within. This metadata is built via implicit feedback based on the way you and your peers use its contents as well as explicit feedback / assignment you manually perform.
Microsoft and everyone else is focused on the flexible view of resources but only on local data contained on disks you have in front of you.
Where OSS can beat everyone to the punch is the decentralized, networked view which makes file resources as mobile as the peers who use them. This scares content owners, and breaks DRM models. This is an area where OSS has an advantage, and can be on the leading edge of innovation instead of the trailing copycat angle (WinFS/Spotlight, etc)
The only way to do this is to weigh the possible harm that could come from illegitimate use vs. the benefit of legitimate use.
and also if there is practical enforcement. there is no practical enforcement to prevent mix networks and onion networks unless we go to a fully monitored and actively filtered internet. not going to happen (this would be a different argument).
the benefits of anonymous communications for preserving liberties, privacy, and the public good are well established. publius!:)
I am a big fan of implicit filesystem feedback. This can support all kinds of services from file sharing to most recently accessed search requests. Even fine tuning access controls in an RSBAC security policy.
The big concern is keeping this data protected and private. You dont want to share all of your metadata with everyone, so security of these systems should be something to look at carefully.
As hinted at in this interview, the future of wireless networking revolves around many variations on a few core themes: diversity, versatility, and scalability.
Diversity is accomplished through MIMO and other technologies like beam steering to provide a robust communication channel between wireless devices.
Versatility comes with open source firmware / drivers and software defined radios. There is no way manufacturers can foretell all of the desirable uses and functionality consumers want in their products. The most useful systems will be those that are versatile and can adapt to new protocols, encodings, etc.
Scalability can be achieved through robust ad-hoc routing protocols and decentralized security methods to produce a system that scales easily as participating nodes join and part the network without complicated provisioning or a reliance on centralized and limited backhaul or access point functionality.
There is still a lot of interesting work to be done in these areas, but the real fun starts in the applications that will utilize these new ad-hoc networking infrastructures.
Re:If you would like to be invited
on
Gmail in the News
·
· Score: 1
I've sent 10 invites, and the queue is at ~65 people. If you don't mind waiting a week or two you can continue to send email, otherwise your best bet might be to try some of the other methods mentioned above.
If you have some invites and would like to help me pare down the queue, that would be cool too, just let me know.
Thanks.
If you would like to be invited
on
Gmail in the News
·
· Score: 4, Informative
Please send me an email to coderman at peertech.org with your first and last name, and email address (this is for the form).
I will reply with your current position in the queue of people wanting an invite, and when I get more invitations (currently 5 every one to three days) I'll send you one.
All I ask is this: 1. Please tell me if you get invited before your turn in queue, otherwise I will waste an invitation. 2. Please don't sell this invite, or sell the invites you subsequently get from your own account.
People who sell or extort for invites lack integrity and are selfish. Don't be that kind of person.
Transmissible gene therapy has some awesome potential, and the fact that such limited resources could pull it off is all the more inredible.
The flip side of this is of course the potential for insanely destructive devices in the hands of anyone with a decent budget and some technical bioengineering skill.
Technological advances are going to drive the price point for this technology down ever further. In 10 years, should we be concerned if $5,000 in supplies and computing equipment allows this same feat to be accomplished?
It's going to start getting very interesting as the decades roll by. The ever increasing and incredible capabilities that these technologies provide are a double edged sword. They will be used for great good, but you can be sure more malicious uses will also be employed...
IP bans are easily circumvented, and a ban is individual per user. every user would need to get burned, then ban the IP, etc, etc. Very inefficient and a hassle.
File size checks and hashing means you download all or a good portion of the file only to find out it is crap. Still inefficient and a hassle. (And even worse, some clients leave partially completed downloads available for re-sharing)
The "check for files with lots of sources AND different IPS with a file that ISN'T rated 0 with a FAKE comment attached to it" method is a step improved, nearing a metric style evaluation of offered resources.
This is still a very manual and tedious process in most clients, so automating this kind of robust checking is a must.
And even better you can move towards a system that implements actual reputation and trust in a decentralized manner so that these unknown spammers will never make it into your peer group in the first place.
There are indeed many ways to block fake files; right now most of them suck.
[P.S. The RIAA does use valid lead-in's in fake's, and other techniques, like rapidly decreased quality, etc, so that listening to the beginning of a song or playing the first few minutes of a movie are not guarantee's of validity]
I've always preferred social discovery in peer networks because it avoids the weaknesses that automated systems and spammers in general can exploit to subvert search results.
Social discovery, reputation and trust metrics, and feedback to close the loop will all become bigger and bigger concerns in partially or fully decentralized peer networks as a natural consequence of attacks and exploits like these.
The incentives for groups and individuals (even government) to try and subvert these systems is growing by the day. These networks will either adapt and improve their resilience against these activies, or their users will depart to other networks that do.
Yeah, i shot off the hip in reply to posts about ephemeral ports and obfuscating IP's. The exploit mentioned is not about to choosing good sequence numbers (although that is orthogonal to stopping spoofed insertion/DoS attacks).
So regarding this specific attack, here is a quote from the paper about TCP sequence numbers:
a good TCP sequence number generator implementation currently provides enough security to protect against spoofing attacks, at least for the present time and in typical conditions. But increasing bandwidth and processor speed will eventually make brute force guessing of 32-bit ISNs feasible for the average attacker.
If you are using large windows in long lived TCP connections (BGP?) you have made a brute force denial of service (not insertion) a good bit easier for the attacker. Exactly how much easier depends on how large the window is set and how fat the network pipe is to the target system.
In the case of BGP, these servers are often configured with large windows, and have significant bandwidth: ripe for DoS'ing.
If only ISP's were required to do egress filtering...
Guessing a port and IP is fairly easy. Guessing the sequence number is not. This is why making sure that TCP initial sequence numbers are random is important.
Multisecond RTT doesn't happen on anything but GPRS
I've seen it far too often on congested wifi networks. you easily get into a congested state with a crowded AP that forces lots of client waits for the DCF (i.e DIFS + padding, each in turn) and also induces lots of retransmission at the physical level due to collision with so many clients trying to talk to the same AP. Low power clients associated at the 1 or 2 Mbps rates drive this contention over the DCF even higher, severely punishing everyone associated.
The big conference venues are notoriously bad about this, as you often end up with 10-20+ people associated with a single access point. That is just too many, and the 802.11 MAC was never meant to handle that kind of load efficiently. It is a pretty good solution for the general case that simply can't cover all the edge cases (long shots, high client loads, noisy RF environments).
This type of situation results in really weird ping times, for example. I've seen fluctuations myself that go from 80ms, 120ms to 3s!, 2s!, etc. then back down to a few score milliseconds. That is the 802.11 MAC trying to cope with scenario's it was never designed to encounter.
I mentioned software radios in the first post because having access to timing and congestion control in the MAC would allow mesh boxes, clients, and AP's to make very significant performance enhancements for situations where they were needed. Why be forced to use a static, inflexible, proprietary hardware layer when you can have the open flexibility associated with software radio? (It's coming, just not soon enough:-) There are also extensions to the ad-hoc routing protocols (like passive monitor of route info between other clients in DSR) that could be supported if only the hardware was open enough to do so.
I don't want to bitch too much; we have come a long way from sub-megabit data via FHSS over 900Mhz. I just want the really good stuff to hurry up and get here already so that things like mesh networks, low latency/loss voice over IP, and highly available multipath/redundant network configurations can be enjoyed to their full potential. (software radio + multiple input / multiple output + intelligent network stacks that can handle a diverse and volatile network environment).... and a pony!
Good points. What I meant by latency is that losses in the physical layer result in large latencies at the transport layer (i.e. the 802.11 MAC).
And RTP wont fragment as you mention because of MTU (unless you were doing something really odd with fragmentation at the 802.11 MAC?). I was thinking along the lines of long setup delays for the sessions due to SIP over TCP with larger payloads.
I was a bit harsh on mesh networks. The combination of AODV, DSR, and DSDV is a huge shift in the style of ad-hoc organization and cooperation that makes for a truly useful and individual/community centered approach to communication. It is going to be fun.
I just tend to get a bit annoyed with the grand visions of a nationwide mesh utopia springing up from the bowls of democracy and freedom to release us from the tyranny of Big Co Telecom and whoever else... *grin*
Hmmm, I'm going to avoid discussing security implications of the various protocols for now (that's a whole other can of worms I'm sure you are well familiar with)
Trust and security in decentralized networks makes the security problems of the enterprise look appealing in comparison:-)
Slashdot Mirror
I meant to say "that were leaked". I had nothing to do with those documents appearing in google. No spooks please.
The mysterious death of Kenneth Trentadue
...
... what happened to the America I used to know?
The body of Kenneth Trentadue lay in a coffin in an Orange County, Calif., funeral home. His family had been told by the U.S. Bureau of Prisons earlier that week that the man hanged himself with a bed sheet on Aug. 21, 1995, while in federal custody at the Federal Transfer Center (FTC) in Oklahoma City. But Trentadue's family members who viewed his corpse-his wife, mother and sister-doubted the story.
the prison had gone to the trouble of putting Kenneth in a suit and applying makeup to his face-departing from the no-frills way the BOP typically releases dead inmates to their families-but had not bothered to mask his slashed throat.
Then the women noticed Kenneth's wrists and knuckles were black and swollen, strange injuries for a hanging.
Trentadue's sister, Donna Sweeney, clutched a camera she had brought with her. Taking a deep breath, she directed an attendant to strip Kenneth's body and scrub the heavy makeup from his face.
What the women saw shocked and disgusted them. Kenneth's head bore three massive wounds, two of which had ruptured the flesh to expose the skull. Below his left arm were fingerprint marks suggesting he had been propped up and held by someone else. Patches of skin had been ripped from his back. Bruises and welts lined the entire body, from his eyelids to the soles of his feet. [cont.]
I wouldn't be surprised if Homeland Security Operations Morning Briefs that we leaked are also part of their inclination to avoid digital record keeping (and comprehensive FOIA searches)
These reports show an interesting view of the domestic intelligence gathering being done at the DHS.
It doesn't really matter. You should consider wild exploit code available the moment a vulnerability is discovered. While this is less common than some kind of grace period (days, week?) you should act according to the risk of immediate vulnerability.
Other weaknesses were reported in various other secure digests, including MD4, RIPEMD, HAVAL-128, SHA-0.
SHA-256 is a good replacement. SHA-1 should be fine but if you are going through the trouble of an upgrade, why not make it sufficiently future proof?
fingerprint biometrics are notoriously spoofable. only 1 in 1000 even mention "liveness detection" with an adequate threat model.
vascular scan biometrics are the only adequate security solution to date (with the possible exception of facial geometry). even iris scanners are susceptible to spoofing.
vascual ! always = retinal scan; many foreign banks are using hand vascular scans for banking transactions. facial vascular scans can also be less intrusive than retinal scans.
Let's take a step back and consider some fundamentals:
- Filesystems are a way to represent resources in an organized namespace.
- Disk capacity is increasing faster than our ability to utilize it effectively.
- Networks are everywhere, from Internet to WiFi to Lan Party.
- How you use data is more relevant than where you use it.
- Social networks provide context and reputation to resources and conversations.
Lets mix them all together and see what comes out:
- A filesystem that is not "fixed" to a disk, but is a "view" associated with you (securely) that travels wherever you go, using networks and aggressive caching on plentiful disk space to make access fast.
- A filesystem that is a shared collaborative space organized by the way you use resources within it, and the way your peers in your social network use their resources as well. New resources can be quickly brought to your attention as something "interesting". Common resources are more aggressively cached, making them fast to access and distribute, more reliable.
- A filesystem that has rich semantics and robust metadata data associated with the resources contained within. This metadata is built via implicit feedback based on the way you and your peers use its contents as well as explicit feedback / assignment you manually perform.
Microsoft and everyone else is focused on the flexible view of resources but only on local data contained on disks you have in front of you.
Where OSS can beat everyone to the punch is the decentralized, networked view which makes file resources as mobile as the peers who use them. This scares content owners, and breaks DRM models. This is an area where OSS has an advantage, and can be on the leading edge of innovation instead of the trailing copycat angle (WinFS/Spotlight, etc)
The only way to do this is to weigh the possible harm that could come from illegitimate use vs. the benefit of legitimate use.
:)
and also if there is practical enforcement. there is no practical enforcement to prevent mix networks and onion networks unless we go to a fully monitored and actively filtered internet. not going to happen (this would be a different argument).
the benefits of anonymous communications for preserving liberties, privacy, and the public good are well established. publius!
LIBERTY IS OVERRATED.
please to trade my freedom for the appearance of security...
I am a big fan of implicit filesystem feedback. This can support all kinds of services from file sharing to most recently accessed search requests. Even fine tuning access controls in an RSBAC security policy.
The big concern is keeping this data protected and private. You dont want to share all of your metadata with everyone, so security of these systems should be something to look at carefully.
As hinted at in this interview, the future of wireless networking revolves around many variations on a few core themes: diversity, versatility, and scalability.
Diversity is accomplished through MIMO and other technologies like beam steering to provide a robust communication channel between wireless devices.
Versatility comes with open source firmware / drivers and software defined radios. There is no way manufacturers can foretell all of the desirable uses and functionality consumers want in their products. The most useful systems will be those that are versatile and can adapt to new protocols, encodings, etc.
Scalability can be achieved through robust ad-hoc routing protocols and decentralized security methods to produce a system that scales easily as participating nodes join and part the network without complicated provisioning or a reliance on centralized and limited backhaul or access point functionality.
There is still a lot of interesting work to be done in these areas, but the real fun starts in the applications that will utilize these new ad-hoc networking infrastructures.
I've sent 10 invites, and the queue is at ~65 people. If you don't mind waiting a week or two you can continue to send email, otherwise your best bet might be to try some of the other methods mentioned above.
If you have some invites and would like to help me pare down the queue, that would be cool too, just let me know.
Thanks.
Please send me an email to coderman at peertech.org with your first and last name, and email address (this is for the form).
I will reply with your current position in the queue of people wanting an invite, and when I get more invitations (currently 5 every one to three days) I'll send you one.
All I ask is this:
1. Please tell me if you get invited before your turn in queue, otherwise I will waste an invitation.
2. Please don't sell this invite, or sell the invites you subsequently get from your own account.
People who sell or extort for invites lack integrity and are selfish. Don't be that kind of person.
End of story. Sometimes you can actually make a bit of money doing. Sometimes you can make some damn good money doing it.
But in the end, open source == philanthropy and it's just a question of who is donating what. (time, money, advocacy, etc)
you still have HIV which means you can still infect someone.
yes, but they mentioned that the anti-virus-virus also remains, so you would infect them not only with HIV, but anti-HIV as well.
a nice trick...
but it might be a cure for AIDS, which is caused by sufficient amounts of HIV causing immune system malfunction.
Anyone remember the super lethal smallpox virus?
Transmissible gene therapy has some awesome potential, and the fact that such limited resources could pull it off is all the more inredible.
The flip side of this is of course the potential for insanely destructive devices in the hands of anyone with a decent budget and some technical bioengineering skill.
Technological advances are going to drive the price point for this technology down ever further. In 10 years, should we be concerned if $5,000 in supplies and computing equipment allows this same feat to be accomplished?
It's going to start getting very interesting as the decades roll by. The ever increasing and incredible capabilities that these technologies provide are a double edged sword. They will be used for great good, but you can be sure more malicious uses will also be employed...
sweet. you want to write the RFC? :-)
You are missing the point.
The problem is not identifying content, it's determing who's opinion to trust when they say "this file is good" or "this file is bogus".
If you go by votes alone, the RIAA will have lots of drones ranking down the legitimate content, and ranking up their crap.
Figuring out an effective way to determine quality, regardless of how you identify the files is the difficult aspect of these systems.
There are also much more effective ways.
IP bans are easily circumvented, and a ban is individual per user. every user would need to get burned, then ban the IP, etc, etc. Very inefficient and a hassle.
File size checks and hashing means you download all or a good portion of the file only to find out it is crap. Still inefficient and a hassle. (And even worse, some clients leave partially completed downloads available for re-sharing)
The "check for files with lots of sources AND different IPS with a file that ISN'T rated 0 with a FAKE comment attached to it" method is a step improved, nearing a metric style evaluation of offered resources.
This is still a very manual and tedious process in most clients, so automating this kind of robust checking is a must.
And even better you can move towards a system that implements actual reputation and trust in a decentralized manner so that these unknown spammers will never make it into your peer group in the first place.
There are indeed many ways to block fake files; right now most of them suck.
[P.S. The RIAA does use valid lead-in's in fake's, and other techniques, like rapidly decreased quality, etc, so that listening to the beginning of a song or playing the first few minutes of a movie are not guarantee's of validity]
I've always preferred social discovery in peer networks because it avoids the weaknesses that automated systems and spammers in general can exploit to subvert search results.
Social discovery, reputation and trust metrics, and feedback to close the loop will all become bigger and bigger concerns in partially or fully decentralized peer networks as a natural consequence of attacks and exploits like these.
The incentives for groups and individuals (even government) to try and subvert these systems is growing by the day. These networks will either adapt and improve their resilience against these activies, or their users will depart to other networks that do.
Yeah, i shot off the hip in reply to posts about ephemeral ports and obfuscating IP's. The exploit mentioned is not about to choosing good sequence numbers (although that is orthogonal to stopping spoofed insertion/DoS attacks).
So regarding this specific attack, here is a quote from the paper about TCP sequence numbers:
...
a good TCP sequence number generator implementation currently provides enough security to protect against spoofing attacks, at least for the present time and in typical conditions. But increasing bandwidth and processor speed will eventually make brute force guessing of 32-bit ISNs feasible for the average attacker.
If you are using large windows in long lived TCP connections (BGP?) you have made a brute force denial of service (not insertion) a good bit easier for the attacker. Exactly how much easier depends on how large the window is set and how fat the network pipe is to the target system.
In the case of BGP, these servers are often configured with large windows, and have significant bandwidth: ripe for DoS'ing.
If only ISP's were required to do egress filtering
Guessing a port and IP is fairly easy. Guessing the sequence number is not. This is why making sure that TCP initial sequence numbers are random is important.
This is old news.
For the insanely paranoid use a hardware entropy generator (TRNG) for choosing ISN's.
There are all sorts of attacks against network protocols when poor random number sources are used. This is but one example...
I'll shut up after this, promise. :-)
:-) There are also extensions to the ad-hoc routing protocols (like passive monitor of route info between other clients in DSR) that could be supported if only the hardware was open enough to do so.
... and a pony!
Multisecond RTT doesn't happen on anything but GPRS
I've seen it far too often on congested wifi networks. you easily get into a congested state with a crowded AP that forces lots of client waits for the DCF (i.e DIFS + padding, each in turn) and also induces lots of retransmission at the physical level due to collision with so many clients trying to talk to the same AP. Low power clients associated at the 1 or 2 Mbps rates drive this contention over the DCF even higher, severely punishing everyone associated.
The big conference venues are notoriously bad about this, as you often end up with 10-20+ people associated with a single access point. That is just too many, and the 802.11 MAC was never meant to handle that kind of load efficiently. It is a pretty good solution for the general case that simply can't cover all the edge cases (long shots, high client loads, noisy RF environments).
This type of situation results in really weird ping times, for example. I've seen fluctuations myself that go from 80ms, 120ms to 3s!, 2s!, etc. then back down to a few score milliseconds. That is the 802.11 MAC trying to cope with scenario's it was never designed to encounter.
I mentioned software radios in the first post because having access to timing and congestion control in the MAC would allow mesh boxes, clients, and AP's to make very significant performance enhancements for situations where they were needed. Why be forced to use a static, inflexible, proprietary hardware layer when you can have the open flexibility associated with software radio? (It's coming, just not soon enough
I don't want to bitch too much; we have come a long way from sub-megabit data via FHSS over 900Mhz. I just want the really good stuff to hurry up and get here already so that things like mesh networks, low latency/loss voice over IP, and highly available multipath/redundant network configurations can be enjoyed to their full potential. (software radio + multiple input / multiple output + intelligent network stacks that can handle a diverse and volatile network environment).
Gratuitous links:
congestion problems at TechEd conference
congestion melt down at CeBIT
GNU Radio's software defined radio (SDR)
software defined radio on $2,000 of 'roids [it's a dev kit, but would work very well for almost any kind of project]
Good points. What I meant by latency is that losses in the physical layer result in large latencies at the transport layer (i.e. the 802.11 MAC).
:-)
And RTP wont fragment as you mention because of MTU (unless you were doing something really odd with fragmentation at the 802.11 MAC?). I was thinking along the lines of long setup delays for the sessions due to SIP over TCP with larger payloads.
I was a bit harsh on mesh networks. The combination of AODV, DSR, and DSDV is a huge shift in the style of ad-hoc organization and cooperation that makes for a truly useful and individual/community centered approach to communication. It is going to be fun.
I just tend to get a bit annoyed with the grand visions of a nationwide mesh utopia springing up from the bowls of democracy and freedom to release us from the tyranny of Big Co Telecom and whoever else... *grin*
Hmmm, I'm going to avoid discussing security implications of the various protocols for now (that's a whole other can of worms I'm sure you are well familiar with)
Trust and security in decentralized networks makes the security problems of the enterprise look appealing in comparison