Posted by
chrisd
on from the law-and-technology dept.
cf_33073 writes "Scary stuff for the privacy advocates out there. Your Internet telephone conversations may soon be tapped by the government. Anyone else concerned about these intercepts being hacked?
Full text of the
RFC
Is available (mirror)"
Since the connection is digital, it shouldn't be tough to add a layer of encryption onto your conversation. Let 'em monitor scrambled data.
Encryption .. wont be legal much longer.
by
nurb432
·
· Score: 4, Informative
The only way these rules will work is if encryption is taken out of the hands of the public.
Can it be accomplished at this point? I donno, but a first start is calling the use of any un-approved ( i.e. , no governmental backdoor key ) encryption cause for the use to be investigated under the patriot act..
Then it will be made outright illegal, as its placed back on the 'controlled munitions' list.
Many of the comments in response to this story demonstrate that the posters have neither read the referenced RFC nor understand the problem it is trying to solve. I'll restate it for the stupid or perpetually lazy among you (i.e. most of you who've responded so far):
Telecommunications companies in many countries must by law provide "assistance to law enforcement" on occasion. Note: in many countries, not just the United States. This assistance has traditionally been in the form of providing call intercept and tracing on voice networks. Some governments in many countries now want to do the same thing for data packets, but moreover, when data networks are used to emulate "traditional" voice services, the existing laws already apply. Just because your ISP's telecom backbone runs over ATM or IP doesn't mean that they're off the hook when it comes to lawful intercept and emergency services (e.g. E911) regulations. When voice is extended to "the edge" in packet form, little changes in that regard.
Now, that said, this RFC proposes an architecture to support tapping data (and any application layer-services that run on it, e.g. voice) in a uniform and scalable manner. Whether you like the idea of tapping or not is immaterial and irrelevant. Service providers must obey the law. If they cannot, they go out of business, or in some cases, never get off the ground. And make no mistake; this RFC is no more about "voice" than any other data service; it describes some of the special problems with enabling the enforcement of existing wiretap laws for packet voice, yet the aim of the RFC is to solve the general problem.
The architecture proposed makes no assumptions about the use of encryption except that no assumptions can be made about the use of encryption; i.e. deliver "tapped" packets to the LEA as packets, not transcoded or decoded into some other format.
Sybase markets USA PATRIOT Act transaction scanner
by
nate.sammons
·
· Score: 5, Informative
This ad from Sybase has information about a "compliance solution" for customers complying with the new USA PATRIOT Act.
From their ad: "It integrates your existing customer and transaction information systems into a consolidated compliance system that detects unusual activity and automates its investigation and resolution in a timely, secure and meticulously documented manner."
Slashdot Mirror
Since the connection is digital, it shouldn't be tough to add a layer of encryption onto your conversation. Let 'em monitor scrambled data.
The only way these rules will work is if encryption is taken out of the hands of the public.
Can it be accomplished at this point? I donno, but a first start is calling the use of any un-approved ( i.e. , no governmental backdoor key ) encryption cause for the use to be investigated under the patriot act..
Then it will be made outright illegal, as its placed back on the 'controlled munitions' list.
---- Booth was a patriot ----
Many of the comments in response to this story demonstrate that the posters have neither read the referenced RFC nor understand the problem it is trying to solve. I'll restate it for the stupid or perpetually lazy among you (i.e. most of you who've responded so far):
Telecommunications companies in many countries must by law provide "assistance to law enforcement" on occasion. Note: in many countries, not just the United States. This assistance has traditionally been in the form of providing call intercept and tracing on voice networks. Some governments in many countries now want to do the same thing for data packets, but moreover, when data networks are used to emulate "traditional" voice services, the existing laws already apply. Just because your ISP's telecom backbone runs over ATM or IP doesn't mean that they're off the hook when it comes to lawful intercept and emergency services (e.g. E911) regulations. When voice is extended to "the edge" in packet form, little changes in that regard.
Now, that said, this RFC proposes an architecture to support tapping data (and any application layer-services that run on it, e.g. voice) in a uniform and scalable manner. Whether you like the idea of tapping or not is immaterial and irrelevant. Service providers must obey the law. If they cannot, they go out of business, or in some cases, never get off the ground. And make no mistake; this RFC is no more about "voice" than any other data service; it describes some of the special problems with enabling the enforcement of existing wiretap laws for packet voice, yet the aim of the RFC is to solve the general problem.
The architecture proposed makes no assumptions about the use of encryption except that no assumptions can be made about the use of encryption; i.e. deliver "tapped" packets to the LEA as packets, not transcoded or decoded into some other format.
This ad from Sybase has information about a "compliance solution" for customers complying with the new USA PATRIOT Act.
From their ad:
"It integrates your existing customer and transaction information systems into a consolidated compliance system that detects unusual activity and automates its investigation and resolution in a timely, secure and meticulously documented manner."
Yikes.