Isn't it obvious that the best benefit of using something like Gnutella is the possibility of setting up "private" Gnutella nets?
Sharing with the whole world is always a problem. If you've got something everyone wants, they will always beat a path to your doorstep... with a number of friends in a "private" network, the grass might not all die as they cross your yard.
How 'bout convincing the local CompUSA or other computer store to get a fat pipe and hold "events"? Buy a pack of 10 CDRs and get the "hot off the presses" just out RH7.
Agreed. I was ready to start a reply saying the same. For that matter, if there were transparent caching all around, then there wouldn't be so damned much congestion at the peering points from the general populace doing the same things over and over again.
In thinking about the function of the watermarking, I've come to my own spooky realization.
What's the function? To prevent unauthorized duplication and distribution? How will they know who has what?
Are the players going to report back to centralized servers when a song gets played, giving an IP or other method to trace copyright violators?
Without some sort of reporting, the only other point of any of this, as I see it, would be limiting the content which is being distributed to the player which is downloading it.
Of course, that gets f'ed up as soon as the consumer does his monthly reinstall of Windows... so then John Q. Public has to re-buy?
If it were locked by whichever the originating registry was, then they'd have had to go through domain dispute procedures to get the domain, though.
-Nev
I used to work for Qwest. At that point, I think my dual OC-48 connected data center with 100Mbps switched to my desk would have qualified. Of course, I've changed jobs, and lost it.
ICANN should have a policy whereby a registrar *immediately* upon request to register a domain marks it as being in-process, effectively locking it for a short period (3-5 days?) such that another registrar can't swoop in and do it faster.
-Nev
I'd think that the second biggest mistake made in security is pride (the first being laziness).
If you think your machine is secure, you're just not paranoid enough. If you've got a user on your system, you've offered it up to be abused.
"appropriate filesystem permissions" is a nice concept. Even if initially done well, how does one know that they will stay correctly?
-Nev
How, exactly, do you expect them to get the drug interaction part into a standard DB? It'd seem to me to be the most important part of the database -- don't give someone a drug which will kill them. Even if they got data snapshot in CSV format, the updates could be rough.
Regular records, fine, but I'd think that if nothing else, legally, they'd have to cover their asses with a "real" drug interaction product.
That said, if there's a Windows product which can do it and can do ODBC or something like that, interfacing it with a standard records system would be fine.
Why must you have such contempt and assume intent?
How about the fact that it's easier to support things which are predictable? There's a hell of a lot more distros of Linux out there than there are flavors of Windows... Linux on their printserver is a known quantity. Linux on your workstation is not. libc compatibility, anyone?
First, let me say this: If a company expects me to be at work anything above and beyond what is recognized as a standard work week, they can fuck themselves if they don't want me using company resources to rearrange the rest of my life to suit them.
Back to company policies. The company for which I work has RFC1918 addresses for internal systems, NATted out through a firewall which only allows outbound on 80 and 443 for almost all systems.
Being non-stupid, I set up an SSH daemon on port 443 on an outside box and set up tunneling, but that's beside the point.
Point is that my company chose to place restrictions such that using external non-webmail accounts was impossible (well, for the 99% who tend to lack clue). MSIE is set up here by default to use their proxy, and settings on the workstations are locked down.
Were their choices better because they were diligent in limiting use?
Were they worse, because by not allowing SMTP, POP, SSH, telnet, and unproxied FTP, they encouraged the use of company applications and company servers, and not just company connectivity?
Since I can tunnel everything including web traffic (got me a proxy outside) they can't even see anything but one really long connection to a single host which comes up with nothing when they pop it after https://.
Reliability suffers, and my TCP/IP stack on this damned Windows box blows up too often with all the forwards, but have they won, have I, or neither?
If you're serving many entities who need SSL from one box, and allowing them shell access, then you're doing a disservice by letting any of them think their information is safe.
The actual nature of the problem is not "what SSL certificates are for," -- it's that the SSL is done at a lower level than the HTTP headers.
Verisign certificates are assigned to what they refer to as a Common Name. A Common Name is pretty much just an FQDN. (www.foo.bar)
The SSL session is begun before the hostname is known. The problem then becomes that the webserver has to know what certificate to present before it ascertains the hostname request from the client. If the Common Name in the certificate presented differs from the portion of the URL between the// and/, the user's browser pops up an error, as it should.
It can be done through either IP based virtual SSL hosts or name-based virtual SSL hosts on differing ports.
Laziness, the fact that too often people have no clue how to do a goddamned thing with that little box with the Cisco logo on it, or not knowing where to do handle the issue.
You know certain things about what's inside, and what's outside. Network addresses internal to your network should never be acceptable as a source address on packets coming into your external interface, and addresses which are external should not be accepted as sources on the internal interface of your router. Very simple.
If it were actually sniffing the network, then it wouldn't have required any software changes at the ISP. It's relatively obvious that the "scanning" is being done at the MTA level.
Even if it weren't, there's always mail spools to grep through.
You say that WebMail type things would be harder to monitor... no harder when you have access to the servers.
I like the fact that you seem to have covered many different areas where network traffic can be sniffed, but you seem to have forgotten that the asynchronous nature of e-mail usage means that there's a server somewhere in the middle.
Changing over to an ICQ-type "OK... I'm on... you can send it directly to me" method would help in alleviating the centralized storage issue, and if public-key encryption were incorporated with ICQ, then it'd be rougher for the FBI, though this would require that the sender be on 24/7 or risk not sending the e-mail.
Which brings us to another point. Subject lines and PGP.
Peeve: My Outlook/PGP combination leaves subject lines as plaintext. How is one supposed to both provide a useful reference and keep the gist of an e-mail secure with that?
Well, at the very least, it does bring to mind the question of what UNIX on the whole is to be.
Something that one must always think when looking at a comparison of any variant of UNIX to one of the Windows series is whether or not the boxes are compared fairly regarding what a box can and does do vs. the "opponent".
I often think, when wondering about these things, about how a box running Win2K, Exchange, IIS, and doing NT filesharing, maybe ProxyServer and some sort of NAT would do when compared to a Linux box with the same configuration doing sendmail, samba, Apache with proxy support, and ipchains would do.
Yeah... if we have RadHat Webserver, RedHat Workstation, RedHat BigDeal Workstation, and RedHat DataCenter, how much better off are we?
Are we better off?
Does making these sorts of differences a matter of loading kernel modules any better?
I think that perhaps, in the interests of performance on XYZ benchmark, we're losing sight of the thing that most of us love about UNIX. We tend to love the "pick the right tool for the job, be it sed, awk, shell, perl, C, python, or whatever you want" mentality, and here we are abandoning that universality for pure performance on a tit-for-tat basis.
We all know that given boxes to which we'd not have access for a month, that we'd rather have some sort of UNIX on running than WinXYZ, but must we give up the ghost to offer up something else? If you're a hacker trying to poof up a Windows beater, couldn't you hack something on QNX which would kick Windows's ass? Must we sacrifice more just to rub Microsoft's nose in something?
Just a thought from someone who dreams in 'NIX.
Re:Good idea, but if fails the legal test...
on
Pirate DNS?
·
· Score: 2
It depends on what microsoft.xxx does.
If it's a parody site or the like, your statements are not necessarily true.
When you say "MS has the right to the microsoft.xxx" domains, you're only partially correct.
Trademarks are not universally valid within even the context of locality.
Cincinatti Microwave used to make a radar detector called the Escort.
Ford made a car called the Escort at the same time.
(I'm drawing a blank on the countless other examples because it's way too hot in here)
So... which gets Escort.com?
Cincinatti Microwave had the exclusive right to use the name Escort in the course of commerce related to radar detectors. Whistler couldn't have introduced a radar detector called the Escort.
However, Ford wasn't selling radar detectors. They were selling cars. Chevrolet couldn't have started selling Escorts after Ford had established their trademark, related to automobiles.
Look up old articles on the chevychase.com domain name dispute to see some interesting discussion of this topic.
Slashdot Mirror
Isn't it obvious that the best benefit of using something like Gnutella is the possibility of setting up "private" Gnutella nets?
Sharing with the whole world is always a problem. If you've got something everyone wants, they will always beat a path to your doorstep... with a number of friends in a "private" network, the grass might not all die as they cross your yard.
-Nev
-Nev
To err is human, but to really fowl things up you require a politician.
No, politicians foul things up. All you need to fowl things up are a chicken and a blender.
-Nev
How 'bout convincing the local CompUSA or other computer store to get a fat pipe and hold "events"? Buy a pack of 10 CDRs and get the "hot off the presses" just out RH7.
-Nev
Agreed. I was ready to start a reply saying the same. For that matter, if there were transparent caching all around, then there wouldn't be so damned much congestion at the peering points from the general populace doing the same things over and over again.
-Nev
While there are still white people who would refuse a heart transplant from a black man, death scares most people more than technology.
-Nev
In thinking about the function of the watermarking, I've come to my own spooky realization.
What's the function? To prevent unauthorized duplication and distribution? How will they know who has what?
Are the players going to report back to centralized servers when a song gets played, giving an IP or other method to trace copyright violators?
Without some sort of reporting, the only other point of any of this, as I see it, would be limiting the content which is being distributed to the player which is downloading it.
Of course, that gets f'ed up as soon as the consumer does his monthly reinstall of Windows... so then John Q. Public has to re-buy?
I'm not sure which is scarier...
-Nev
If it were locked by whichever the originating registry was, then they'd have had to go through domain dispute procedures to get the domain, though. -Nev
I used to work for Qwest. At that point, I think my dual OC-48 connected data center with 100Mbps switched to my desk would have qualified. Of course, I've changed jobs, and lost it.
-Nev
ICANN should have a policy whereby a registrar *immediately* upon request to register a domain marks it as being in-process, effectively locking it for a short period (3-5 days?) such that another registrar can't swoop in and do it faster. -Nev
I'd think that the second biggest mistake made in security is pride (the first being laziness). If you think your machine is secure, you're just not paranoid enough. If you've got a user on your system, you've offered it up to be abused. "appropriate filesystem permissions" is a nice concept. Even if initially done well, how does one know that they will stay correctly? -Nev
How, exactly, do you expect them to get the drug interaction part into a standard DB? It'd seem to me to be the most important part of the database -- don't give someone a drug which will kill them. Even if they got data snapshot in CSV format, the updates could be rough.
Regular records, fine, but I'd think that if nothing else, legally, they'd have to cover their asses with a "real" drug interaction product.
That said, if there's a Windows product which can do it and can do ODBC or something like that, interfacing it with a standard records system would be fine.
-Nev
Why must you have such contempt and assume intent?
How about the fact that it's easier to support things which are predictable? There's a hell of a lot more distros of Linux out there than there are flavors of Windows... Linux on their printserver is a known quantity. Linux on your workstation is not. libc compatibility, anyone?
First, let me say this: If a company expects me to be at work anything above and beyond what is recognized as a standard work week, they can fuck themselves if they don't want me using company resources to rearrange the rest of my life to suit them.
Back to company policies. The company for which I work has RFC1918 addresses for internal systems, NATted out through a firewall which only allows outbound on 80 and 443 for almost all systems.
Being non-stupid, I set up an SSH daemon on port 443 on an outside box and set up tunneling, but that's beside the point.
Point is that my company chose to place restrictions such that using external non-webmail accounts was impossible (well, for the 99% who tend to lack clue). MSIE is set up here by default to use their proxy, and settings on the workstations are locked down.
Were their choices better because they were diligent in limiting use?
Were they worse, because by not allowing SMTP, POP, SSH, telnet, and unproxied FTP, they encouraged the use of company applications and company servers, and not just company connectivity?
Since I can tunnel everything including web traffic (got me a proxy outside) they can't even see anything but one really long connection to a single host which comes up with nothing when they pop it after https://.
Reliability suffers, and my TCP/IP stack on this damned Windows box blows up too often with all the forwards, but have they won, have I, or neither?
If you're serving many entities who need SSL from one box, and allowing them shell access, then you're doing a disservice by letting any of them think their information is safe.
-Nev
The actual nature of the problem is not "what SSL certificates are for," -- it's that the SSL is done at a lower level than the HTTP headers.
// and /, the user's browser pops up an error, as it should.
Verisign certificates are assigned to what they refer to as a Common Name. A Common Name is pretty much just an FQDN. (www.foo.bar)
The SSL session is begun before the hostname is known. The problem then becomes that the webserver has to know what certificate to present before it ascertains the hostname request from the client. If the Common Name in the certificate presented differs from the portion of the URL between the
It can be done through either IP based virtual SSL hosts or name-based virtual SSL hosts on differing ports.
-Nev
Laziness, the fact that too often people have no clue how to do a goddamned thing with that little box with the Cisco logo on it, or not knowing where to do handle the issue.
You know certain things about what's inside, and what's outside. Network addresses internal to your network should never be acceptable as a source address on packets coming into your external interface, and addresses which are external should not be accepted as sources on the internal interface of your router. Very simple.
Helps both you and the world.
Umm... if you're screaming for crypto coprocessors, then why don't you buy something like the nCipher nFast? PCI or external SCSI...
If it were actually sniffing the network, then it wouldn't have required any software changes at the ISP. It's relatively obvious that the "scanning" is being done at the MTA level.
Even if it weren't, there's always mail spools to grep through.
You say that WebMail type things would be harder to monitor... no harder when you have access to the servers.
I like the fact that you seem to have covered many different areas where network traffic can be sniffed, but you seem to have forgotten that the asynchronous nature of e-mail usage means that there's a server somewhere in the middle.
Changing over to an ICQ-type "OK... I'm on... you can send it directly to me" method would help in alleviating the centralized storage issue, and if public-key encryption were incorporated with ICQ, then it'd be rougher for the FBI, though this would require that the sender be on 24/7 or risk not sending the e-mail.
Which brings us to another point. Subject lines and PGP.
Peeve: My Outlook/PGP combination leaves subject lines as plaintext. How is one supposed to both provide a useful reference and keep the gist of an e-mail secure with that?
Argh.
Just my £0.02.
-NevDull
Interesting information...
carnivore.com is hosted at Earthlink.
carnivore.com brings you to the home page of a family of people born in "Palestine" and Libya.
Palestinians and Libyans and their communications are probably of interest to the FBI for various reasons.
Hmmmm...
Something which makes you go hmmmmmm... n'est-ce pas?
With a name like FreePascal, couldn't the "release" have waited until Bastille Day?
Now how long before desktop environments on Linux are integrated in a CDE-like fashion?
Splinter splinter merge merge.
/... == slashdot.dot ?
If software distribution licenses are all that we have to worry about, then maybe I should see about patenting SSH.
"When in the course of human events it becomes necessary..."
It's necessary.
USA% init 6
Well, at the very least, it does bring to mind the question of what UNIX on the whole is to be.
Something that one must always think when looking at a comparison of any variant of UNIX to one of the Windows series is whether or not the boxes are compared fairly regarding what a box can and does do vs. the "opponent".
I often think, when wondering about these things, about how a box running Win2K, Exchange, IIS, and doing NT filesharing, maybe ProxyServer and some sort of NAT would do when compared to a Linux box with the same configuration doing sendmail, samba, Apache with proxy support, and ipchains would do.
Yeah... if we have RadHat Webserver, RedHat Workstation, RedHat BigDeal Workstation, and RedHat DataCenter, how much better off are we?
Are we better off?
Does making these sorts of differences a matter of loading kernel modules any better?
I think that perhaps, in the interests of performance on XYZ benchmark, we're losing sight of the thing that most of us love about UNIX. We tend to love the "pick the right tool for the job, be it sed, awk, shell, perl, C, python, or whatever you want" mentality, and here we are abandoning that universality for pure performance on a tit-for-tat basis.
We all know that given boxes to which we'd not have access for a month, that we'd rather have some sort of UNIX on running than WinXYZ, but must we give up the ghost to offer up something else? If you're a hacker trying to poof up a Windows beater, couldn't you hack something on QNX which would kick Windows's ass? Must we sacrifice more just to rub Microsoft's nose in something?
Just a thought from someone who dreams in 'NIX.
It depends on what microsoft.xxx does.
If it's a parody site or the like, your statements are not necessarily true.
When you say "MS has the right to the microsoft.xxx" domains, you're only partially correct.
Trademarks are not universally valid within even the context of locality.
Cincinatti Microwave used to make a radar detector called the Escort.
Ford made a car called the Escort at the same time.
(I'm drawing a blank on the countless other examples because it's way too hot in here)
So... which gets Escort.com?
Cincinatti Microwave had the exclusive right to use the name Escort in the course of commerce related to radar detectors. Whistler couldn't have introduced a radar detector called the Escort.
However, Ford wasn't selling radar detectors. They were selling cars. Chevrolet couldn't have started selling Escorts after Ford had established their trademark, related to automobiles.
Look up old articles on the chevychase.com domain name dispute to see some interesting discussion of this topic.