about similar topics from an Australian perspective is Where's The Loot?. The author, Grant Butler, was a financial journalist during the boom and had the chance to see a fair number of companies in details. I strongly recommend it.
Mr Goundry seems to be ignoring the fact that UTF-8, which is for many purposes is the most useful representation of UNICODE characters, can compatibly and simply represent the full ISO-10646 character space of 2^31 characters, just by using more of the reserved prefix bits. I can't see what his objection is to this.
Plane zero (the first 65k characters) is supposed to be enough for most ordinary people speaking modern languages. The additional codeplanes exist to satisfy the valid needs of linguists studying archaic or obscure languages, and our author is welcome to use them.
65k characters seems like a reasonable limit for ordinary use: going beyond that is going to require a whole new level of complexity in font representation, character entry, and so on. Even being able to display all those characters only gets you halfway: you have to take into account ligature, composition, kerning and layout rules, and it's not at all clear many program authors will find this worthwhile for obscure dialects.
The elegance of UNICODE is that it offers a smooth migration path away from ASCII through UTF-8, captures a great majority of uses in plane zero, and can expand to handle more obscure cases.
You assume the tree is safe. In this case the tree is suspect.
No, the point of reading the diff is that it allows me to avoid assuming the tree is safe.
Let me explain it in smaller words: I have a checkout of the Apache source on my laptop, which I last updated a month or two ago. (This is not just an example, I really do.) If I get a new checkout of the tree, and run a recursive diff across the two directories, then I can see all the changes which were made to the head of the tree since I made my checkout. Most of these will be normal development changes that have happened in the intervening period, but if I see any suspicious binding of ports or launching of shells then we know something bad has happened.
Of course this is not just me. Many developers or spectators will have their own copies of the tree from various points in time. Covalent, IBM and distribution vendors will have their own internal mirrors of the tree. Since the intruders couldn't break all of these copies, any damage would likely be discovered.
The review process Brian explains in his mail is a systematic way of doing this. The chances that a change will slip through are pretty small.
I think you're misreading the letter. My interpretation is that it was the admin's ISP who had been owned for five months, not SourceForge.
MS can "prove" their code internally when hacked (back ups/ownership/check digits) and is liable if they produce rooted code.
That's classic Microsoft FUD. It has taken the US federal and state governments years and millions of dollars to take Microsoft to court, and they still don't have a decisive result. What chance does anyone else have of proving them "liable", even leaving aside the EULA's exclusion of liability?
Personally, I can run a diff of my Apache and other source checkouts against what's currently in the tree, and know for sure what's changed. I find that much more reassuring that you handwaving about "check digits".
Get an open source PalmOS tool like Keyring for PalmOS or String that can generate random passwords and store them safely encrypted. Then you can use strong passwords that are different on every machine, and change them regularly without needing to worry about forgetting them. (But don't forget to make backups of your keyring!)
If you write or use software, start using Gnu Privacy Guard signatures on the packages. It's not that hard, and it gives good (not perfect) protection against the distribution machine being compromised.
The action plan is
Generate a secret key. Use a strong passphrase, and keep it on a machine that you trust deeply. (Your own laptop or desktop.) Perhaps even keep it on removable media.
Distribute the public key widely. Get other people to sign it, after checking your credentials.
For all future releases of the software, either generate a detached signature, or put the MD5 signature into a GPG-signed release announcement.
When you download software, check the signature before you install it.
This is not complete protection: there are still attacks involving breaking the signing machines, getting users to use the wrong public key, and so on. But if more projects started using this, it would be a real advance.
Here's an enormous and concrete example: the SMB protocol used for Windows file sharing. Most of the functionality in Samba has been created by examining network traffic, since very little of the protocol is documented by Microsoft, and what is documented is often wrong. Examine the samba-technical mailing list archives for details.
Another example is the.HLP file format used in older versions of Windows. I was trying to write code to read them a couple of years ago, searched MSDN very thoroughly and found nothing. (Possibly it's here now; I doubt it.) The same goes for.DOC, and other Office programs. People who choose these programs give over control of their own data to a monopolist.
If you can find complete and accurate documentation of these somewhere on MSDN, please post the URLs.
I think they're actually not compatible if it's the old-style Berkeley license, because the advertising clause clashes with the GPL's requirement of no restrictions on distribution other than the GPL itself. Perhaps that's wrong.
At any rate, the original author can always dual-license it, and without the advertising clause (e.g. the MIT-style license) they're perfectly compatible.
(Hi Ceren!)
Most subscribers use the RBL from their mail server as a way of deciding whether to accept connections or forward mail.
However, it can also be fed directly into routers through eBGP4. I think larger networks might be more likely to use it that way. In this case, the blacklisted addresses simply become unroutable, and not even web access to the domain will work.
This only happens if your network, or your upstream, voluntarily and consciously decides they want to follow MAPS's advice about abusive networks. --
Martin
Attackers won't get in by defeating smartcard antitamper mechanisms any more than they get in by brute-forcing DES today. Even when the cards are perfect, there will be gaping holes in the system.
Consider for example a smartcard reader connected to a Windoze box and used to authenticate network connections. Why bother breaking the card when you could just take over the machine once authentication is complete?
That, and DECSSS-style stupidity inside the cards should mean that hackers of all varieties will continue unimpeded.
Privacy however... now there's a problem. --
Martin
Free software is not about anti-commercialism. That is a purely RMS concept,
You're quite right that they're not the same, and I don't think RMS has ever claimed that they are. I think RMS would object strongly to Meyer's attempt to confuse commercial software with proprietary software -- Martin
As of last week, Junkbuster did not filter out the cache-control headers, although it does make it harder to use the results. I heard from (I think) a Junkbuster developer that they'll be considering this problem in the next version.
I think servers could track pretty well using a combination of cache control and IP even in the absence of Referer headers, though this would only give most-likely and not certain results. Consider for example a proxy or Apache module that rewrites the modification times on all requests from a server.
The general point, in any case, is
if the server can hand some information to the client and have the client later send back the same data then tracking is possible
and protocol designers should remember that. -- Martin
I'm writing an application called GNU Keyring with the best features from all of these, and it's also GPL'd so that you can assure yourself of its security. You can find it at Freshmeat 942590261.
The Internet develops so quickly in part because it amplifies intelligence: it lets people cooperate and work more effectively than ever before. When it's stabilized, when the boom ends, we'll still have that benefit and will be able to apply it to other problems. Consider how much better space exploration will be with ubiquitous networking. "Can't get there without going through here."
Slashdot Mirror
about similar topics from an Australian perspective is Where's The Loot?. The author, Grant Butler, was a financial journalist during the boom and had the chance to see a fair number of companies in details. I strongly recommend it.
"Every EULA is doing you damage."
Mr Goundry seems to be ignoring the fact that UTF-8, which is for many purposes is the most useful representation of UNICODE characters, can compatibly and simply represent the full ISO-10646 character space of 2^31 characters, just by using more of the reserved prefix bits. I can't see what his objection is to this.
Plane zero (the first 65k characters) is supposed to be enough for most ordinary people speaking modern languages. The additional codeplanes exist to satisfy the valid needs of linguists studying archaic or obscure languages, and our author is welcome to use them.
65k characters seems like a reasonable limit for ordinary use: going beyond that is going to require a whole new level of complexity in font representation, character entry, and so on. Even being able to display all those characters only gets you halfway: you have to take into account ligature, composition, kerning and layout rules, and it's not at all clear many program authors will find this worthwhile for obscure dialects.
The elegance of UNICODE is that it offers a smooth migration path away from ASCII through UTF-8, captures a great majority of uses in plane zero, and can expand to handle more obscure cases.
You assume the tree is safe. In this case the tree is suspect.
No, the point of reading the diff is that it allows me to avoid assuming the tree is safe.
Let me explain it in smaller words: I have a checkout of the Apache source on my laptop, which I last updated a month or two ago. (This is not just an example, I really do.) If I get a new checkout of the tree, and run a recursive diff across the two directories, then I can see all the changes which were made to the head of the tree since I made my checkout. Most of these will be normal development changes that have happened in the intervening period, but if I see any suspicious binding of ports or launching of shells then we know something bad has happened.
Of course this is not just me. Many developers or spectators will have their own copies of the tree from various points in time. Covalent, IBM and distribution vendors will have their own internal mirrors of the tree. Since the intruders couldn't break all of these copies, any damage would likely be discovered.
The review process Brian explains in his mail is a systematic way of doing this. The chances that a change will slip through are pretty small.
That's classic Microsoft FUD. It has taken the US federal and state governments years and millions of dollars to take Microsoft to court, and they still don't have a decisive result. What chance does anyone else have of proving them "liable", even leaving aside the EULA's exclusion of liability?
Personally, I can run a diff of my Apache and other source checkouts against what's currently in the tree, and know for sure what's changed. I find that much more reassuring that you handwaving about "check digits".
Get an open source PalmOS tool like Keyring for PalmOS or String that can generate random passwords and store them safely encrypted. Then you can use strong passwords that are different on every machine, and change them regularly without needing to worry about forgetting them. (But don't forget to make backups of your keyring!)
The action plan is
- Generate a secret key. Use a strong passphrase, and keep it on a machine that you trust deeply. (Your own laptop or desktop.) Perhaps even keep it on removable media.
- Distribute the public key widely. Get other people to sign it, after checking your credentials.
- For all future releases of the software, either generate a detached signature, or put the MD5 signature into a GPG-signed release announcement.
- When you download software, check the signature before you install it.
This is not complete protection: there are still attacks involving breaking the signing machines, getting users to use the wrong public key, and so on. But if more projects started using this, it would be a real advance.Here's an enormous and concrete example: the SMB protocol used for Windows file sharing. Most of the functionality in Samba has been created by examining network traffic, since very little of the protocol is documented by Microsoft, and what is documented is often wrong. Examine the samba-technical mailing list archives for details.
.HLP file format used in older versions of Windows. I was trying to write code to read them a couple of years ago, searched MSDN very thoroughly and found nothing. (Possibly it's here now; I doubt it.) The same goes for .DOC, and other Office programs. People who choose these programs give over control of their own data to a monopolist.
Another example is the
If you can find complete and accurate documentation of these somewhere on MSDN, please post the URLs.
I think they're actually not compatible if it's the old-style Berkeley license, because the advertising clause clashes with the GPL's requirement of no restrictions on distribution other than the GPL itself. Perhaps that's wrong. At any rate, the original author can always dual-license it, and without the advertising clause (e.g. the MIT-style license) they're perfectly compatible. (Hi Ceren!)
However, it can also be fed directly into routers through eBGP4. I think larger networks might be more likely to use it that way. In this case, the blacklisted addresses simply become unroutable, and not even web access to the domain will work.
This only happens if your network, or your upstream, voluntarily and consciously decides they want to follow MAPS's advice about abusive networks.
--
Martin
Attackers won't get in by defeating smartcard antitamper mechanisms any more than they get in by brute-forcing DES today. Even when the cards are perfect, there will be gaping holes in the system.
Consider for example a smartcard reader connected to a Windoze box and used to authenticate network connections. Why bother breaking the card when you could just take over the machine once authentication is complete?
That, and DECSSS-style stupidity inside the cards should mean that hackers of all varieties will continue unimpeded.
Privacy however... now there's a problem.
--
Martin
You're quite right that they're not the same, and I don't think RMS has ever claimed that they are. I think RMS would object strongly to Meyer's attempt to confuse commercial software with proprietary software
--
Martin
I think servers could track pretty well using a combination of cache control and IP even in the absence of Referer headers, though this would only give most-likely and not certain results. Consider for example a proxy or Apache module that rewrites the modification times on all requests from a server.
The general point, in any case, is
and protocol designers should remember that.--
Martin
How ironic that today I finally got around to making an appointment with a physiotherapist -- I think I'm getting CTS in my left hand.
I'm writing an application called GNU Keyring with the best features from all of these, and it's also GPL'd so that you can assure yourself of its security. You can find it at Freshmeat 942590261.
See, for example, Kim Stanley Robinson's Red Mars epic hard-sf trilogy, which includes a description of the failure of a space elevator.
Facades As Distributed Components
Distributed Facade
My heuristic is that one should design CORBA interfaces thinking of them as network protocols, not as collections of objects in a program.
The Internet develops so quickly in part because it amplifies intelligence: it lets people cooperate and work more effectively than ever before. When it's stabilized, when the boom ends, we'll still have that benefit and will be able to apply it to other problems. Consider how much better space exploration will be with ubiquitous networking. "Can't get there without going through here."
(Well, I'm feeling optimistic today.)