The problem with your analysis is that mass *is* energy *is* mass.
A flywheel is an energy storage device - the faster it spins the more enengy it has the moer massive becomes.
If you slowed the flywheel down you would bleed the energy off into another storage device - that would become more massive proportional to the energy stored.
e=mcc works both ways. For a given quantity of stored energy you can calculate how much mass it is adding to the rest mass of its container.
When the P2P people want to allow easy cooperation (and not circumvention) of firewalls and stuff, the ought to design their protocols in the direction of corporation.
Damn P2P - I am tasked with making a client2server setup as smooth as possible for the end users.
So, where is this document that tells me in a generic way how to cooperate with some BOFH blanket filter on outgoing ports?
Really - I want to use a unique port number for my service - to be friendly to sysadmins who might like their logs of port numbers to be meaningfull. But - I can't. Invariably some idiot on a powertrip has blanket banned a range (i.e. everything) that contains my port selection.
My only way out of this hole (in terms of getting software to the end user that workd) is to port whore, and port whoring is going to become a massive problem if outgoing port filtering persists. I'll do it for one, and I'm sure many other developers will join the bandwagon too - Unless there is a book/URL someplace that tells me and other developers who to cooperate with, rather than evade, a firewall.
I am saying I dislike you and your kind. I mean that in the nicest possible way of course: my intention is not to be rude or flame - I have just been pissed off past my ability to endure by admins that, in my mind, are not thinking clearly (or have their hands tied by (even more) incompetent management.
I block large ranges of ports on a regular basis, because there's no business for *any* external traffic to come into my LAN.
"*any*"? Just one line later you contradict this statement yourself and allow for incoming connections in certain situations.
Also, I assume you meant connections not traffic, surely the tightly controlled users on your LAN are allowed to retrieve the results of their web browsing.
HTTP, HTTPS, FTP, and a limited few others get inbound permissions to specific servers (On a different extranet subnet) that are hardened for those specific tasks.
How to be polite.
hmmm.
Oh to be one of the dirty unwashed untrusted masses an your LAN.
I used to hate it when reporters on TV and in magazines would confuse the "Internet" with the "World Wide Web" but I see that WWW access is all some are given.
And if you think that security should *only* be on inbound traffic, you've obviously never seen a coworker led off in handcuffs after attempting to (illegally) hack another companies servers and leave his company to blame while he skips town.
Some random thoughts:
1. If a company can't trust their own employees who can they trust?
2. This point is invalid because you have shot yourself in the foot anyway: Excessive port filtering makes programmers & hackers choose specific ports used by legitimate applications:- Finally, once everything is done via port 80, how exactly are you going to get any meaningful filtering done at all?
3. Does the company also have metal detectors on the doors and are all the papers and disks the employees leave the building with checked?
If your App has both the server and clients inside the firewall, no problem.
That's not exactly now the "Internet" with a capital I now is it. Its a LAN application that happens to use TCP/IP as a protocol.
If your client-server application is sensitive, and it crosses the internet, you should be using a VPN tunnel or SSH to cross the firewall in the first place, instead of sending passwords in the clear!
The Internet - capital I. An internet (small I) is any network of tcp/ip hosts that may or may not be connected via gateway to the Internet. In my situation, we cross the Internet using SSL3.
And if the app isn't sensitive, why not treat it as if it is? Use https, ssh, or pptp to do your tunneling, and forget about it. Then those nasty admins won't ask you to help them protect you and your code.
Ah, so If I get the code for BackOrifice, modify it to make outgoing connections via HTTPS then you would have no problem if I managed to "deploy" it on your network?
This is exactly my point. Now that we have a "short-list" of acceptable ports to use in applications, all applications will use them.
Which meant that, in order to remain effective, firewalls will have to install application level filters, which (a) should be impossible as modern secure protocols are man-in-the-middle proof, (b) makes my life (as a writer of said applications) harder as I have to either co-operate with the firewall in some way, or fudge my protocol somehow to make it pass the application level filter applicable to some other more common application.
What happens if I write some new P2P application that your users would find useful or just plain fun - or perhaps its even dangerous and sends sensitive information outside your network:- Given some random tool your users download you don't know and can't know. Hell - are you sure that Netscape or IE isn't volunteering sensitive company information to the outside?
Now, do you "ban" the usage of this application? And how? (and why?).
Imagine that the application is question was actually useful, and your users would be more productive for it. Would you make a hole in the firewall at your users request to allow the app to work?
Or, imagine instead that the application is deemed dangerous as it keeps posting passwords in clear text to remote sites run by evil hackers. However the application does this by cleverly using ports that are currently open on your firewall allowing other mission critical services to function.
My assertion is that port filtering is a short term fix to a problem that is made worse by the _very_ existence of port filtering:- the problem is that you - the sysadmin - doesn't trust certain application programs. BackOrifice is not to be trusted. HTTP daemons can be trusted on locked down boxes. ICQ???.
Your assumption is there is a binding between an application and the ports it uses. This is false, and was false. And it becomes more false the more you try to leverage it under the guise of "security".
If you truly think outbound port filtering constitutes a valid form of security then you are no deserving of your "SysAdmin" title.
I have a straight client server app and can't figure out which ports I *should* be using for outgoing connections. Below or above 1024?
Personally my personal ideas right now are:
1. Port scan: Write the server to listen on *lots* of ports. The client software simply port scans the server the first time its run to see if anything is open.
2. use the https port first. proxies aren't allowed to look inside https packets as that would break the security. https (443 iirc) is thus (imho) more likely to be open than straight http.
Any admins that block outgoing connections on a per port basis should be dealt with with extreme prejudice.
When buying DVD players here the first thing you ask the salesman is if the player is multi-zoned. The answer is invariably yes.
I buy all my DVD's from Amazon because they have a much wider range than any of the local stores and I can get the movies I want much sooner (in many cases before they hit the local circuit). My DVD player is hacked to report its region 1 to get past those icky disks from universal.
The correct way to release DeCSS would have been in a self extracting archive with shrinkwrap license agreement.
"By clicking "OK" you agree not to hold the distributor of this software program liable for anything" type of thing. Even throw in a clause whereby the user agrees not to use the product for any number of "infringing" uses.
This protects - using another totally insane act of law - the UCITA -- the DeCSS distribution at a number of levels.
1. Representatives of the MPAA obviously opened the distribution and looked inside - thus agreeing not to sue based on the contents of the archive. If they didn't click ok and still have examined the contents it can only be becasue they bypassed the protection on the archive and thus have fallen foul of the DMCA itself.
2. The end users of the software too have enterd into (and been bound by) the contract not to use the software for infringing uses.
Done properly and worded right this would put the DMCA in conflict with UCITA. Hopefully one of them would give, and half our current problems would be over.
WARNING: Caffine levels low. Output may be incoherent.
* If DeCSS was made for Linux DVD players, then why was the compiled Windows port made and released?
Because DeCSS was written in C, and well written C code is (should be) platform neutral.
Binaries are provided as a convenience - everyone knows how to (and could) compile the code for any number of disparate platforms. Right?:)
* DeCSS's intended purpose was for a DVD player for Linux. This is an honorable and difficult thing to do and is protected by law. Releasing the compiled Win32 version does not help the Linux DVD project at all. Not only that, but...
We are open source. We belive distribution of effort is more efficient. With DeCSS in hand we must give it the widest possible distrubution so interested developers can gain exposure to it and begin making more advanced tools around it.
*...anybody linking to the compiled version isn't following the intended purpose either, as stated in the case.
The Judge himself points out that the line between "source" and "object" code is fuzzy. I don't think its defined in law and I for one don't see a meaningfull distinction at all.
* And finally, our elected officials in Congress passed the DMCA to "protect" everybody, including the MPAA.
Congress passes laws to protect Americans and American Companies. As much as I might like to be an American I am not, and over here (as far as DVD's are concerned) we have the really short end of the stick. Some DVD's are not available in "region 2" and many DVD's (including "The Matrix") are feature impaired compared to their region 1 counterparts. I do not feel anything but violated by the DMCA and CSS and the MPAA.
No. As I read it (and I admit I may be quite wrong) they are saying the engine cannot be sold independently of the car.
And computers (unlike cars and their OEM engines) can be purchased sans OS.
Which is something I insist on doing - this discussion notwithstanding Microsoft have now required OEM producers to physically "lock" distributed OEM "engines" to the computer models they ship in.
This clearly bites. What the EULA giveth... what the EULA doeth not taketh away explicitly, the OEM agreement taketh away.
Harris' list might be an OPT-IN list but its not structured as a "double opt in" which MAPS require. Without a double opt in mechanism it is too easy for unscrupulous individuals to fake opt-ins on behalf of third parties who actually do not want to opt in.
Without a double opt-in I could go to the Harris web site and fill in the opt-in form with "lk@caralis.com". Assuming that email is legit:) it has been added to the Harris database as an "opt-in" subscriber and will receive the full amount of traffic sent.
Ok. Gnutella seems involved...somehow.
Filtering of ShareZilla seems to be crucial to the story too.
This has what to do with advertizing (or porn)?
This article severely lacks any form of the instant gratification I, as a 21st century consumer, have come to expect.
Am I (that is "we" - the slashdot readers) expected to reverse engineer the story oursleves?
The verance watermark (watermarks in general) is implemented as an inaudible signal.
mpeg audio compression works by using a psychoacoustic model to strip inaudible signals from a sound recording.
These two technologies appear to be at odds. If mp3-compression works it will strip the watermark as being inaudible. OTOH If the watermark works the resulting file will be larger than the unwatermarked equilavent sounding mp3 as it contains inaudible signals that should have been stripped.
In the worst case the watermark "works" because the psychoacoustic model fails to identify it as non-audible. In that case - either the psychoacoustic model can do with some improvement... or it is correct and the watermark is audible.
My thought is that while a watermark is resistent to traditional "dumb" noise reduction filters it cannot withstand a good psycho-acoustic encoder - by definition either technology is flawed if the other works correctly.
Because - quite frankly, Win32 on NT is implemented the same way WINE is on UNIX.
Win32 is NOT NT's native API - The Win32 API that most ms-windows programmers know and love is implemented as a subsystem on quite a different lower level type SPI interface. POSIX and OS/2 *were* two other subsystems that wrapped the NT native API.
WINE and NT's Win32 are similar even in that both have native API service applications that manage the mapping of Win32 handles to native handles. In NT's case the process is csrss.exe.
(If you followed all the ballyhoo about NT4, when it was released, being potentially so much more unstable than the previous versions due to the move of code from user to kernel mode - it was code being moved from csrss.exe into win32k.sys - a native/kernel mode driver).
NT then (insomuch as its architecture is documented or can be reverse engineered) acts as an example of how to implement Win32 API's on a system that is not nativly Win32.
I would argue though that WINE *is* and emulator - because it tries to run NT and 95 binaries (like Office) and is thus forced to emulate a number of bugs *ahem* features in Microsofts own implementation.
My biggest problem with these new products is not that they will prevent Napster or Gnutella or RealAudio from functioning.
Quite the converse. My fear is that file sharing, media streaming, bandwidth hogging applications will not be stopped. The developers of these applications are under no obligation to stick to their current easy to recognise ports and protocols.
This is a treand that has already begun thanks to mis-configured firewalls. I maintain the code for a tcp based client/server communication protocol used by my companies products. When choosing port numbers for the servers I cannot choose whether to use ports between 0 and 1023 or 1024 and up based on any criteria more rational than "how much chance does this port have of successfully negotiating any firewalls between the client and the server?".
I am under a lot of pressure to simply throw in the towel and recast the entire protocol as HTML over HTTP so it can at least escape networks that have a proxy. My boss unfortunately has heard of XML - I can see the end comming.
In the long run it seems that all protocols will converge to running over port 80 looking enough like HTML that these so called smart filtering firewalls can't tell the difference.
And that will be the bad thing. Every grey featureless protocol looking like every other grey featureless protocol. Bloated with loads of headers all telling lies. A great loss to the richness that the internet once was or could have been.
I still imagine a world where many different protocols exist, each suited to its task. Sadly this seems to be becomming more and more of a pipe dream.
Slashdot Mirror
A flywheel is an energy storage device - the faster it spins the more enengy it has the moer massive becomes.
If you slowed the flywheel down you would bleed the energy off into another storage device - that would become more massive proportional to the energy stored.
e=mcc works both ways. For a given quantity of stored energy you can calculate how much mass it is adding to the rest mass of its container.
--
We could look at a field of what we see as solid color - the tetrachromat could distinguish between different colors that we see as the same.
Therefore they see colors we can't (distinguish from, say a greenish red :)
--
Damn P2P - I am tasked with making a client2server setup as smooth as possible for the end users.
So, where is this document that tells me in a generic way how to cooperate with some BOFH blanket filter on outgoing ports?
Really - I want to use a unique port number for my service - to be friendly to sysadmins who might like their logs of port numbers to be meaningfull. But - I can't. Invariably some idiot on a powertrip has blanket banned a range (i.e. everything) that contains my port selection.
My only way out of this hole (in terms of getting software to the end user that workd) is to port whore, and port whoring is going to become a massive problem if outgoing port filtering persists. I'll do it for one, and I'm sure many other developers will join the bandwagon too - Unless there is a book/URL someplace that tells me and other developers who to cooperate with, rather than evade, a firewall.
Im listening.
--
I am saying I dislike you and your kind. I mean that in the nicest possible way of course: my intention is not to be rude or flame - I have just been pissed off past my ability to endure by admins that, in my mind, are not thinking clearly (or have their hands tied by (even more) incompetent management.
I block large ranges of ports on a regular basis, because there's no business for *any* external traffic to come into my LAN.
"*any*"? Just one line later you contradict this statement yourself and allow for incoming connections in certain situations.
Also, I assume you meant connections not traffic, surely the tightly controlled users on your LAN are allowed to retrieve the results of their web browsing.
HTTP, HTTPS, FTP, and a limited few others get inbound permissions to specific servers (On a different extranet subnet) that are hardened for those specific tasks.
How to be polite. hmmm. Oh to be one of the dirty unwashed untrusted masses an your LAN. I used to hate it when reporters on TV and in magazines would confuse the "Internet" with the "World Wide Web" but I see that WWW access is all some are given.
And if you think that security should *only* be on inbound traffic, you've obviously never seen a coworker led off in handcuffs after attempting to (illegally) hack another companies servers and leave his company to blame while he skips town.
Some random thoughts: :- Finally, once everything is done via port 80, how exactly are you going to get any meaningful filtering done at all?
1. If a company can't trust their own employees who can they trust?
2. This point is invalid because you have shot yourself in the foot anyway: Excessive port filtering makes programmers & hackers choose specific ports used by legitimate applications
3. Does the company also have metal detectors on the doors and are all the papers and disks the employees leave the building with checked?
If your App has both the server and clients inside the firewall, no problem.
That's not exactly now the "Internet" with a capital I now is it. Its a LAN application that happens to use TCP/IP as a protocol.
If your client-server application is sensitive, and it crosses the internet, you should be using a VPN tunnel or SSH to cross the firewall in the first place, instead of sending passwords in the clear! The Internet - capital I. An internet (small I) is any network of tcp/ip hosts that may or may not be connected via gateway to the Internet. In my situation, we cross the Internet using SSL3.
And if the app isn't sensitive, why not treat it as if it is? Use https, ssh, or pptp to do your tunneling, and forget about it. Then those nasty admins won't ask you to help them protect you and your code.
Ah, so If I get the code for BackOrifice, modify it to make outgoing connections via HTTPS then you would have no problem if I managed to "deploy" it on your network?
This is exactly my point. Now that we have a "short-list" of acceptable ports to use in applications, all applications will use them.
Which meant that, in order to remain effective, firewalls will have to install application level filters, which (a) should be impossible as modern secure protocols are man-in-the-middle proof, (b) makes my life (as a writer of said applications) harder as I have to either co-operate with the firewall in some way, or fudge my protocol somehow to make it pass the application level filter applicable to some other more common application.
What happens if I write some new P2P application that your users would find useful or just plain fun - or perhaps its even dangerous and sends sensitive information outside your network:- Given some random tool your users download you don't know and can't know. Hell - are you sure that Netscape or IE isn't volunteering sensitive company information to the outside?
Now, do you "ban" the usage of this application? And how? (and why?).
Imagine that the application is question was actually useful, and your users would be more productive for it. Would you make a hole in the firewall at your users request to allow the app to work?
Or, imagine instead that the application is deemed dangerous as it keeps posting passwords in clear text to remote sites run by evil hackers. However the application does this by cleverly using ports that are currently open on your firewall allowing other mission critical services to function.
My assertion is that port filtering is a short term fix to a problem that is made worse by the _very_ existence of port filtering :- the problem is that you - the sysadmin - doesn't trust certain application programs. BackOrifice is not to be trusted. HTTP daemons can be trusted on locked down boxes. ICQ???.
Your assumption is there is a binding between an application and the ports it uses. This is false, and was false. And it becomes more false the more you try to leverage it under the guise of "security".
If you truly think outbound port filtering constitutes a valid form of security then you are no deserving of your "SysAdmin" title.
--
I have a straight client server app and can't figure out which ports I *should* be using for outgoing connections. Below or above 1024?
Personally my personal ideas right now are:
1. Port scan: Write the server to listen on *lots* of ports. The client software simply port scans the server the first time its run to see if anything is open.
2. use the https port first. proxies aren't allowed to look inside https packets as that would break the security. https (443 iirc) is thus (imho) more likely to be open than straight http.
Any admins that block outgoing connections on a per port basis should be dealt with with extreme prejudice.
--
When buying DVD players here the first thing you ask the salesman is if the player is multi-zoned. The answer is invariably yes.
I buy all my DVD's from Amazon because they have a much wider range than any of the local stores and I can get the movies I want much sooner (in many cases before they hit the local circuit). My DVD player is hacked to report its region 1 to get past those icky disks from universal.
--
Also imagine how empty our lives would be if we never saw another advert for a product that mysteriously requires wings?
--
Who is going to firewall Napster on our very PC's? Sony.
Who is a member of both the MPAA and RIAA? Sony.
Sorry if I care very little for Sony and anything related.
--
--
"By clicking "OK" you agree not to hold the distributor of this software program liable for anything" type of thing. Even throw in a clause whereby the user agrees not to use the product for any number of "infringing" uses.
This protects - using another totally insane act of law - the UCITA -- the DeCSS distribution at a number of levels.
1. Representatives of the MPAA obviously opened the distribution and looked inside - thus agreeing not to sue based on the contents of the archive. If they didn't click ok and still have examined the contents it can only be becasue they bypassed the protection on the archive and thus have fallen foul of the DMCA itself.
2. The end users of the software too have enterd into (and been bound by) the contract not to use the software for infringing uses.
Done properly and worded right this would put the DMCA in conflict with UCITA. Hopefully one of them would give, and half our current problems would be over.
WARNING: Caffine levels low. Output may be incoherent.
I don't use Napster. But, as much as I dislike Napsters implementation of the peer-to-peer file sharing concept I do not belive Napster is wrong.
Napster is merely terribly efficient at a task that can be done dozens of other ways (i.e. sharing files).
Note that I will say that I don't use Napster.
The security aspect of allowing non-open file sharing code to run on my system fills me with the horrors.
Because DeCSS was written in C, and well written C code is (should be) platform neutral.
Binaries are provided as a convenience - everyone knows how to (and could) compile the code for any number of disparate platforms. Right? :)
* DeCSS's intended purpose was for a DVD player for Linux. This is an honorable and difficult thing to do and is protected by law. Releasing the compiled Win32 version does not help the Linux DVD project at all. Not only that, but...
We are open source. We belive distribution of effort is more efficient. With DeCSS in hand we must give it the widest possible distrubution so interested developers can gain exposure to it and begin making more advanced tools around it.
* ...anybody linking to the compiled version isn't following the intended purpose either, as stated in the case.
The Judge himself points out that the line between "source" and "object" code is fuzzy. I don't think its defined in law and I for one don't see a meaningfull distinction at all.
* And finally, our elected officials in Congress passed the DMCA to "protect" everybody, including the MPAA.
Congress passes laws to protect Americans and American Companies. As much as I might like to be an American I am not, and over here (as far as DVD's are concerned) we have the really short end of the stick. Some DVD's are not available in "region 2" and many DVD's (including "The Matrix") are feature impaired compared to their region 1 counterparts. I do not feel anything but violated by the DMCA and CSS and the MPAA.
And computers (unlike cars and their OEM engines) can be purchased sans OS.
Which is something I insist on doing - this discussion notwithstanding Microsoft have now required OEM producers to physically "lock" distributed OEM "engines" to the computer models they ship in.
This clearly bites. What the EULA giveth ... what the EULA doeth not taketh away explicitly, the OEM agreement taketh away.
Without a double opt-in I could go to the Harris web site and fill in the opt-in form with "lk@caralis.com". Assuming that email is legit :) it has been added to the Harris database as an "opt-in" subscriber and will receive the full amount of traffic sent.
Filtering of ShareZilla seems to be crucial to the story too.
This has what to do with advertizing (or porn)?
This article severely lacks any form of the instant gratification I, as a 21st century consumer, have come to expect. Am I (that is "we" - the slashdot readers) expected to reverse engineer the story oursleves?
mpeg audio compression works by using a psychoacoustic model to strip inaudible signals from a sound recording.
These two technologies appear to be at odds. If mp3-compression works it will strip the watermark as being inaudible. OTOH If the watermark works the resulting file will be larger than the unwatermarked equilavent sounding mp3 as it contains inaudible signals that should have been stripped.
In the worst case the watermark "works" because the psychoacoustic model fails to identify it as non-audible. In that case - either the psychoacoustic model can do with some improvement... or it is correct and the watermark is audible.
My thought is that while a watermark is resistent to traditional "dumb" noise reduction filters it cannot withstand a good psycho-acoustic encoder - by definition either technology is flawed if the other works correctly.
Win32 is NOT NT's native API - The Win32 API that most ms-windows programmers know and love is implemented as a subsystem on quite a different lower level type SPI interface. POSIX and OS/2 *were* two other subsystems that wrapped the NT native API.
WINE and NT's Win32 are similar even in that both have native API service applications that manage the mapping of Win32 handles to native handles. In NT's case the process is csrss.exe.
(If you followed all the ballyhoo about NT4, when it was released, being potentially so much more unstable than the previous versions due to the move of code from user to kernel mode - it was code being moved from csrss.exe into win32k.sys - a native/kernel mode driver).
NT then (insomuch as its architecture is documented or can be reverse engineered) acts as an example of how to implement Win32 API's on a system that is not nativly Win32.
I would argue though that WINE *is* and emulator - because it tries to run NT and 95 binaries (like Office) and is thus forced to emulate a number of bugs *ahem* features in Microsofts own implementation.
Quite the converse. My fear is that file sharing, media streaming, bandwidth hogging applications will not be stopped. The developers of these applications are under no obligation to stick to their current easy to recognise ports and protocols.
This is a treand that has already begun thanks to mis-configured firewalls. I maintain the code for a tcp based client/server communication protocol used by my companies products. When choosing port numbers for the servers I cannot choose whether to use ports between 0 and 1023 or 1024 and up based on any criteria more rational than "how much chance does this port have of successfully negotiating any firewalls between the client and the server?".
I am under a lot of pressure to simply throw in the towel and recast the entire protocol as HTML over HTTP so it can at least escape networks that have a proxy. My boss unfortunately has heard of XML - I can see the end comming.
In the long run it seems that all protocols will converge to running over port 80 looking enough like HTML that these so called smart filtering firewalls can't tell the difference.
And that will be the bad thing. Every grey featureless protocol looking like every other grey featureless protocol. Bloated with loads of headers all telling lies. A great loss to the richness that the internet once was or could have been.
I still imagine a world where many different protocols exist, each suited to its task. Sadly this seems to be becomming more and more of a pipe dream.
As far as I know at least, CORBA is the competition to DCOM, now COM+.
Not having used either technology I can't say for sure...
The official CORBA FAQ has a feature list that is similar to COM+ in key areas:
http://sisyphus.omg.org/getting started/corbafaq.htm
Yes I develop for Windows. I enjoy it too.