This has nothing to do with stopping viruses. When an email virus runs code that is interpreted by an interpreter in Outlook or in a Windows DLL, it is running code that very likely would have been signed by MicroSoft.
Virus code and all other computer hacking relies on bugs and programming errors. It will not help one bit if these bugs and errors are signed by Palladium!
You machine can run an old version of Word, right? Like say from Windows 3.1. But can that old version of Word open a file saved with the new version of Word? Hint: the answer is no.
That is how back-compatability works. You can run *old* software, but that does not mean that old software can do anything with *new* data.
Nonsense. They can do this right now. Run "kiosk" style software on Windows. MicroSoft even makes such stuff and has gotten it so that the worst a user can do is crash the machine and it reboots and is running the software again.
The problem is the IT department, which knows the password, can run anything. For business users this is actually good, they like having their IT department able to modify their systems to match their needs. But for Hollywood and MicroSoft it is bad, because that IT department has no disincentive to run software that harms Hollywood's and MicroSoft's business models as long as it does not harm the business the IT department is working for.
Palladum is entirely to force users who do have control over their machines to be unable to do things.
It is trivial to force users of a machine that that user does not have final control over to be unable to do things. This is a long-solved problem and Palladium has nothing to do with it.
This could be done with some clever easy-to-use system by which the user of a program can be told clearly whether a package that is being installed has the right cryptographic signature. It should be impossible without root privledge to install anything without passing through this, and it should be made extremely difficult to fool the user into bypassing it or ignoring the warning message.
However I am now thinking a better approach is to have zero-capabilities programs. Every single thing the program tries to do would pop up a box and the user would confirm/deny it. To make this actually usable they could confirm the program's ability to do it forever. To allow a word processor to save files to any typed-in name without popping up a box every time, the word processor would have to talk to another program that confirms that the name of the file being written is the one the user typed in. Or something like that. This is obviously complicated. However I feel this may be more possible in Linux than windows due to the much smaller kernel interface.
TCPA devices have their place -- in banks, brokerages, power plants, and other establishements where you don't want random code introduced without a red flag popping up. And its use and proliferation should be confined to precisely those areas.
I don't see any reason for TCPA even here. Any such system should be designed to not run anything unexpected, whether it is "signed" or not. And that is easy to enforce by not letting people who might be interested in running unwanted programs from touching the machine.
The trick with TCPA/Palladium is it tries to keep a person who is interested in running such programs and has complete control over the machine, from doing so. This does not sound good to me, and very bad for banks, power plants, and other places that might really need to modify the software on their machine!
You are wrong. There is very good security for two programs to talk to each other right now. SSL and things like that. The problem is that they rely on the idea that the users of both programs are interested in maintaining that security. If for instance I was uninterested in how secure my system was I could tell anybody the password, and it would not matter how advanced the encryption used was. Currently I can do this and not get in trouble or thrown in jail.
Despite all the smoke and mirrors, Palladium's purpose is to try to make sure the program is "secure" even when the user of the program does not want it to be secure.
The problem with this scenario is that it necessarily removes control from the owner of the program or machine. Unfortunately I cannot think of any possible scenario where this is benificial to the user of the software. If you can elighten me to a single instance where the fact that a user cannot give away their password no matter how much they want to is benificial to them, I would like to hear it.
Yes there are mini-command lines, but there is still the serious lack on Linux of an "open" command that does the same thing as a double-click of an icon in the desktop environment. We *REALLY* need this, it is shameful that both OS/X and WIndows (which calls it "start") have it, but the supposedly command-line-oriented Linux does not.
It would also allow a lot more variety in file managers because they would no longer have to manage the linkings.
While I'm at it, I would also like to see the ability to open tar files and ftp sites and smb shares moved out of the graphical file managers and moved to the open() system call, so that any program that wants to can read such names (use the KDE naming with smb: or whatever at the start). This would also go a long way to making it easier to implement file managers and would probably allow a vast number of new services to be added easily.
I believe a parser that does not have to decode UTF-8 will be both faster and more correct. This is because it is much simpler and can use well-established tools that work with bytes. Even with modern memory sizes using 256-entry lookup tables is much more possible than a 2^31 entry lookup table.
For these reason I would greatly prefer a scheme where all characters greater than 0x7f are treated identically.
No it doesn't. Unicode also defines paragraph and line seperator characters, in the same document that describes this NEL character, and those are not treated as newlines.
There is a good reason for this: those characters are hard to identify in UTF-8 and some other encodings without actually decoding to Unicode. Unfortunatly this is also true of 0x85. Therefore I think this proposal is bad.
Also there are a *lot* of people (all users of MicroSoft Word) who think this character is an ellipsis.
I think the standard should read that a sequence containing a single 0x0a preceeded and followed by any number of 0x0d's should count as a single newline. A 0x0a or a 0x0d by itself also counts as a newline. This should handle all the possibilities listed.
I used to think 0x0d could be treated as whitespace but it sounds like older Macintoshes messed up that idea.
The MicroSoft assignemnts should be made official, in my opinion.
The idea of protecting systems from the high bit being stripped is obsolete. UTF-8 (and also all 16 or 32 bit encodings) will cause exactly the same havoc with such systems because they will use bytes that when the high bit is stripped produce C0 control characters. Therefore the idea of protecting the C1 range is irrelevant as soon as you talk about any encoding with more than 256 characters.
These slots must be filled in and MicroSoft's assignments are quite a reasonable selection of punctuation marks and symbols that are in very common use. The euro symbol is particularily important today. Even if the assignments are not ideal, these assignments are used so much that it is impossible to argue for any other assignments.
I don't think 0x85 (or any other character > 0x7f) should be used for any kind of control or newline purposes.
The main reason is that is does not pass cleanly throught UTF-8 encoding and thus it is far too easy to write software to miss it, and writing correct software is inefficient. Anything that assigns a non-tokeninzing meaning to characters > 0x7f will mean the UTF-8 must be decoded to parse the file. If instead all characters > 0x7f are considered parts of identifiers/words then the parser can easily be byte-based and use lookup tables to correctly match words. In fact this can be very safe because it will prevent illegal UTF-8 encodings, provided the parsers check the encoding when *adding* words to their has tables, they have no need to check encodings when looking up words, as illegal long encodings will not match.
In addition there is no good reason for the "hole" in 0x80 through 0x9F. It was done so that systems that stripped the high bit would not accidentally map a foreign letter to a control code. However all such systems are long obsolete and would barf on UTF-8 encoding anyway (since it does use these codes).
My recommendation, strange as it may seem for something on Slashdot, is to use MicroSoft's assignments use in Word for these codes (usually seen as the "smart quotes" output). This is apparently called the "CP1252 superset" in MicroSoft-speak. In this encoding 0x85 is the ellipsis (...).
Why use this arbitrary standard from the evil company? Mostly because it is by far the most-used standard for these codes. Also I think the assignments are pretty good, they were selected for actual use in the (admittedly euro-centric) modern world of office software, and are not tainted with the nasty political correctness that has so messed up and delayed Unicode assignments.
I recommend two things: first that all characters >0x7f in Unicode be considered "part of an identifier" by all parsers. Second that Unicode have the MicroSoft CP1252 assignments added to the codes 0x80-0x9f.
That is true. Almost all real innovation in Graphical User Interface is being done on Unix and Unix-like systems. Unfortunatly none of it sees the light of day because it is "not user friendly", ie it does not look like Windows.
Just see what happens if somebody here proposes a different design for a window manager. They are yelled at mercilessly for being "user unfriendly". Unfortunatly everything that does not look identical to Windows is attacked this way.
It is pretty obvious from the statement that he is not talking about TCO, his statement shows he thinks "Open-source programs" are a different catagory than "Unix". Ie: Linux is not Unix. By "Unix" he means the commercial things like Solaris and Irix, and they are more expensive than Windows. Meanwhile Linux is cheaper than windows and "has improved enough to replace" expensive Unix machines.
This is a very very bad idea. You seriously underestimate the enormous complexity of the communication to a "toolkit". Also there is a little thing called "innovation" where people invent new methods of GUI interaction. This would be stopped by such a design, or would force people to write a parallel toolkit anyway (as many (most?) Windows applications are forced to).
If you don't believe GUI innovation happens, imagine if X had an enforced toolkit. It would be Athena, in black and white, with this 1-bit color so written into it that it would be impossible to remove, and everybody would marvel at the fact that you could set it to inverse video and all applications would agree. And defenders would claim that the fact that only the middle mouse button makes the scrollbars move was a *feature*. And any intelligent people would be laughing X off the planet!
Meanwhile, despite it's problems and pretty stupid design even for when it was invented, X is able to replicate interfaces designed 15 or more years after it was invented. This is because of the one intelligent decision they made, which was to keep the GUI widgets out of it!
Now X has problems. There really should be high-level graphics, at least similar to PostScript. Though also complex, it is far less complex than toolkit interfaces, and perhaps more importantly the set of graphics calls needed has been pretty stable for about 20 years. It may even make sense to add calls to "draw a nice raised box" or "clear this to the flat background color" which would do about 99% of what people want "themes" to do.
Also there is a bit of "toolkit" inside X: the "window manager" (even though a seperate process, but the communication protocols are there, and I know for a fact that it takes more code to communicate with the window manager than it would take to draw the window borders and handle moving and raising the windows myself). This also needs to be removed.
But I am serious that putting any kind of "toolkit" interface into the system in a very very bad idea.
You just described a command-line interface. With the added feature that the ability to type the command requires you to clutter your desktop with icons that you will not click on. Brilliant.
People keep defending Mozilla by saying you can remove the modules. But I feel that a program that was *only* a browser is really what we need, and that everything else (mail, ftp, chat, etc) could be done by *seperate* programs, not modules. It would also be much, much easier to add new functions.
Here is how it would work for mail:
Some new interface is added so a program can act as a "server" of web pages that are seen by the local machine. For instance a program can run that will then claim that anything starting with "/mail" should go to it. In my ideal situation this would replace the filesystem entirely so any program can read data from any service by using open() and read(), though I realize that there may be additional calls needed for synchronization.
This program then generates the display and email interface, exactly like hotmail or whatever does to display your email from a remote machine on your browser.
The browser works like normal and has no idea it is displaying or creating email.
Any deficienices in how the interface works are addressed by adding new browser-like functionality that can be used by things other than email, and by changing the email client to use them.
This all seem remarkably easy but I never see this approach proposed. Am I missing anything?
A whole lot of people sent me "junction.exe". Unfortunately I have been unable to get it to work. I either get "illegal parameter" or "malformed junction name" or something like that. It does appear to work for *local* disks but that is pretty useless, what I am trying to do is get *remote* disks to work so that filenames can be identical on all our NT and Linux machines.
As far as I can tell there is a definate planned effort by MicroSoft to make this impossible. It could be solved trivially by adding a type of file to NTFS which is a "symbolic link" where the contents of the text are interpreted by the OS as a new file to alias to this original name. Because it is text it would allow *any* file that can be opened to be given a new name. It sould also be trivial to implement and is fairly easy to understand by moderate users and would be a major improvement to Windows. Instead we get all these programs with "junction points" and "hard links" where the target is seriously limited (ie to local disks, files on the same disk, and special services like the "Desktop").
It is of course in MicroSoft's interest that we are forced to modify all filenames if we want our scripts and software to work on both Linux and NT. At work we have to add "z:" to every file that starts with a small set of names, and strip this off when typed in by the user before storing files. This is incredibly painful, probably causing more porting difficulties than the difference between X and GDI, despite the initial impression that this is trivial. It also means we cannot use any standard software that handles filenames as any part of our toolchain unless we modify the software to do this to the filenames.
Say I invent a new way to decode the encryption on the new DRM DVD. I can do this because it is all documented. Yet my program will not work unless it is running in the palladium box with a key for it's own hash, which I cannot generate. So how do I test if my program works? Do I submit it to get a hash code approved? What if I then find I had a bug, do I have to submit the fixed version for another hash code?
I don't think this can possibly work. Instead even rich developers will have to have access to a hash-generating code machine. If you think AlQueda or a Hong Kong pirate cannot also get one of these machines, if they exist at all,then you are seriously mistaken.
Like many others here I believe all this is a direct attack on open source software (or any competing software, though MicroSoft has managed to squash everybody other than Open Source hackers already).
If there is a player that plays unencrypted content, then it is possible to copy movies. It only needs to be copied once, perhaps by a hacker with hardware modifications, or by pointing a video camera at the screen, and then can be played everywhere.
If only encryped content can be played, then it does not matter if some hacker makes a copy, it cannot be played on most people's machines. Every single machine would have to be hacked to enable it to play some new player that allowed unencrypted content. The security to IP is enormously greater with such a system, ie hundreds of millions of times more secure, so much greater that the drive to enforce this system will completely squash any morals or promises by a few people at MicroSoft.
But how will parents send grandma their videos of their baby? The answer is they won't, and they will forget the fact that there was once a time when a recording could be removed from one device and put into another. Or more likely they will be able to do it with a live connection through a trusted 1:1 connection from their camera to grandma's desktop.
Nobody will be able to record music, make movies, and possibly even publish text without a license from a media conglomerate.
I believe this is going to happen if these schemes are not stopped now.
It has come to my attention that the HFS filesystem includes a layer to "decompose" the Unicode/UTF-8 string used to identify files. This I believe is a serioius security and design mistake that will hurt you greatly in the future and may seriously impact the ability to make a user-friendly interface to the system. I got into an argument with somebody about this and he basically said "well if you think you are so right, tell Apple". Well, I do think I am right and so I am trying to tell you.
A file on the file system should be identified by a series of bytes. Ideally there should be as few rules as possible about this series of bytes. For instance the Unix rules that the nul and slash characters are not allowed are, in my opinion, pushing the limits of complexity. (An ideal system would take an arbitrary byte stream and a length in bits to identify the file). In addition all different byte sequences should be required to identify a different directory entry.
The fact that other parts of the system will treat these bytes as UTF-8 encoding of Unicode and that when the same bytes are sent to a totally different display device causes some glyphs to appear that have some meaning to a human being should NOT be a consideration when designing low level communication and storage protocols. Unfortunately you seem to have fallen into the same trap virtually every file system designer has.
I am most concerned about the "decomposing" rules, though the case insensitivity is also a problem. These rules make it very difficult to write secure software that can make assumptions about the non-collision of files, or to use filenames for database purposes, or to support foreign file systems that do not follow the same mapping rules (as you have already discovered with NFS). They also seriously damage the ability to write user-friendly front ends that do more complex file-matching rules by making the underlying service complicated. People keep saying the average user thinks the file "Random" and "random" are the same, which is true, but they also think the file "random" and "ranndom" are the same, and systems that can solve this are much harder to write when there are cheapo "solutions" hidden underneath that they must contend with and compensate for.
Therefore I wish to recommend that you seriously reconsider your design. Ideally the operating system interface should accept any stream of bytes as a file identifier, including malformed UTF-8 strings. Decomposition and all other matching, though quite useful, are best done at the application level, for instance your file selector could decompose any text typed in, and you could provide a spelling-corrector like interface in a library to find the best match of a user-typed filename, much like the bash shell's spelling corrector.
I've found symbolic links to be more likely to do what I want. My only experience with hard links was early (1982) VAX Unix systems which I don't think had symbolic links, and we seemed to get in a lot of trouble with the creation of loops.
Also it seems that symbolic links are easy to support on any file system as long as there is room for one bit to be stored with the file because the actual resolution can be done at a higher level. This is one reason why I am completely baffled as to why MicroSoft refuses to add them to NT.
Then again hard links do have a certain appeal of being the "correct" way to do things, rather than kludges involving strings. I also think most of the stuff symbolic links are being used to solve could be fixed with Plan-9 type merge mounts.
Um, most of those *ARE* antialiased curves. At least the corners of the ovals in the window titles and the corners of the OK buttons are. Try zooming in on the sample image. It does look like the corners of the windows themselves are not antialiased, though.
Slashdot Mirror
Virus code and all other computer hacking relies on bugs and programming errors. It will not help one bit if these bugs and errors are signed by Palladium!
You machine can run an old version of Word, right? Like say from Windows 3.1. But can that old version of Word open a file saved with the new version of Word? Hint: the answer is no.
That is how back-compatability works. You can run *old* software, but that does not mean that old software can do anything with *new* data.
The problem is the IT department, which knows the password, can run anything. For business users this is actually good, they like having their IT department able to modify their systems to match their needs. But for Hollywood and MicroSoft it is bad, because that IT department has no disincentive to run software that harms Hollywood's and MicroSoft's business models as long as it does not harm the business the IT department is working for.
Palladum is entirely to force users who do have control over their machines to be unable to do things.
It is trivial to force users of a machine that that user does not have final control over to be unable to do things. This is a long-solved problem and Palladium has nothing to do with it.
However I am now thinking a better approach is to have zero-capabilities programs. Every single thing the program tries to do would pop up a box and the user would confirm/deny it. To make this actually usable they could confirm the program's ability to do it forever. To allow a word processor to save files to any typed-in name without popping up a box every time, the word processor would have to talk to another program that confirms that the name of the file being written is the one the user typed in. Or something like that. This is obviously complicated. However I feel this may be more possible in Linux than windows due to the much smaller kernel interface.
I don't see any reason for TCPA even here. Any such system should be designed to not run anything unexpected, whether it is "signed" or not. And that is easy to enforce by not letting people who might be interested in running unwanted programs from touching the machine.
The trick with TCPA/Palladium is it tries to keep a person who is interested in running such programs and has complete control over the machine, from doing so. This does not sound good to me, and very bad for banks, power plants, and other places that might really need to modify the software on their machine!
Despite all the smoke and mirrors, Palladium's purpose is to try to make sure the program is "secure" even when the user of the program does not want it to be secure.
The problem with this scenario is that it necessarily removes control from the owner of the program or machine. Unfortunately I cannot think of any possible scenario where this is benificial to the user of the software. If you can elighten me to a single instance where the fact that a user cannot give away their password no matter how much they want to is benificial to them, I would like to hear it.
It would also allow a lot more variety in file managers because they would no longer have to manage the linkings.
While I'm at it, I would also like to see the ability to open tar files and ftp sites and smb shares moved out of the graphical file managers and moved to the open() system call, so that any program that wants to can read such names (use the KDE naming with smb: or whatever at the start). This would also go a long way to making it easier to implement file managers and would probably allow a vast number of new services to be added easily.
For these reason I would greatly prefer a scheme where all characters greater than 0x7f are treated identically.
There is a good reason for this: those characters are hard to identify in UTF-8 and some other encodings without actually decoding to Unicode. Unfortunatly this is also true of 0x85. Therefore I think this proposal is bad.
Also there are a *lot* of people (all users of MicroSoft Word) who think this character is an ellipsis.
I used to think 0x0d could be treated as whitespace but it sounds like older Macintoshes messed up that idea.
The idea of protecting systems from the high bit being stripped is obsolete. UTF-8 (and also all 16 or 32 bit encodings) will cause exactly the same havoc with such systems because they will use bytes that when the high bit is stripped produce C0 control characters. Therefore the idea of protecting the C1 range is irrelevant as soon as you talk about any encoding with more than 256 characters.
These slots must be filled in and MicroSoft's assignments are quite a reasonable selection of punctuation marks and symbols that are in very common use. The euro symbol is particularily important today. Even if the assignments are not ideal, these assignments are used so much that it is impossible to argue for any other assignments.
The main reason is that is does not pass cleanly throught UTF-8 encoding and thus it is far too easy to write software to miss it, and writing correct software is inefficient. Anything that assigns a non-tokeninzing meaning to characters > 0x7f will mean the UTF-8 must be decoded to parse the file. If instead all characters > 0x7f are considered parts of identifiers/words then the parser can easily be byte-based and use lookup tables to correctly match words. In fact this can be very safe because it will prevent illegal UTF-8 encodings, provided the parsers check the encoding when *adding* words to their has tables, they have no need to check encodings when looking up words, as illegal long encodings will not match.
In addition there is no good reason for the "hole" in 0x80 through 0x9F. It was done so that systems that stripped the high bit would not accidentally map a foreign letter to a control code. However all such systems are long obsolete and would barf on UTF-8 encoding anyway (since it does use these codes).
My recommendation, strange as it may seem for something on Slashdot, is to use MicroSoft's assignments use in Word for these codes (usually seen as the "smart quotes" output). This is apparently called the "CP1252 superset" in MicroSoft-speak. In this encoding 0x85 is the ellipsis (...).
Why use this arbitrary standard from the evil company? Mostly because it is by far the most-used standard for these codes. Also I think the assignments are pretty good, they were selected for actual use in the (admittedly euro-centric) modern world of office software, and are not tainted with the nasty political correctness that has so messed up and delayed Unicode assignments.
I recommend two things: first that all characters >0x7f in Unicode be considered "part of an identifier" by all parsers. Second that Unicode have the MicroSoft CP1252 assignments added to the codes 0x80-0x9f.
Just see what happens if somebody here proposes a different design for a window manager. They are yelled at mercilessly for being "user unfriendly". Unfortunatly everything that does not look identical to Windows is attacked this way.
It is pretty obvious from the statement that he is not talking about TCO, his statement shows he thinks "Open-source programs" are a different catagory than "Unix". Ie: Linux is not Unix. By "Unix" he means the commercial things like Solaris and Irix, and they are more expensive than Windows. Meanwhile Linux is cheaper than windows and "has improved enough to replace" expensive Unix machines.
If you don't believe GUI innovation happens, imagine if X had an enforced toolkit. It would be Athena, in black and white, with this 1-bit color so written into it that it would be impossible to remove, and everybody would marvel at the fact that you could set it to inverse video and all applications would agree. And defenders would claim that the fact that only the middle mouse button makes the scrollbars move was a *feature*. And any intelligent people would be laughing X off the planet!
Meanwhile, despite it's problems and pretty stupid design even for when it was invented, X is able to replicate interfaces designed 15 or more years after it was invented. This is because of the one intelligent decision they made, which was to keep the GUI widgets out of it!
Now X has problems. There really should be high-level graphics, at least similar to PostScript. Though also complex, it is far less complex than toolkit interfaces, and perhaps more importantly the set of graphics calls needed has been pretty stable for about 20 years. It may even make sense to add calls to "draw a nice raised box" or "clear this to the flat background color" which would do about 99% of what people want "themes" to do.
Also there is a bit of "toolkit" inside X: the "window manager" (even though a seperate process, but the communication protocols are there, and I know for a fact that it takes more code to communicate with the window manager than it would take to draw the window borders and handle moving and raising the windows myself). This also needs to be removed.
But I am serious that putting any kind of "toolkit" interface into the system in a very very bad idea.
What makes you think MicroSoft wants you to have the ability to develop trusted software?
You just described a command-line interface. With the added feature that the ability to type the command requires you to clutter your desktop with icons that you will not click on. Brilliant.
Here is how it would work for mail:
Some new interface is added so a program can act as a "server" of web pages that are seen by the local machine. For instance a program can run that will then claim that anything starting with "/mail" should go to it. In my ideal situation this would replace the filesystem entirely so any program can read data from any service by using open() and read(), though I realize that there may be additional calls needed for synchronization.
This program then generates the display and email interface, exactly like hotmail or whatever does to display your email from a remote machine on your browser.
The browser works like normal and has no idea it is displaying or creating email.
Any deficienices in how the interface works are addressed by adding new browser-like functionality that can be used by things other than email, and by changing the email client to use them.
This all seem remarkably easy but I never see this approach proposed. Am I missing anything?
As far as I can tell there is a definate planned effort by MicroSoft to make this impossible. It could be solved trivially by adding a type of file to NTFS which is a "symbolic link" where the contents of the text are interpreted by the OS as a new file to alias to this original name. Because it is text it would allow *any* file that can be opened to be given a new name. It sould also be trivial to implement and is fairly easy to understand by moderate users and would be a major improvement to Windows. Instead we get all these programs with "junction points" and "hard links" where the target is seriously limited (ie to local disks, files on the same disk, and special services like the "Desktop").
It is of course in MicroSoft's interest that we are forced to modify all filenames if we want our scripts and software to work on both Linux and NT. At work we have to add "z:" to every file that starts with a small set of names, and strip this off when typed in by the user before storing files. This is incredibly painful, probably causing more porting difficulties than the difference between X and GDI, despite the initial impression that this is trivial. It also means we cannot use any standard software that handles filenames as any part of our toolchain unless we modify the software to do this to the filenames.
I don't think this can possibly work. Instead even rich developers will have to have access to a hash-generating code machine. If you think AlQueda or a Hong Kong pirate cannot also get one of these machines, if they exist at all,then you are seriously mistaken.
Like many others here I believe all this is a direct attack on open source software (or any competing software, though MicroSoft has managed to squash everybody other than Open Source hackers already).
If there is a player that plays unencrypted content, then it is possible to copy movies. It only needs to be copied once, perhaps by a hacker with hardware modifications, or by pointing a video camera at the screen, and then can be played everywhere.
If only encryped content can be played, then it does not matter if some hacker makes a copy, it cannot be played on most people's machines. Every single machine would have to be hacked to enable it to play some new player that allowed unencrypted content. The security to IP is enormously greater with such a system, ie hundreds of millions of times more secure, so much greater that the drive to enforce this system will completely squash any morals or promises by a few people at MicroSoft.
But how will parents send grandma their videos of their baby? The answer is they won't, and they will forget the fact that there was once a time when a recording could be removed from one device and put into another. Or more likely they will be able to do it with a live connection through a trusted 1:1 connection from their camera to grandma's desktop.
Nobody will be able to record music, make movies, and possibly even publish text without a license from a media conglomerate.
I believe this is going to happen if these schemes are not stopped now.
If this is a joke, congratulations, it is well written. If this is not a joke it is pretty scary that anybody would believe any of this.
Even if the system works as you say, I'd like to know how the OSS program writer can test the decryption portion?
Title: FIlename mangling in HFS
It has come to my attention that the HFS filesystem includes a layer to "decompose" the Unicode/UTF-8 string used to identify files. This I believe is a serioius security and design mistake that will hurt you greatly in the future and may seriously impact the ability to make a user-friendly interface to the system. I got into an argument with somebody about this and he basically said "well if you think you are so right, tell Apple". Well, I do think I am right and so I am trying to tell you.
A file on the file system should be identified by a series of bytes. Ideally there should be as few rules as possible about this series of bytes. For instance the Unix rules that the nul and slash characters are not allowed are, in my opinion, pushing the limits of complexity. (An ideal system would take an arbitrary byte stream and a length in bits to identify the file). In addition all different byte sequences should be required to identify a different directory entry.
The fact that other parts of the system will treat these bytes as UTF-8 encoding of Unicode and that when the same bytes are sent to a totally different display device causes some glyphs to appear that have some meaning to a human being should NOT be a consideration when designing low level communication and storage protocols. Unfortunately you seem to have fallen into the same trap virtually every file system designer has.
I am most concerned about the "decomposing" rules, though the case insensitivity is also a problem. These rules make it very difficult to write secure software that can make assumptions about the non-collision of files, or to use filenames for database purposes, or to support foreign file systems that do not follow the same mapping rules (as you have already discovered with NFS). They also seriously damage the ability to write user-friendly front ends that do more complex file-matching rules by making the underlying service complicated. People keep saying the average user thinks the file "Random" and "random" are the same, which is true, but they also think the file "random" and "ranndom" are the same, and systems that can solve this are much harder to write when there are cheapo "solutions" hidden underneath that they must contend with and compensate for.
Therefore I wish to recommend that you seriously reconsider your design. Ideally the operating system interface should accept any stream of bytes as a file identifier, including malformed UTF-8 strings. Decomposition and all other matching, though quite useful, are best done at the application level, for instance your file selector could decompose any text typed in, and you could provide a spelling-corrector like interface in a library to find the best match of a user-typed filename, much like the bash shell's spelling corrector.
Also it seems that symbolic links are easy to support on any file system as long as there is room for one bit to be stored with the file because the actual resolution can be done at a higher level. This is one reason why I am completely baffled as to why MicroSoft refuses to add them to NT.
Then again hard links do have a certain appeal of being the "correct" way to do things, rather than kludges involving strings. I also think most of the stuff symbolic links are being used to solve could be fixed with Plan-9 type merge mounts.
Um, most of those *ARE* antialiased curves. At least the corners of the ovals in the window titles and the corners of the OK buttons are. Try zooming in on the sample image. It does look like the corners of the windows themselves are not antialiased, though.