> reject the connection if the IP address of the > connection doesn't match one of the listed MXes > for the domain
Wrong assumption: incoming SMTP server = outgoing SMTP server. Many large and small organizations use different machines to recieve and send mail via SMTP. In other words, you'll end up rejecting a huge (50-80?) percentage of legitimate mail.
This is exactly the key point and the problem. DRM is not acceptable. We must make sure that it doesn't become necessary for things we want to do. Anything that makes DRM more acceptable to the masses is thus a bad thing.
Mine. I run my own mailserver on a dialup line, and I get blocked.
I have good reasons to run my own mail server (privacy etc.), that's why MAPS DUL sucks.
You can always *refer* to something using the trademarked game. All the trademark prevents is you calling a *similar* thing (not from the company owning the trademark) with that trademarked name.
"Ford Explorer" is most likely trademarked. Of course I can call Ford Explorers that way. I may not sell my own car under the name "Ford Explorer".
Um, so, if CVS runs as user "cvs", which can write your source. Have fun to verify that nobody installed an exploit in your software
Yes, running as user prevents from the CVS binary itself being comprimised, which would allow same nasty tricks to hide exploits. But maybe you can achieve almost the same with smart, unusual rcs files.
But otherwise, your source is probably the most valueable asset on that machine (you're not running the company database on the same machine, are you?), so write access to the source *is* severe.
Just create a source tarball for each release and store it offsite. Then you can at any time check out the old sources from CVS and compare them with your tarball. Then you can compare the source tarball of this release with the one from the last one, ideally read that diff manually for bugs, and make a cvs diff, which you compare with the diff of the tarballs you made.
> If you just want to keep packet sniffing from being effective, self sign it.
This may work, if you routinely work with the same peers. It does not work, if you routinely communicate with unknown peers. For example, if my mail server had a self-signed cert, and another mail server sends me mail without ever before having done so, how can it know that the contacted server (supposedly mine) is really my server and no man-in-the-middle attack is taking place? DNS is *not* failure-proof.
Encryption doesn't make sense, if you can't be sure that you're talking to the right person.
Oh, BTW: That's also one (the?) big weakness of SSL: The US government probably controls VeriSign, meaning they can get technically valid, but faked certs, and maybe able to run man-in-the-middle attacks. This is way harder with the web of trust of GPG. (But you can have SSL-style CAs for PGP, as Thawte demonstrated.)
> GPG/PGP keys are always self-signed
And should be signed by others who verified your identity. Look up "web of trust".
VKB Inc
IP
Lieberman is reluctant to reveal how VKB achieved this result as the company has a patent pending on the technology, but he says "all we can say is that we know where your hands are
uh, oh. /me quickly pulls the hand out of the pants.
Not my impression, for hardware in general and esp. for mainboards. I had maybe 10 problems this year (some of them with parts baught earlier), probably more than in the 10 years before.
Because I replace my processor every 6-12 months, and I usually have to buy a new motherboard as well then (socket changes, FSB changes, RAM type changes, whatever).
And then I have to buy new HDD controller, FDD, keyboard, mouse, parallel, serial, USB, Firewire, health, whatnot controllers and connectors as well. Basically the whole southbridge and all the connectors at the back, which I bet are together 50% of the mainboard cost, don't need replacement, but I have have to replace them, because they are hardwired to the old board.
Why not break motherboards in 2-3 parts? - A backplane with PCI and AGB slots - (plus maybe) CPU socket, northbridge and RAM sockets - southbridge with all this clutter and connectors etc.
Frankly, it makes more sense to save the CPU socket (significant cost, I guess) and to solder the CPU to the mainboard than to hardwire the southbridge to the northbridge, at least when I look at my buying pattern.
Apart from saving me a lot of money (as described above), it would give a lot more choice. Mainboard manufacturers wouldn't have to make a P3 board with audio and without, with video and without, with RAID and without, for SDRAM and DDR, same for P4 and Athlon and soon Hammer. The northbridge would be dependant on the processor and RAM type, and the southbridge would offer the gimmecks, and any southbridge could be combined with any northbridge.
I, for example, would like to have an athlon or hammer, without legacy crap like parallel, serial, PS/2, FDD etc.. Just USB and maybe Firewire, health control, maybe a HDD controller, nothing else. If I am building a server, I wouldn't even need Firewire, but would like a cheap video card built in (console only), but no audio needed. And nothing from VIA please, I have been burned *way* too much by the KT133A. Now, try to find me a mainboard, stable and reasonably cheap, with my specs. I would totally expect to be able to relatively easily build such a computer, if most mainboards had north- and southbridge separated.
And the north/south cross-vendor connection standard is simple: PCI (in a modern/fast variation, if needed). Not long ago, even VIA's own north- and southbridges communicated technically via PCI, so it's definitely possible.
The only problem is physical: The ATX standard (case holes, screws etc.) assumes that the connection crap is on the mainboard. And the willingness of mainboard manufacturers to build such parts.
Yes, but apart from being incredibly impractical and other downsides, the EU plans ID-chips for Euro bank notes. Starting 2005 (if it goes well for them). Only for 200 Euro ($200$) and up at first, because of costs, but costs drop, of course.
Would anyone please bother to actually check the vulnerabilities page and compare it with the Register article, before posting this on a news site? Most of the bugs *are* listed on the vulnerabilities page. IIRC, *all* of the bugs are freely accessible in bugzilla.
What's more, they are *fixed*. Long ago. Beonex Communicator 0.8.1, released 1.5 months ago, is not vulnerable to *any* of these bugs (not even that referrer bug, at least not in the default config).
You assume they'll care. I don't think they'll do. This is a plot.
And I don't think copyright is their primary concern. Their business is not based on copyright, that's owned by the artists. Their business is based on control. DRM systems like WMA give them more control than they could dream of 10 years ago.
Most webmail providers now have SSL access, not? If your employer snoops on that, it's hacking and it's most likely illegal. If your webmail provider doesn't offer SSL, then switch. If your employer blocks webmail providers, ask your boss to open it. If he doesn't do it, bad luck.
> Yes, it's really hard indeed (N-O-T). > './setup -net' as root, click 'next' a > few times, then run $INSTALLDIR/setup > as the user that wants to use Openoffice
Hahaha. That's not how it works under Unix. I install it as any user I like (which is certainly *not* root), in any location I like, and then start the executable as the user using the app (which is different from the user owning the installation).
I tried to do that, and wasted lots of hours until it worked. Because OpenOffice didn't give me error msgs, when it didn't like something - it just crashed.
The setup path you describe might work for you, but I will not run such software as root. Almost any other Unix software can deal with that.
> Except in this case you are the only one around > here that claims to have severe problems all > the time
Wrong. Most people I spoke of said that the installation of OpenOffice under Unix is a catastrophe.
> I don't think Openoffice.org belongs in the > category that 'falls apart at the slightest > nudge'
But that's exactly my experience. I don't want to disminish the work of the people, because I used it only for a few minutes (successfully), but within that time, it crashed several times (IIRC).
No, because Redhat is not allowed to distribute without accepting the license. Which disclaims the liability. I don't think a click-wrap help to protect the developer from Redhat:).
Now, if Redhat sells the software, I do think that they should be liable just as much as Microsoft is, unless the customer understands that there is no such liability (and the customer ideally has a reasonable choicie to get such liability).
I just think that click-wrap licenses help with that "understanding" part, mostly because they are simply too long.
> It's not the case, and they are indeed terrible.
Not in Germany, to my knowledge. Here, there are explicitly different rules for non-commerical (defined as free of cost, IIRC) software wrt. warranties.
Sorry to flame, but such general statements, which a lot of people make, always give the impression that the American broken laws were generally true. They are of course, not. Other countries, other laws.
And I think that this is important to consider for licenses.
From "Why freedb?": "One programmer told me, that his cd-player will be banned if he is refusing to display the CDDB-logo. His software is a console-based program [...] for blind people..."
Slashdot Mirror
> reject the connection if the IP address of the
> connection doesn't match one of the listed MXes
> for the domain
Wrong assumption: incoming SMTP server = outgoing SMTP server. Many large and small organizations use different machines to recieve and send mail via SMTP. In other words, you'll end up rejecting a huge (50-80?) percentage of legitimate mail.
> If DRM becomes mandated
This is exactly the key point and the problem. DRM is not acceptable. We must make sure that it doesn't become necessary for things we want to do. Anything that makes DRM more acceptable to the masses is thus a bad thing.
> a) What is the same as "the developers must do my bidding"?
Employing a developer
> b) What is the phrase or action that will get the
> developers to actually do my bidding?
Here you have $$$, do this.
> Those are the kind of users who usually don't
:-(
> report bugs in Bugzilla. They complain on
> messageboards.
Sometimes, bugzilla seems to be understood as message board
That's extortion. There is no technical reason to block Telia's central mail server to block the customer's machines.
Mine. I run my own mailserver on a dialup line, and I get blocked. I have good reasons to run my own mail server (privacy etc.), that's why MAPS DUL sucks.
You can always *refer* to something using the trademarked game. All the trademark prevents is you calling a *similar* thing (not from the company owning the trademark) with that trademarked name.
"Ford Explorer" is most likely trademarked. Of course I can call Ford Explorers that way. I may not sell my own car under the name "Ford Explorer".
Is that the political correct term for Superbowl, to not offend fans of other sports?
Yeah, but nobody else does.
Um, so, if CVS runs as user "cvs", which can write your source. Have fun to verify that nobody installed an exploit in your software
Yes, running as user prevents from the CVS binary itself being comprimised, which would allow same nasty tricks to hide exploits. But maybe you can achieve almost the same with smart, unusual rcs files.
But otherwise, your source is probably the most valueable asset on that machine (you're not running the company database on the same machine, are you?), so write access to the source *is* severe.
Just create a source tarball for each release and store it offsite. Then you can at any time check out the old sources from CVS and compare them with your tarball. Then you can compare the source tarball of this release with the one from the last one, ideally read that diff manually for bugs, and make a cvs diff, which you compare with the diff of the tarballs you made.
You can do that at any interval you choose.
> If you just want to keep packet sniffing from being effective, self sign it.
This may work, if you routinely work with the same peers. It does not work, if you routinely communicate with unknown peers. For example, if my mail server had a self-signed cert, and another mail server sends me mail without ever before having done so, how can it know that the contacted server (supposedly mine) is really my server and no man-in-the-middle attack is taking place? DNS is *not* failure-proof.
Encryption doesn't make sense, if you can't be sure that you're talking to the right person.
Oh, BTW: That's also one (the?) big weakness of SSL: The US government probably controls VeriSign, meaning they can get technically valid, but faked certs, and maybe able to run man-in-the-middle attacks. This is way harder with the web of trust of GPG. (But you can have SSL-style CAs for PGP, as Thawte demonstrated.)
> GPG/PGP keys are always self-signed
And should be signed by others who verified your identity. Look up "web of trust".
uh, oh.
/me quickly pulls the hand out of the pants.
OK, I admit it, I saw "Blue Streak" yesterday.
> I have found that the quality of mobos
Not my impression, for hardware in general and esp. for mainboards. I had maybe 10 problems this year (some of them with parts baught earlier), probably more than in the 10 years before.
Why? Simple.
Because I replace my processor every 6-12 months, and I usually have to buy a new motherboard as well then (socket changes, FSB changes, RAM type changes, whatever).
And then I have to buy new HDD controller, FDD, keyboard, mouse, parallel, serial, USB, Firewire, health, whatnot controllers and connectors as well. Basically the whole southbridge and all the connectors at the back, which I bet are together 50% of the mainboard cost, don't need replacement, but I have have to replace them, because they are hardwired to the old board.
Why not break motherboards in 2-3 parts?
- A backplane with PCI and AGB slots
- (plus maybe) CPU socket, northbridge and RAM sockets
- southbridge with all this clutter and connectors etc.
Frankly, it makes more sense to save the CPU socket (significant cost, I guess) and to solder the CPU to the mainboard than to hardwire the southbridge to the northbridge, at least when I look at my buying pattern.
Apart from saving me a lot of money (as described above), it would give a lot more choice. Mainboard manufacturers wouldn't have to make a P3 board with audio and without, with video and without, with RAID and without, for SDRAM and DDR, same for P4 and Athlon and soon Hammer. The northbridge would be dependant on the processor and RAM type, and the southbridge would offer the gimmecks, and any southbridge could be combined with any northbridge.
I, for example, would like to have an athlon or hammer, without legacy crap like parallel, serial, PS/2, FDD etc.. Just USB and maybe Firewire, health control, maybe a HDD controller, nothing else. If I am building a server, I wouldn't even need Firewire, but would like a cheap video card built in (console only), but no audio needed. And nothing from VIA please, I have been burned *way* too much by the KT133A.
Now, try to find me a mainboard, stable and reasonably cheap, with my specs. I would totally expect to be able to relatively easily build such a computer, if most mainboards had north- and southbridge separated.
And the north/south cross-vendor connection standard is simple: PCI (in a modern/fast variation, if needed). Not long ago, even VIA's own north- and southbridges communicated technically via PCI, so it's definitely possible.
The only problem is physical: The ATX standard (case holes, screws etc.) assumes that the connection crap is on the mainboard.
And the willingness of mainboard manufacturers to build such parts.
> Any smarter and faster (Stasi, KGB, Gestapo)
Frankly, Stasi and Gestapo couldn't even dream about what Poindexter is building there.
Yes, but apart from being incredibly impractical and other downsides, the EU plans ID-chips for Euro bank notes. Starting 2005 (if it goes well for them). Only for 200 Euro ($200$) and up at first, because of costs, but costs drop, of course.
Bye-bye anonymous shopping.
Would anyone please bother to actually check the vulnerabilities page and compare it with the Register article, before posting this on a news site? Most of the bugs *are* listed on the vulnerabilities page. IIRC, *all* of the bugs are freely accessible in bugzilla.
What's more, they are *fixed*. Long ago. Beonex Communicator 0.8.1, released 1.5 months ago, is not vulnerable to *any* of these bugs (not even that referrer bug, at least not in the default config).
You assume they'll care. I don't think they'll do. This is a plot.
And I don't think copyright is their primary concern. Their business is not based on copyright, that's owned by the artists. Their business is based on control. DRM systems like WMA give them more control than they could dream of 10 years ago.
Most webmail providers now have SSL access, not? If your employer snoops on that, it's hacking and it's most likely illegal. If your webmail provider doesn't offer SSL, then switch. If your employer blocks webmail providers, ask your boss to open it. If he doesn't do it, bad luck.
> Yes, it's really hard indeed (N-O-T).
> './setup -net' as root, click 'next' a
> few times, then run $INSTALLDIR/setup
> as the user that wants to use Openoffice
Hahaha. That's not how it works under Unix. I install it as any user I like (which is certainly *not* root), in any location I like, and then start the executable as the user using the app (which is different from the user owning the installation).
I tried to do that, and wasted lots of hours until it worked. Because OpenOffice didn't give me error msgs, when it didn't like something - it just crashed.
The setup path you describe might work for you, but I will not run such software as root. Almost any other Unix software can deal with that.
> Except in this case you are the only one around
> here that claims to have severe problems all
> the time
Wrong. Most people I spoke of said that the installation of OpenOffice under Unix is a catastrophe.
> I don't think Openoffice.org belongs in the
> category that 'falls apart at the slightest
> nudge'
But that's exactly my experience. I don't want to disminish the work of the people, because I used it only for a few minutes (successfully), but within that time, it crashed several times (IIRC).
> I just think that
eh, I just *do not* think that....
(Sorry. Note to self: Use Preview.)
No, because Redhat is not allowed to distribute without accepting the license. Which disclaims the liability. I don't think a click-wrap help to protect the developer from Redhat :).
Now, if Redhat sells the software, I do think that they should be liable just as much as Microsoft is, unless the customer understands that there is no such liability (and the customer ideally has a reasonable choicie to get such liability).
I just think that click-wrap licenses help with that "understanding" part, mostly because they are simply too long.
> It's not the case, and they are indeed terrible.
Not in Germany, to my knowledge. Here, there are explicitly different rules for non-commerical (defined as free of cost, IIRC) software wrt. warranties.
Sorry to flame, but such general statements, which a lot of people make, always give the impression that the American broken laws were generally true. They are of course, not. Other countries, other laws.
And I think that this is important to consider for licenses.
IANAL.
In the sense of Gracenote/CDDB...
From "Why freedb?": "One programmer told me, that his cd-player will be banned if he is refusing to display the CDDB-logo. His software is a console-based program [...] for blind people..."