Interesting. I'll have to read that J-STD-025A. -TD ALAMEDA, Calif. -- MetaSwitch, supplier of the VP3500, the industry's first true Next Generation Class 5 Switch, announced today that it has completed an extensive review with the FBI, which demonstrates that the MetaSwitch CALEA specification meets the J-STD-025A standard for circuit switching equipment. CALEA, the Communications Assistance for Law Enforcement Act, requires that U.S. carriers provide Law Enforcement Agencies (LEAs) with the continued ability to perform electronic surveillance with existing and new telecommunications switching equipment. Electronic surveillance consists of either the interception of call content (commonly referred to as wiretaps) and/or the interception of call-identifying information (commonly referred to as dialed-number extraction). "We simplified providing CALEA compliance for our customers by incorporating CALEA functionality on-board the MetaSwitch VP3500 rather than requiring additional external equipment", said John Lazar, Vice President of Sales and Marketing. "We are ensuring the completeness of our solution with ongoing testing with the FBI." In light of the current uncertainty in world events, electronic surveillance is becoming increasingly important as a tool for law enforcement agencies. Therefore it is vital that vendors and telecommunications carriers develop and deploy solutions that support electronic surveillance, in both traditional TDM and next generation packet-based networks. Technical requirements or standards for CALEA capabilities have been established for several categories of telecommunications by industry associations or standard-setting organizations, in consultation with representatives of the law enforcement community. The Telecommunications Industry Association (TIA) and Committee T1, standards organizations, are currently working on a further revision, J-STD-025B to cover packet based networks. Metaswitch _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
ALAMEDA, Calif. -- MetaSwitch, supplier of the VP3500, the industry's first true Next Generation Class 5 Switch, announced today that it has completed an extensive review with the FBI, which demonstrates that the MetaSwitch CALEA specification meets the J-STD-025A standard for circuit switching equipment.
What's the chance to amend the H.323 specs with end-to-end encryption, and/or make publicly available design of phone switching system built on fully open designs, something that the user can audit and amend, something over which nobody but the user has the control? There are already general steps in the right direction out there, see eg. http://www.openh323.org/ and http://www.opencores.org/ - could even be a good small-to-medium size business for the manufacturers of the hardware, generic boards for the PABXes - boards with interface circuits, and empty, user-programmable FPGAs? An open-source FPGA core firmware could come free with the package, or developed in-house to suit needs (or, most likely, combination of both approaches - build the function from blocks). Then we'd get cheaper private switchboards with guaranteed NO CALEA "extensions", full knowledge of what's inside (and the associated chance to do our own in-house service without need of expensive vendor service contracts and dependency on their servicemen). Fully open, fully documented designs are the only doable way of getting infrastructure building blocks that aren't vulnerable to incorporating (either by the vendor being forced by law, or by "voluntary cooperation") of little agents of Big Brother. Or did I smoked one puff too much?
At 11:07 PM 04/11/2003 +0200, Thomas Shaddack wrote:
ALAMEDA, Calif. -- MetaSwitch, supplier of the VP3500, the industry's first true Next Generation Class 5 Switch, announced today that it has completed an extensive review with the FBI, which demonstrates that the MetaSwitch CALEA specification meets the J-STD-025A standard for circuit switching equipment.
What's the chance to amend the H.323 specs with end-to-end encryption, and/or make publicly available design of phone switching system built on fully open designs, something that the user can audit and amend, something over which nobody but the user has the control? .. Or did I smoked one puff too much? Smoke away - the situation is both better and worse than you think :-)
H.323 isn't quite dead, but the impressions I've gotten before and at the recent Voice On The Net conference are that SIP is pretty much taking over, and H.323 is at least resting and pining for the fjords, even if nobody's nailed its feet to the perch yet. And some people have addressed encryption issues with SIP, though I'm not sure of the exact standards status. H.323 looks a lot like some of the ISDN protocols - designed by people who didn't really have a clue about how to make things work well on the Internet, but who did like complex and ugly features. SIP isn't perfect, and it apparently has some issues with NAT, but it's a fairly well-behaved Internet-like standard, and there was a lot of work done to make things extensible and modular and let services be provided by networks of servers rather than monoliths. While H.323 is ugly and doomed, it can be used for direct user-to-user calls, and Microsoft did everybody a major favor a few years ago with Netmeeting, which does H.323 for audio, video, and shared whiteboarding, for free, and while it doesn't do conferencing well, it's quite usable for person-to-person calls as long as there's no NAT in the way and everybody runs it, plus it can use an IIS server for tracking who's on. And you can run it over IPSEC, though there's usually overhead. The basic problem SIP tries to solve is to have some method of tracking user presence, and telling users who want to talk to each other how to reach the others systems, with a bunch of optional extra activities like multi-person calls. (If that sounds like what H.323 does, yes, that's true, but H.323 feels like it was designed by someone much worse at programming than Microsoft, vs. solving the same problems on Unix.) If all you wanted to do was let SIP users talk to other SIP users, this would be pretty simple, but that's not the main market - real systems need to talk to existing phone networks as well, and they need to provide many of the standard business features like voicemail and different types of conferencing, and those add lots of complexity. The two main environments this can run in are PBXs (phone switch on customer premises, run by the customer, getting some long-haul from a carrier) and Phone Companies, either local or long distance, who own the old phone infrastructure, may have better economies of scale, and often provide Internet service as well as telephony. IP telephony has lots of ways to build hybrids, and economies of scale matter a lot less in a Stupid Network with the control functions happening on glorified PCs than they did with 1960s phone switches. From the perspective of a Phone Company, the hardest problems with the emerging IP telephony market involve figuring out how to make money while the whole industry is collapsing around us (:-), and some of those methods involve finding new and innovative features that we can provide slightly better than other ISPs because we have a hundred years of experience. (Yes, I realize that the hundred years of experience involves lots of dead weight and useless baggage :-) One of the annoying pieces of baggage that phone companies have in many countries is regulation, and in the US, that includes the CALEA wiretapping rules, which apply to us and don't appear to apply to businesses providing their own phone service using equipment they buy from hardware and software vendors like Cisco and MS, or to those vendors. This annoying baggage not only shows up when we plan consumer telephony evolution, which is mostly in the future, it also shows up when we reply to RFPs from businesses that want people to manage their telephone systems for them. It is not only annoying because it's an offensive invasion of privacy, it's annoying because it's really hard to implement well in an evolving tech environment, and it's annoying because we and some of our competitors have to do it while others of our competitors don't have to. But in a SIP world, there's not much difference between a wiretap and a conference call where one party is on mute, and it's really really easy to build fancy calling features like conferencing. At Voice On The Net last week, our development people were demonstrating interesting systems like "You're on a phone call at your office, and you want to go home but the people you're talking to won't shut up, so you tell your phone to conference in your cellphone, which connects in silently without losing anybody from the call, and you drive home, and when you get there you press keys on your analog cellphone to tell the call that you now want it to switch to the software phone on your PC, and tell the popup window on your PC that you also want the call to play on the speaker in the kitchen while you get yourself a beer". Another generic kind of demo they did was follow-me numbers - the Centrex knows that when you get a call (IP or old-style), it should first try ringing your desk and your lab phone simultaneously and if you don't answer at either of those, try your cell phone if it's before midnight or the caller is on your buddy list. Letting the FBI join in on your call isn't too hard, if they can tell the call control system what to do - the hardest part is finding a way to let all the different kinds of phones Not Warn The User, since most phones are really just software, and the software writers like to add features like "Hey, Bob just joined your conference, do you want to send him the draft of the memo, and do you want to add in his video?" and "Find who's using Music-on-Hold and delete their MP3 collection". It's somewhat different for two-party pure-SIP calls, which can go peer-to-peer, while some of the more complex call types run the voice bits through the call manager or conference bridge so it has a handle to build things with, but of course the calls can often be moved between those environments. http://www.iptel.org/info/products/sipphones.php has a nice list of SIP phones (software and hardware, including free software.) Grandstream makes a nice $75 SIP phone as well. There's a lot of other open source telephony work, much of it sponsored by hardware vendors trying to facilitate their sales. Google. You can take SIP or H.323 and run them through IPSEC tunnels, but there turn out to be some annoying inefficiencies - the IP and RTP headers take up a lot of space, often turning 8kbps compressed voice into about 22-24kbps. You can run compressed headers (cRTP is sort of like the old cslip), cutting it down to 11-12kbps, but only over raw Layer 2 transport, not over IPSEC, which also adds headers. It's cleaner to do the crypto along with the voice compression, and the SIP standards support that (but I don't know how many people use it), though of course anything the SIP helps to set up, the SIP can set up wiretaps for. The other piece of really annoying telco regulation baggage is 911 (emergency telephone service, which some of you non-US folks dial 999 for.) Unlike wiretapping, which is inherently offensive, this part is mainly annoying because it's a hard problem, and regulations can make it impossible for telcos to bid on projects without solving it, plus it's something that customers actually want, unlike wiretapping. With Real Telco Telephones, the phone number tells you what building a phone is in, so 911 can send the fire truck to the right building. With IP telephones, the gateway to the phone company might not be on the same side of the continent as the phone, so calling the local fire trucks is a bad idea, and you can plug your phone in anywhere (if it's hardware) or run your phone software from any PC, maybe over a VPN, so your phone number isn't always in the _same_ wrong place. Some of the IP PBX makers have crude hacks for the problem, but it's hard.
I got a request from a (US) psychiatrist that m-o-o-t (m-o-o-t is a CD that boots on your computer, and does secure things) should include an implementation of VOIP, to allow his patients to securely connect to his server. I think they are mostly servicemen or spies, but so what. It's actually easy to do a version that will do that, and if you're listening, I'll do it soon, and for free to you only :) - but m-o-o-t is based on OpenBSD, and isn't that good at modems. Linux isn't that good either... The problem is that the usual, everyday, modem is _only_ supported by Windows... which thereby gains a competitive advantage, based on it's monopoly position. While I have no beef (and being a UK person I eat no beef anyway) with the idea that there should be a single computing platform/ interface, and I don't expect manufacturers to do the work, I do think that interfaces used en masse should, in general, be communal property. That includes modem interfaces, especially. Apple is no better either here. I'd like to suggest that those who don't provide details of their modems' functionality (which is the main problem) should be boycotted. Or killed. Similar applies to all hardware. It's not a very libertarian perspective, and I like to think I am a libertarian - but so be it. The alternative is... -- Peter http://www.m-o-o-t.org ps Tim was right about cosmic rays, it's cosmic background radiation that does the 1% noise on TV's - which is even more "Cosmic" imo - but then I'm wrong from time to time.
Peter Fairbrother wrote:
I got a request from a (US) psychiatrist that m-o-o-t (m-o-o-t is a CD that boots on your computer, and does secure things) should include an implementation of VOIP, to allow his patients to securely connect to his server. I think they are mostly servicemen or spies, but so what.
Voice Over IP? I wouldn't bother and it sounds unlikely that anyone would use this.
It's actually easy to do a version that will do that, and if you're listening, I'll do it soon, and for free to you only :) - but m-o-o-t is based on OpenBSD, and isn't that good at modems. Linux isn't that good either...
The problem is that the usual, everyday, modem is _only_ supported by Windows... which thereby gains a competitive advantage, based on it's monopoly position.
No it's only winmodems which are supported only by windows. Winmodems are found often in cheap laptops. Acually some winmodems are supported by linux http://www.linmodems.org/ although not by OpenBSD -- Steve
At 05:04 AM 04/13/2003 +0100, Peter Fairbrother wrote:
I got a request from a (US) psychiatrist that m-o-o-t (m-o-o-t is a CD that boots on your computer, and does secure things) should include an implementation of VOIP, to allow his patients to securely connect to his server. I think they are mostly servicemen or spies, but so what.
It's actually easy to do a version that will do that, and if you're listening, I'll do it soon, and for free to you only :) - but m-o-o-t is based on OpenBSD, and isn't that good at modems. Linux isn't that good either...
I don't know about OpenBSD, but supposedly Linux is getting better at handling Winmodems, at least for the most common chipsets. You might want to check with Perry Metzger, one of the founders of Wasabisystems.com, which is a company that ports NetBSD to things; perhaps they've got better driver sets than the OpenBSD folks. Also, in addition to looking at openh323.org, you should probably check out Speak Freely. http://speakfreely.org/ has the 7.2 version, and John Walker recently prereleased some 7.6 versions at http://www.fourmilab.ch/speakfree/windows/download/ and maybe http://web.tiscali.it/vitez/picophone.html
I'd like to suggest that those who don't provide details of their modems' functionality (which is the main problem) should be boycotted. Or killed. Similar applies to all hardware.
Too late for that, and some of them have reproduced already so you won't even be keeping them out of the gene pool...
On Sun, Apr 13, 2003 at 05:04:10AM +0100, Peter Fairbrother wrote:
I got a request from a (US) psychiatrist that m-o-o-t (m-o-o-t is a CD that boots on your computer, and does secure things) should include an implementation of VOIP, to allow his patients to securely connect to his server. I think they are mostly servicemen or spies, but so what.
It's actually easy to do a version that will do that, and if you're listening, I'll do it soon, and for free to you only :) - but m-o-o-t is based on OpenBSD, and isn't that good at modems. Linux isn't that good either...
Really? You got this mail through an old modem and linux box..
The problem is that the usual, everyday, modem is _only_ supported by Windows... which thereby gains a competitive advantage, based on it's monopoly position.
Google for 'winmodem' and linux finds: http://www.linmodems.org/ plus lots of other links you may find useful. Microsoft's lock on the winmodem appears to have been pretty short.
While I have no beef (and being a UK person I eat no beef anyway) with the idea that there should be a single computing platform/ interface, and I don't expect manufacturers to do the work, I do think that interfaces used en masse should, in general, be communal property.
Commonly used interfaces do eventually become well known. While they do have owners, the amount of market interia they develop makes then essentially unchangeable. But demanding that they be "communal property" sounds like the sort of socialism that can only be imposed by authority and fails when it is imposed.
I'd like to suggest that those who don't provide details of their modems' functionality (which is the main problem) should be boycotted.
That's been done before-- Diamond refused for years to supply info to Xfree86, so there was a boycott of Diamond graphic cards in the Linux community. They eventually saw the light (or market).
It's not a very libertarian perspective, and I like to think I am a libertarian - but so be it. The alternative is...
1. figuring out the winmodem interface. It's software, so its possible. But it appears that others have already done the work for at least some winmodem chips. 2. boycotting winmodem makers. Not likely to work in this case since most modem makers sell the things. Besides, the market drive for reduced chip count and the PC makers' hunger for anything that chews up CPU cycles and drives consumers to buy faster machines is a lot stronger than that for linux. 3. beg for some higher power to "do something". You can probably guess from my tone that I don't think much of this option. Eric
Really? You got this mail through an old modem and linux box..
The keyword is *OLD* modem. There were times when the interface was RS232, the manufacturers voluntarily obeyed the Hayes standard AT command set, and their vendor-specific extensions were typically documented in the booket you got with the modem. No special drivers, no proprietary interfaces, as the computers were meant to be when Gods created them.
Microsoft's lock on the winmodem appears to have been pretty short.
Depends on vendor and chipset.
Commonly used interfaces do eventually become well known. While they do have owners, the amount of market interia they develop makes then essentially unchangeable.
PROBLEM: Depends on how willing the vendor is in documenting the chipset.
But demanding that they be "communal property" sounds like the sort of socialism that can only be imposed by authority and fails when it is imposed.
Interfaces, APIs, and standards are WAY too important to be let exclusively in the hands of the manufacturers. Besides, there is no point in proprietariness of technology as if the vendors want to keep exclusivity for manufacturing of their designs, they already have the infrastructure of (*spit*) patents. I am pretty militant in this issue. No compromises.
That's been done before-- Diamond refused for years to supply info to Xfree86, so there was a boycott of Diamond graphic cards in the Linux community. They eventually saw the light (or market).
...and for years it was impossible to use Diamond cards in real operating systems. Good.
1. figuring out the winmodem interface. It's software, so its possible. But it appears that others have already done the work for at least some winmodem chips.
VERY labor-intensive. Requires highly qualified workforce. Barely suitable only for the most common chipsets. (See the end for more comments.) Wastes brain-hours that could be invested better.
2. boycotting winmodem makers. Not likely to work in this case since most modem makers sell the things. Besides, the market drive for reduced chip count and the PC makers' hunger for anything that chews up CPU cycles and drives consumers to buy faster machines is a lot stronger than that for linux.
Won't work well, and surely won't work well for integrated modems in laptops.
3. beg for some higher power to "do something". You can probably guess from my tone that I don't think much of this option.
I would be happy if we could ignore this option. However, still better than nothing; you have to have a really big stick for the big vendors. Maybe it could be sneaked into something about security or infrastructure protection/maintenance. One more option: 4) Extend Assassination Politics to high managers. Everyone who peddles proprietary technology and refuses to open their documentation should be killed in a long and painful way. They should pay for the frustration they inflict onto the field technicians. Or a version of 4), 5) A bounty for the information leaks. Have a cash pool with a bounty for the one who will leak the given "proprietary" information into the Public Domain. This could extend to schematics and service manuals. However, the option 1) would be the best, if we'd manage to dramatically reduce the amount of labor necessary to tear a proprietary driver apart. This requires development of good, easy to use reverse engineering tools.
Interfaces, APIs, and standards are WAY too important to be let exclusively in the hands of the manufacturers. Besides, there is no point in proprietariness of technology as if the vendors want to keep exclusivity for manufacturing of their designs, they already have the infrastructure of (*spit*) patents.
It is so important that people should be forced to sell things that adhere to a mandaded system? Should I be forced to write code in a spcific way? This isn't academic - I'm about to push code to CPAN. I'm going to do so because I think there's a commercial advantage it releasing the code. Are you proposing that I be forced to write to some spec (that doesn't exist)? (I must say that I'm not defending Microsoft. I think they're killing innovation everywhere they can. Typical monopoly behaviour - it isn't interesting. Transforming them into a public utility is not the way to call them to task. Making them an AT&T is.)
I am pretty militant in this issue. No compromises.
I largely agree that it is aweful that IT is so stagnent.I'm personally doing OK, if not great, selling change. I sell open source agressively. Sometimes, I sell closed source. Best tool, best job. Trade is about what works. I do have a personal preference, but that does not interfere with what I tell clients, because I fell I have a duty to tell then facts. -- Jamie Lawrence jal@jal.org "If this were a dictatorship, it'd be a heck of a lot easier... just as long as I'm the dictator...." - GW bush, http://www.cnn.com/TRANSCRIPTS/0012/18/nd.01.html
It is so important that people should be forced to sell things that adhere to a mandaded system? Should I be forced to write code in a spcific way? This isn't academic - I'm about to push code to CPAN. I'm going to do so because I think there's a commercial advantage it releasing the code. Are you proposing that I be forced to write to some spec (that doesn't exist)?
It's critical that vendors adhere to published specs. They can be "standard" ones, they can be their own ones, but they have to be PUBLISHED. Either as an RFC-like document, or as the source code of the program/driver itself. I don't care about the form as long as I can take that damned thing and glue it to whatever I am building at the moment without having to reverse-engineering it. (Or, even more important, that when I will be tracing why it doesn't work as expected, I will know where I have to look for what.) If the specs are too tight for you to fit, or aren't at all, good for me - but I want to have enough of data to write an eventual convertor from/to something other. What it does inside is your business, but I want to know what goes in and out - protocols and data formats.
(I must say that I'm not defending Microsoft. I think they're killing innovation everywhere they can. Typical monopoly behaviour - it isn't interesting. Transforming them into a public utility is not the way to call them to task. Making them an AT&T is.)
I want to see Billy "Greedy" Gates having to powerlessly watch his power disappearing, his clout leaking through his fingers, his empire crumbling. This would hurt him more than losing money. I want to see him suffer. I want him to end in Hell, reinstalling Windows NT 5 forever.
I largely agree that it is aweful that IT is so stagnent.I'm personally doing OK, if not great, selling change. I sell open source agressively. Sometimes, I sell closed source. Best tool, best job. Trade is about what works. I do have a personal preference, but that does not interfere with what I tell clients, because I fell I have a duty to tell then facts.
I go for open source whenever I can. If I can't have the source, I want at least the specs. I would have to think hard to find what I hate more than feeling powerless - when a binary-only thing doesn't work correctly and I can't take a look into it and litter the suspicious part of code with debug messages. (I am in fighting mood now, freshly after winning a several hours long battle with gnokii, smsd, and Nokia 3310, trying to figure out why that damned thing sent a message 4 times and claimed error. The reason was a response timeout constant defaulting to -1 (no wait) instead of 30 (at most 3 seconds wait). If it'd be a binary-only thing, I'd have to wait at least a day for the vendor's response, likely MUCH longer - if it would have support at all.) Mark Twain was right, when he said that the nearest helping hand is right at the end of your shoulder. :) I just wish the corporations would let people help themselves and wouldn't push for artificial complexity and forced dependence on their "good will".
Thomas Shaddack wrote on April 13, 2003 at 22:45:33 +0200:
But demanding that they be "communal property" sounds like the sort of socialism that can only be imposed by authority and fails when it is imposed.
Interfaces, APIs, and standards are WAY too important to be let exclusively in the hands of the manufacturers. Besides, there is no point in proprietariness of technology as if the vendors want to keep exclusivity for manufacturing of their designs, they already have the infrastructure of (*spit*) patents.
I am pretty militant in this issue. No compromises.
If I want to keep secret the details of something I make, it is my right to do so. Don't like it? Don't fucking buy it. (Snipped)
4) Extend Assassination Politics to high managers. Everyone who peddles proprietary technology and refuses to open their documentation should be killed in a long and painful way. They should pay for the frustration they inflict onto the field technicians.
Any communist maggots that murder, or attempt to murder people for merely keeping secret the details of the stuff they make and sell should be bound, gagged, tortured, then taken out back to have their skulls crushed with a sledgehammer until their brains start oozing out their ears. -- Tom Veil
On 14 Apr 2003, Tom Veil wrote:
If I want to keep secret the details of something I make, it is my right to do so.
Then I have the right to appropriately dislike you, and to reverse-engineer the "product", which is so shoddy that you are ashamed of documenting its internals, and to publish it. I am currently HEAVILY pissed, as we built our servers on ASUS motherboards (otherwise pretty good) with AS99127F chips for health monitoring. We run Linux on them. When I load the appropriate drivers to activate the onboard sensor chip, the speaker starts beeping an alarm and won't stop until hardware reset. So I either have to sacrifice the sensors (which can be potentially fatal, one of my servers had problems (weird crashes) because of cooling fan, and because of no sensors support (old board) it took me several crashes to identify the pattern (it was a remote, unattended machine)), or I have to unplug the internal squeaker, which makes it difficult to assess boot-time problems. I met MANY other problems of this kind.
Don't like it? Don't fucking buy it.
THERE IS NO CHOICE! Couple months ago we were shopping for a PABX. The only possibilities available were Siemens, Nortel, and Bosch. No one of them supplied any service-level documentation, all three wanted to lock us into an expensive service contract. We have to wait for hours in case of every little hiccup, instead of me taking a look at the box and giving it the right commands, because I DON'T KNOW THE FUCKING COMMANDS AND NOBODY TELLS ME WHAT THEY ARE!!! There is of course the choice of doing without the phones, but you can't run a bigger office without telephones. And the open-source PABX constructions that are out there aren't mature enough for practical use yet :((( And if there is a choice, tell me what brand of a cellphone comes with full docs, what TV comes with full docs (see lower), what hard drive comes with full docs (which is especially painful as it makes problems with secure data overwriting).
Any communist maggots that murder, or attempt to murder people for merely keeping secret the details of the stuff they make and sell should be bound, gagged, tortured, then taken out back to have their skulls crushed with a sledgehammer until their brains start oozing out their ears.
...and after you kill off all the technicians with a peeve against the money-hungry corporations (read: everyone who ever tried to do some real work on a budget), you will pay through your nose for every hiccup, and not only in money, but also in time loss and in being whined at for not being able to do something immediately. I could talk for long about "intellectual property", my pet peeve, but one paragraph will do. There was no such concept for millenia. Imagine how it could slow down the progress if eg. alphabet or calculus would be someone's "property", and the someone would then aggressively enforce the royalties or "licence conditions". How many people would think reading is worth of the added expenses? (...and how many would just "steal" the knowledge without paying? Or maybe decide to "opt out" - the literacy results of American students are going down... not even talking about calculating with just a pencil and paper. *sigh*) Besides, the proceedings rarely go to the inventors themselves - or did you expect that the inventor of eg. LED got rich? In way too many cases the "intellectual property" is a yoke to keep the market share, to deny others the access there, to slow down the others when the "owner" can't cope by fair play. Sorry, this isn't the kind of game I want to play. Not by these rules. I don't even talk about the insecurity factor for the public infrastructure. The documentation will leak sooner or later, or the crucial parts will be acquired and reverse-engineered, and someone who will want to cause damage will get ahold of the information. A determined attacker has a choice where he wants to invest the effort, but a determined defender has no other choice than to be intimately familiar with ALL parts of their infrastructure - and you can't sanely expect to be able to reverse-engineer every byte of every firmware of every your critical device, nor can you expect the vendors to plug all the holes, especially in older devices. (Especially not in the pace the devices get obsolete, the artificially fueled march towards unreliability, towards the promises of better results in next version. After all, what's better force to upgrade than a bug in your old device, which you can't repair because of no docs, and which the vendor won't repair because their interest is to make you buy something new? With the only thing you can be confident about being the increasing shoddiness of new electronics, as the time-to-market takes precedence over testing and debugging! *spit* Phooey! And then you come and have the balls to defend the "right" of the vendors to not reveal how crappy and unfinished is what they dare to call a "product".) Back during the Communism there was a small shop here, where it was possible to buy schematics and docs for all the consumer devices manufactured by Tesla, local manufacturer. Their quality was widely underestimated (or, more accurately, the quality of the Western crap was overestimated, as not enough people opened the imported equipment to make the public aware about the cheap material of the circuitboards, usage of plastic levers and gearwheels where metal would be more suitable, and mistaking design for quality). With available documentation the followup came, with hobbyists devising add-ons, repairs, and tweaks, and publishing them in a widely read magazine. (If Tesla would follow and incorporate the tweaks into newer submodels, then they could get much better quality. But, as Communist way of leading the factories was more about careerism and politics than about technology, it didn't happen. On the other hand, capitalism is more about money than about technology, so no big difference either. *sigh*) Now, the users are actively discouraged from understanding the internals of their appliances, maybe in order to keep the advertising effective in peddling trivial add-ons (eg, home networking) as groundbreaking features. There is an expression to characterize the techno-economical system we're heading into: CRAPITALISM! The case of Blackboard security, which recently flashed through Politech (thanks, Declan!), nicely illustrates the situation - technical shortcomings addressed by lawyers. Vendors, who keep crucial informations away from the customers, should be shot. The ones, who try to sue the reverse engineers, should be boiled in oil before being shot.
On Tue, 15 Apr 2003, Thomas Shaddack wrote:
Then I have the right to appropriately dislike you, and to reverse-engineer the "product", which is so shoddy that you are ashamed of documenting its internals, and to publish it.
I am currently HEAVILY pissed, as we built our servers on ASUS
[rant snipped]
Vendors, who keep crucial informations away from the customers, should be shot. The ones, who try to sue the reverse engineers, should be boiled in oil before being shot.
I guess I have to agree :-) Back in the early '80's I reverse engineered a Harris PBX. Replacing its 8080 microprocessor with a 68020 allowed me to take over total control of the switch and make the long distance company I worked in far more competitive. It took a lot of effort and equipment, and Harris Corp. never even believed we did it. Good thing, or they would have probably sued us! Reverse engineering in that case makes 1 company far more competitive. But in most cases simply understanding the principles is all you need to build a better product. The problem is then manufacturing, marketing and selling the better product. Most people are lazy, they just steal the idea and duplicate the principles, maybe with cheaper parts. That's where I think the lawyers have a good job. But if someone can figure out a better way to do things, then the person who hired the lawyers to harrass them needs to be boiled in oil. Anything that slows the advance of technology is a bad thing, and there's too many laws now aimed at exactly that. Patience, persistence, truth, Dr. mike
(This message was sent before, with the wrong subject and reference.) Thomas Shaddack wrote on April 15th, 2003 at 23:30:57 +0200:
On 14 Apr 2003, Tom Veil wrote:
If I want to keep secret the details of something I make, it is my right to do so.
Then I have the right to appropriately dislike you, and to reverse-engineer the "product", which is so shoddy that you are ashamed of documenting its internals, and to publish it.
I've never said that people should be legally punished for tinkering with the stuff they've bought, nor do I think they should. (snipped)
Don't like it? Don't fucking buy it.
THERE IS NO CHOICE!
Well I guess that's tough, isn't it? There simply isn't much of a market for open, fully-documented products. Of course, you are free to make your own fully-documented, open-source products, or encourage those companies to make documentation available to implementers and administrators.
Any communist maggots that murder, or attempt to murder people for merely keeping secret the details of the stuff they make and sell should be bound, gagged, tortured, then taken out back to have their skulls crushed with a sledgehammer until their brains start oozing out their ears.
...and after you kill off all the technicians with a peeve against the money-hungry corporations (read: everyone who ever tried to do some real work on a budget), you will pay through your nose for every hiccup, and not only in money, but also in time loss and in being whined at for not being able to do something immediately.
I didn't say anything about killing technicians. I _did_ say things about killing people who would murder others for keeping secrets.
I could talk for long about "intellectual property", my pet peeve, but one paragraph will do. There was no such concept for millenia.
While protecting IP is a duly authorized power of the US government, the way it extends protection for periods of time sometimes spanning the entire course of an average human lifespan, is far beyond any reasonable interpretation of the "limited Times" proviso in Article I, Section 8, and such excessively long periods of protection should be ruled unconstitutional. As for the DMCA, it is simply an atrocity. Obviously unconstitutional.
And then you come and have the balls to defend the "right" of the vendors to not reveal how crappy and unfinished is what they dare to call a "product".)
I defend the right of EVERYONE to try and keep stuff secret that they want to keep secret. Of course, tough shit if somebody discovers this secret in a non-coercive fashion.
Vendors, who keep crucial informations away from the customers, should be shot.
If you attempt to shoot people for the "crime" of keeping something secret, I will ally with them in efforts to liquidate you.
The ones, who try to sue the reverse engineers, should be boiled in oil before being shot.
This may be acceptable. Actually, the members of Congress who enabled these sorts of lawsuits should be liquidated. -- Tom Veil
Thomas Shaddack wrote on April 15th, 2003 at 23:30:57 +0200:
On 14 Apr 2003, Tom Veil wrote:
If I want to keep secret the details of something I make, it is my right to do so.
Then I have the right to appropriately dislike you, and to reverse-engineer the "product", which is so shoddy that you are ashamed of documenting its internals, and to publish it.
I've never said that people should be legally punished for tinkering with the stuff they've bought, nor do I think they should. (snipped)
Don't like it? Don't fucking buy it.
THERE IS NO CHOICE!
Well I guess that's tough, isn't it? There simply isn't much of a market for open, fully-documented products. Of course, you are free to make your own fully-documented, open-source products, or encourage those companies to make documentation available to implementers and administrators.
Any communist maggots that murder, or attempt to murder people for merely keeping secret the details of the stuff they make and sell should be bound, gagged, tortured, then taken out back to have their skulls crushed with a sledgehammer until their brains start oozing out their ears.
...and after you kill off all the technicians with a peeve against the money-hungry corporations (read: everyone who ever tried to do some real work on a budget), you will pay through your nose for every hiccup, and not only in money, but also in time loss and in being whined at for not being able to do something immediately.
I didn't say anything about killing technicians. I _did_ say things about killing people who would murder others for keeping secrets.
I could talk for long about "intellectual property", my pet peeve, but one paragraph will do. There was no such concept for millenia.
While protecting IP is a duly authorized power of the US government, the way it extends protection for periods of time sometimes spanning the entire course of an average human lifespan, is far beyond any reasonable interpretation of the "limited Times" proviso in Article I, Section 8, and such excessively long periods of protection should be ruled unconstitutional. As for the DMCA, it is simply an atrocity. Obviously unconstitutional.
And then you come and have the balls to defend the "right" of the vendors to not reveal how crappy and unfinished is what they dare to call a "product".)
I defend the right of EVERYONE to try and keep stuff secret that they want to keep secret. Of course, tough shit if somebody discovers this secret in a non-coercive fashion.
Vendors, who keep crucial informations away from the customers, should be shot.
If you attempt to shoot people for the "crime" of keeping something secret, I will ally with them in efforts to liquidate you.
The ones, who try to sue the reverse engineers, should be boiled in oil before being shot.
This may be acceptable. Actually, the members of Congress who enabled these sorts of lawsuits should be liquidated. -- Tom Veil
participants (11)
-
Anonymous -
Anonymous-Remailer＠See.Comment.Header -
Bill Stewart -
Eric Murray -
Jamie Lawrence -
Mike Rosing -
Peter Fairbrother -
Steve Mynott -
Thomas Shaddack -
Tom Veil -
Tyler Durden