Microkernel is not about what space software runs in, it's about how the components that make up the system fit together. Among other things, this means having an API based on communicating between components (whether that's message queues, rendezvous, or whatever), and in fact that's MUCH more important than whether components are inside or outside the kernel... in fact a lot of older microkernel designs didn't HAVE a distinction between "in the kernel" and "outside the kernel"... that abstraction is really part of the security model of the system.
Linux seems to use a separate API for just about every pair of subsystems that need to communicate. It's modular, yes, but it's not even vaguely microkernel-like.
It is based on Mach with a BSD compatibility layer
It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.
Dashboard's "warning" to a user on newly-installed widget launch is a simple yes/no proposition without any indication of the access sought by the widget.
The fact is, Dashboard shouldn't be doing this check at all. The check implies that Dashboard is a "safe" environment, and it's not any such thing, so all it does is provide an illusion of security that encourages people to treat Widgets cavalierly... and it's truly ironic that the first victim of this illusion is Apple themselves. Same thing with Amnesty Widget Browser. The whole point to the way these programs work is that they provide a NON-sandboxed environment that can be used for Webcore scripting, without weakening the sandbox in Webcore itself.
This "security prompt" in Dashboard is another baby step down the dark path that Microsoft took almost a decade ago. It's a bad idea... they need to step back and ask whether they should even be treating Dashboard any differently from any other application environment.
Because you have to start somewhere, and you might as well start where you get the most bang for your buck.
If you really want your music in a Windows-only format, I suppose you can always burn it to a disk from iTunes and then rip it in WMA. That's a lot less hassle than Mac users have to go through to play the games themselves.:)
Is it just a techinical issue that it is easer to add a unique ID to each disk by gluing on an RFID than to write it to the disk?
That, and it's harder for Joe Schmoe to create an RFID-equipped disk in his laptop. But the real protection is having the disk "phone home". And they've already started doing that.
I don't see a reason for a spyware program to be given permission to do http or any other requests to machines outside of my PC.
That's nice. You can probably do a really good job of keeping well-behaved applications from getting to the Internet that way. You have absolutely no chance of keeping a malicious applicaton in check that way. "Hey, I can't get to the Internet", thinks the application. "Let's see, there's Internet Explorer, it has access to the Internet. I know! I'll install myself as an internet plugin" (pause for special effects as the application hides itself in your web browser) "ah, that's better, now that I'm Internet Explorer, I can do anything again..."
So long as there's not many people using tight firewalls like this, you'll be OK. Once a lot of people start doing it, though, the spyware authors will notice, and they'll just add tricks like this to their collection. Or they'll turn the firewall off. Or they'll hide themselves in a driver and talk to the real TCP stack beneath the firewall, inside the kernel. Once they're executing on your computer, the only protection is to be a little bit tougher to exploit than average...
It's like the joke about the two hikers who are attacked by a bear. One of them starts running, while the other yells "you can't outrun a bear!" The first one answers, "I just have to outrun you!"
As long as you run faster than MOST people, you're OK. But to solve the spyware problem, so that people won't even TRY to get into your computer whether they can actually do any spying or not, you have to arrange things so that MOST people are running faster than MOST people.
"And this is, of course, impossible"
The goal, then, isn't "keep it from phoning home". It's "keep it out of the computer in the first place". Luckily, that's an easier problem... IF you're prepared to forgo the pleasure of installing every random game or applet you run across on FilePile...
As a Java developer for the past 7 years, can someone remind me as to how Java will benefit from being open source?
It's not whether it's open source or not, it's whether it can be shipped with an open source OS or not. Right now the biggest problem Java has is that when you get your BSD or Linux system set up, you can just click buttons in the installer and you're good to go.
Unless the packages depend on Java, then you have to download Java from Sun's website (which can be really annoying when you're behind a hard firewall and you weren't expecting this) and THEN go back and install them.
So I don't care if Java is the #1 development environment for ANYTHING, right now it's just a royal pain in the ass.
If Sun wants to keep people from reverse-engineering and fragmenting Java, they need to figure out how to fix their licensing so people can just treat it as something else that ships on their Fedora or FreeBSD or whatever CDs. I don't care how they do it, or what face-saving games they have to pull, I just want to stop getting that "oh no not again" feeling when I see that some program I want to use is based on Java.
Why should I, as an end user, download and use Apache's Harmony instead of using SUN's "real" Java.
As an end user... you won't have to go to anyone's website and accept a clickthrough license to download Harmony. It'll be there on your system, like Perl and bash are.
I don't care if they open Java at this point... I just want them to allow verbatim redistribution of their own j2se because I'm getting really tired of having to download the right version of Java separately from Sun's site when I need to set up Java-based packages on Open Source UNIX.
That's what's more or less burned out whatever interest I ever had in Java. It's just another checkbox to slow down setting up a production system.
A firewall can't protect you from actions by programs inside the protection domain of the firewall. A spyware program could communicate with the outside world by techniques as subtle as coding them in the name if HTTP fetch requests, so even if the firewall was a hard proxy and didn't do more than a lookup of the name (say, to see if it's a blocked IP range), it could still call home through the DNS requests the proxy made.
But it requires more knowledge than most users currently possess.
Which is precisely why the responsibility should be placed on the browser developers. Where they have committed to a comprehensive sandbox (for example, in Firefox outside the XPI installation mechanism) people have accepted it AND the system's overall security has been good without any need for annoying scary dialogs. Where they haven't (for example, Safari's "open safe file" mechanism) they've had repeated problems, and users have complained that fixing the problem would be inconvenient for them.
I've had someone ARGUE with me that HE should be an exception to my "No Outlook" rule... WHILE I was sitting there cleaning his computer after he infected it through Outlook. You're right, the users can't be expected to understand the details of security. What's depressing is that the vendors don't seem to understnd either.
Apple, KDE, Mozilla, Microsoft, they all need to stand up and commit to a comprehensive sandbox. They need to commit to NEVER passing an object outside the sandbox, and requiring all plugins, handlers, helper applications, and so on to register explicitly with the browser... and stop assuming that an application designed for use from the shell/Finder/Desktop is safely sandboxed.
[ActiveX] has allowed a LOT of vendors to build browser-based apps to do stuff rather than have to build actual programs.
The really interesting thing here is that the ActiveX based applications aren't any less complex than a standalone application that injected the ActiveX components as plugins inside a customized HTML control, and they're no more convenient for the user than downloading an application would be because right now it's a LOT harder for a user to figure out how to selectively grant the rights to the webpage that's running the applets than it is to download and install an application. It would be possible for Microsoft to completely eliminate the pain of locking down ActiveX simply by providing a simple conversion kit that created this application with the ActiveX plugins bundled into it, and removed the ActiveX launch capability from the common HTML control. Then the user would download the application as an application, and install it as an application, and these applets would exist IN THAT APPLICATION but they, as well as other ActiveX components out there on the web, would be safely ignored by the common HTML control everywhere else in the computer.
At the same time applications like Windows Explorer or Software Update would have to be modified to do the same thing with their custom extensions to the HTML control.
The other "extra rights" (or rather, the code that implements these capabilities) that IE gives to local pages, like running local scripts, could also be injected by the controlling applet the same way.
So long as they didn't then put in code for IE to automatically install these "Windows Dashboard Widgets", they'd be perfectly safe. This is how KDE's Konqueror handles potentially unsafe extensions (they call them I/O slaves). It's how Dashboard adds them to WebCore (well, except for Safari installing them automatically... Safari doesn't even need to know they exist). It's safe, secure, convenient, and I really expected Microsoft to come up with something equivalent SEVEN YEARS AGO after the first HTML-based malware showed up. But, no... and now it's hard for them to go back.
I wrote: "Any application you hand off a document to has to be one that has an equal commitment to maintaining that sandbox. If the user wants to do anything like that, they have to..."
Then I changed the sense of the preceding sentence when I was previewing it, and didn't notice that changed the meaning of this one. What I meant to write was "If the user wants to do anything more than that, they have to..."
Let's pretend for a moment that this would actually work. It's not possible to get people to implement it.
It's hard enough to get any of the browser teams to commit to implementing a complete sandbox, even though that could be done without inconveniencing the users.
It's hard enough to get users to adjust the sandbox that they're already using so that it's as complete as possible, even though doing so imposes very little invenvenience.
Getting users to go through a lot of inconvenience to create a new account to run their browser in, that's really tough.
But even if you could do it, it wouldn't be effective.
A restricted account could still be used to compromise their privacy, it could still be used to destroy data they consider important... their bookmarks, information maintained on websites they connect to, and so on.
And that's assuming it would remain restricted: once I can run native code on your machine, getting out of a restricted environment is just a matter of time. It's easiest on Windows, of course, but even your typical UNIX or Mac OS X box has all kinds of mechanisms that a restricted account can use to extract information from your "real" account, or launch code (directly or through a boobytrap) into the "real" environment.
The only "restricted environments" I have used that I would consider secure enough to not treat malware running in that account as an immediate threat, apart from physically separate boxes, are FreeBSD Jails or completely emulated systems (VMware, Virtual PC, etc).
But we do know one thing that does work very well. And that's having a sandbox that has no holes in its design. That means there's no holes that the developer's reluctant to close, and no holes that users are reluctant to see closed. That means that any holes that do occur are bugs, and as such can be quickly fixed without embarassment and without discouraging users from applying them.
It's not perfect, but it works much better than a whole sandboxed account, and it's much easier to implement and MUCH more convenient.
So: the first absolute requirement for building a secure web is for the browser manufacturers to commit to a completely closed sandbox. That means there is no mechanism inside the sandbox to get outside the sandbox even as far as to see information stored about other websites. That means: no XPI installers, no ActiveX or Active Scripting, no "open safe files after download", no use of "Desktop" applications to open documents (even if you think the document is local), nothing. Any application you hand off a document to has to be one that has an equal commitment to maintaining that sandbox. If the user wants to do anything like that, they have to explicitly download the document and so move it outside the sandbox, and THEN explicitly open it in the unsandboxed environment. Those two steps must never be shortchanged.
What does that mean to the user, then?
Not much, in most cases. For Firefox users that means they'll have to download XPI files and then load them from the menu or their desktop file manager. For Safari users, no more "open safe files", and no more warnings the first time they open an app because the browser won't ever be opening apps behind their back. For Windows, there would be a bigger impact: a few tools like Software Update would be separate applications, but the bigger impact is that some third-party applications would need to be redesigned to use the new safe API.
Windows, I can see their reluctance. The rest? I don't get it... they're not gaining all that much by having a leaky sandbox, and the fact that even such small leaks can be exploited is sure a good argument for having at the very least no designed-in holes at all.
Evolution is not a guided process, there's no "better" state that species are evolving "towards". Evolution is a description of how selective pressures have an effect on a species over time. If we're selecting for something you think is detrimental in some larger sense, and not selecting for something you think is advantageous, that doesn't mean that evolution isn't happening. It just means there's no Great Hoohoo in the sky guiding it in any particular way.
The idea that there is a "Next Step" in evolution is just as religious a position as the idea that evlution doesn't happen. There's no big "steps" in evolution, just lots of little steps all happening at the same time in every possible direction, and the observation that some of these little steps will work out better than others.
That's it.
Everything else, from the whole concept of "species" on, is our attempt to impose order on something that doesn't really fall into the tidy boxes that labels like "species" apply to. Any attempt to extract meaning or to try and describe a "Next Step", or talking about changes in technology as if they have anything to do with evolution of the "species" other than how they change the way genes are selected for, are fundamental category errors.
Yes, computers evolve. Evolution is a process, and computers have all the requirements to be subject to that process. They have inherited characteristics that are encoded in the software that controls them. Their software changes over time as a result of changes in their environment. But the evolution of computers is no more (and no less) the evolution of the human species than the evolution of the horse and dog, once humans started treating them as tools, are part of the evolution of the human species.
Finally, there are no "bad genes", there are just genes that are selected for or selected against. The gene pool has never been "clean" or "dirty", it's just been more or less variable. Right now it's going through a period where there's more variations in it, but that happens normally in any population and is itself an essential part of the process of evolution... without variations, what is there for selection to apply to?
Before Sun and Microsoft start evangelizing an identity management scheme to the rest of us, perhaps they need to sort out their own schizophrenia.
Is that why their announcement is incoherent?
I read the announcement and I read the PDF and I have to say that I know about as much as I did before I started. Can someone decode the acronyms and trademarks and explain just what this Last Great Single Sign On is really about?
You seem to have read my message as making the exact opposite of the point that I was intending to make. I apologise for the confusion, and I'll try and clear it up.
First of all, I was contrasting the Nickelback and Waltzing Matilda examples with Paul Simon to hilight the main difference between the Harrison case and OCRemix... and that is that Harrison didn't credit his source, and OCRemix's members do.
Your Paul Simon quote implies that he might have got permission.
I'm sure he got permission, and I would be quite surprised to learn otherwise... or that he hadn't paid for the rights to use Los Incas' music. I'm not implying Paul Simon did anything wrong. What I'm getting at is that there's already all kinds of precedent for how the legal system deals with the direct use of another artist's recorded music in a new work.
But of course that precedent doesn't let OCRemix off the hook at all. Quite the contrary: when you have explicitly credited the original work you're in a whole different legal situation than when you're just dealing with music that "sounds the same". There's a whole lot of nonsense going around about remixes, but nobody speaking from experience suggests that remixes are exempt from paying for the right to use their source material. That's why the recent release of a NiN track in GarageBand format explicitly for amateur remixing is such a big deal, and why the silence on the part of Square and others shouldn't be considered approval.
That's unacceptable when you take into account that most of the music was written for and preformed by a Z80.
Hey, most of the music out there was written and performed on instruments that had NO CPU AT ALL.
And, actually, wasn't most of the music written for and performed by a 6502 or 65816, sometimes assisted by a synthesizer chip like an AY38910 or SPC700? The only Z80 in the Nintendo lineup was in the Gameboy.
The world will never know what really happened inside Harrison's head, because musicians can't create the kind of "chinese wall" between the music they listen to and the music they create. It's almost impossible to write music without being derivitive, and without occasionally "ripping" themes and tracks.
The infamous "Nickelback vs Nickelback" remix going around the net is the perfect example. There's two different songs that "everyone" knows have basically the same music. Except, if you start doing that it's amazing the things you can make line up, particularly in pop/rock where there's probably only ten basic beats that 90% of the songs use.
Besides, you can sing any of the lyrics to "Waltzing Matilda".
This has nothing to do with OCRemix, because the OCRemix remixes all explicitly acknowledge where they got their material from. This is more like Paul Simon taking the music of "If I could..." from Los Incas version of "El Condor Pasa" *. There's no secret "inspiration" involved, if anyone's going to sue they're not going to have to wait for a judge to decide if they sound the same, legal or not it's all out in the open...
* I was in Paris in 1965, right before Simon and Garfunkel broke. I was roaming around Europe by myself, doing folk stuff. It was there I met Los Incas at a concert. I was booked, and they were booked, and that was the first time I had ever heard South American music. They gave me an album of their stuff, and "El Condor Pasa" was on the album. The Simon and Garfunkel record of "El Condor Pasa" was recorded over that preexisting track. So that's where it all comes from, and the notion was, if I liked the music, if it sounded good to me, it was popular. For me there was really no distinction between one culture and another. -- Paul Simon
Chrono Cross has some of the best "music to hack to", which is why Yasunori Mitsuda is the top artist on my Audioscrobbler page. Though I guess if I had it all tagged by Composer instead of Performer Bach would be #1.
Yes, I've seen that link. If all the "widget security model" means in Dashboard is that it pops up a one-time dialog, it shouldn't even be enforced by Dashboard. All it does is create an illusion that widgets are somehow "safer" than other classes of applets... and Apple themselves have already fallen for the illusion.
As I understand it: whether you declare these flags in your plist or not, you can't open a Widget in an arbitrary WebCore environment and get any of these rights. Only Dashboard or another front end that adds the same capabilities to its instance of WebCore can give you those rights. And THAT restriction is the important one, from the point of view of real security. Does that fit with what you know?
In my opinion installation of Widgets should be handled in very much the same way as installation of screen savers.
That's a very good way of putting it. Nobody would consider a screen saver to be a "safe", and yet installing a screen saver is by itself little more dangerous than installing a Widget: it doesn't do anything until at a later time you select and run it. A better analogy might be an iTunes Visualiser because someone might have the Random Screen Saver selected, but you've got the fundamental principle right: all these plugins... Widgets, iTunes Plugins, Internet Plugins, Audio Units, and so on... from a security perspective they're all applications. The fact that Widgets are implemented using HTML doesn't change that, and they should no more be treated specially by Safari than anything else for which opening it is equivalent to installing an application.
Slashdot Mirror
Microkernel is not about what space software runs in, it's about how the components that make up the system fit together. Among other things, this means having an API based on communicating between components (whether that's message queues, rendezvous, or whatever), and in fact that's MUCH more important than whether components are inside or outside the kernel... in fact a lot of older microkernel designs didn't HAVE a distinction between "in the kernel" and "outside the kernel"... that abstraction is really part of the security model of the system.
Linux seems to use a separate API for just about every pair of subsystems that need to communicate. It's modular, yes, but it's not even vaguely microkernel-like.
It is based on Mach with a BSD compatibility layer
It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.
Dashboard's "warning" to a user on newly-installed widget launch is a simple yes/no proposition without any indication of the access sought by the widget.
The fact is, Dashboard shouldn't be doing this check at all. The check implies that Dashboard is a "safe" environment, and it's not any such thing, so all it does is provide an illusion of security that encourages people to treat Widgets cavalierly... and it's truly ironic that the first victim of this illusion is Apple themselves. Same thing with Amnesty Widget Browser. The whole point to the way these programs work is that they provide a NON-sandboxed environment that can be used for Webcore scripting, without weakening the sandbox in Webcore itself.
This "security prompt" in Dashboard is another baby step down the dark path that Microsoft took almost a decade ago. It's a bad idea... they need to step back and ask whether they should even be treating Dashboard any differently from any other application environment.
Because you have to start somewhere, and you might as well start where you get the most bang for your buck.
:)
If you really want your music in a Windows-only format, I suppose you can always burn it to a disk from iTunes and then rip it in WMA. That's a lot less hassle than Mac users have to go through to play the games themselves.
Is it just a techinical issue that it is easer to add a unique ID to each disk by gluing on an RFID than to write it to the disk?
That, and it's harder for Joe Schmoe to create an RFID-equipped disk in his laptop. But the real protection is having the disk "phone home". And they've already started doing that.
Now how about just frying the RFID chip on the DVD
Congratulations, now you no longer have a key to decode the DVD.
I don't see a reason for a spyware program to be given permission to do http or any other requests to machines outside of my PC.
That's nice. You can probably do a really good job of keeping well-behaved applications from getting to the Internet that way. You have absolutely no chance of keeping a malicious applicaton in check that way. "Hey, I can't get to the Internet", thinks the application. "Let's see, there's Internet Explorer, it has access to the Internet. I know! I'll install myself as an internet plugin" (pause for special effects as the application hides itself in your web browser) "ah, that's better, now that I'm Internet Explorer, I can do anything again..."
So long as there's not many people using tight firewalls like this, you'll be OK. Once a lot of people start doing it, though, the spyware authors will notice, and they'll just add tricks like this to their collection. Or they'll turn the firewall off. Or they'll hide themselves in a driver and talk to the real TCP stack beneath the firewall, inside the kernel. Once they're executing on your computer, the only protection is to be a little bit tougher to exploit than average...
It's like the joke about the two hikers who are attacked by a bear. One of them starts running, while the other yells "you can't outrun a bear!" The first one answers, "I just have to outrun you!"
As long as you run faster than MOST people, you're OK. But to solve the spyware problem, so that people won't even TRY to get into your computer whether they can actually do any spying or not, you have to arrange things so that MOST people are running faster than MOST people.
"And this is, of course, impossible"
The goal, then, isn't "keep it from phoning home". It's "keep it out of the computer in the first place". Luckily, that's an easier problem... IF you're prepared to forgo the pleasure of installing every random game or applet you run across on FilePile...
As a Java developer for the past 7 years, can someone remind me as to how Java will benefit from being open source?
It's not whether it's open source or not, it's whether it can be shipped with an open source OS or not. Right now the biggest problem Java has is that when you get your BSD or Linux system set up, you can just click buttons in the installer and you're good to go.
Unless the packages depend on Java, then you have to download Java from Sun's website (which can be really annoying when you're behind a hard firewall and you weren't expecting this) and THEN go back and install them.
So I don't care if Java is the #1 development environment for ANYTHING, right now it's just a royal pain in the ass.
If Sun wants to keep people from reverse-engineering and fragmenting Java, they need to figure out how to fix their licensing so people can just treat it as something else that ships on their Fedora or FreeBSD or whatever CDs. I don't care how they do it, or what face-saving games they have to pull, I just want to stop getting that "oh no not again" feeling when I see that some program I want to use is based on Java.
Why should I, as an end user, download and use Apache's Harmony instead of using SUN's "real" Java.
As an end user... you won't have to go to anyone's website and accept a clickthrough license to download Harmony. It'll be there on your system, like Perl and bash are.
I don't care if they open Java at this point... I just want them to allow verbatim redistribution of their own j2se because I'm getting really tired of having to download the right version of Java separately from Sun's site when I need to set up Java-based packages on Open Source UNIX.
That's what's more or less burned out whatever interest I ever had in Java. It's just another checkbox to slow down setting up a production system.
A firewall can't protect you from actions by programs inside the protection domain of the firewall. A spyware program could communicate with the outside world by techniques as subtle as coding them in the name if HTTP fetch requests, so even if the firewall was a hard proxy and didn't do more than a lookup of the name (say, to see if it's a blocked IP range), it could still call home through the DNS requests the proxy made.
But it requires more knowledge than most users currently possess.
Which is precisely why the responsibility should be placed on the browser developers. Where they have committed to a comprehensive sandbox (for example, in Firefox outside the XPI installation mechanism) people have accepted it AND the system's overall security has been good without any need for annoying scary dialogs. Where they haven't (for example, Safari's "open safe file" mechanism) they've had repeated problems, and users have complained that fixing the problem would be inconvenient for them.
I've had someone ARGUE with me that HE should be an exception to my "No Outlook" rule... WHILE I was sitting there cleaning his computer after he infected it through Outlook. You're right, the users can't be expected to understand the details of security. What's depressing is that the vendors don't seem to understnd either.
Apple, KDE, Mozilla, Microsoft, they all need to stand up and commit to a comprehensive sandbox. They need to commit to NEVER passing an object outside the sandbox, and requiring all plugins, handlers, helper applications, and so on to register explicitly with the browser... and stop assuming that an application designed for use from the shell/Finder/Desktop is safely sandboxed.
[ActiveX] has allowed a LOT of vendors to build browser-based apps to do stuff rather than have to build actual programs.
The really interesting thing here is that the ActiveX based applications aren't any less complex than a standalone application that injected the ActiveX components as plugins inside a customized HTML control, and they're no more convenient for the user than downloading an application would be because right now it's a LOT harder for a user to figure out how to selectively grant the rights to the webpage that's running the applets than it is to download and install an application. It would be possible for Microsoft to completely eliminate the pain of locking down ActiveX simply by providing a simple conversion kit that created this application with the ActiveX plugins bundled into it, and removed the ActiveX launch capability from the common HTML control. Then the user would download the application as an application, and install it as an application, and these applets would exist IN THAT APPLICATION but they, as well as other ActiveX components out there on the web, would be safely ignored by the common HTML control everywhere else in the computer.
At the same time applications like Windows Explorer or Software Update would have to be modified to do the same thing with their custom extensions to the HTML control.
The other "extra rights" (or rather, the code that implements these capabilities) that IE gives to local pages, like running local scripts, could also be injected by the controlling applet the same way.
So long as they didn't then put in code for IE to automatically install these "Windows Dashboard Widgets", they'd be perfectly safe. This is how KDE's Konqueror handles potentially unsafe extensions (they call them I/O slaves). It's how Dashboard adds them to WebCore (well, except for Safari installing them automatically... Safari doesn't even need to know they exist). It's safe, secure, convenient, and I really expected Microsoft to come up with something equivalent SEVEN YEARS AGO after the first HTML-based malware showed up. But, no... and now it's hard for them to go back.
I wrote: "Any application you hand off a document to has to be one that has an equal commitment to maintaining that sandbox. If the user wants to do anything like that, they have to..."
Then I changed the sense of the preceding sentence when I was previewing it, and didn't notice that changed the meaning of this one. What I meant to write was "If the user wants to do anything more than that, they have to..."
Let's pretend for a moment that this would actually work. It's not possible to get people to implement it.
It's hard enough to get any of the browser teams to commit to implementing a complete sandbox, even though that could be done without inconveniencing the users.
It's hard enough to get users to adjust the sandbox that they're already using so that it's as complete as possible, even though doing so imposes very little invenvenience.
Getting users to go through a lot of inconvenience to create a new account to run their browser in, that's really tough.
But even if you could do it, it wouldn't be effective.
A restricted account could still be used to compromise their privacy, it could still be used to destroy data they consider important... their bookmarks, information maintained on websites they connect to, and so on.
And that's assuming it would remain restricted: once I can run native code on your machine, getting out of a restricted environment is just a matter of time. It's easiest on Windows, of course, but even your typical UNIX or Mac OS X box has all kinds of mechanisms that a restricted account can use to extract information from your "real" account, or launch code (directly or through a boobytrap) into the "real" environment.
The only "restricted environments" I have used that I would consider secure enough to not treat malware running in that account as an immediate threat, apart from physically separate boxes, are FreeBSD Jails or completely emulated systems (VMware, Virtual PC, etc).
But we do know one thing that does work very well. And that's having a sandbox that has no holes in its design. That means there's no holes that the developer's reluctant to close, and no holes that users are reluctant to see closed. That means that any holes that do occur are bugs, and as such can be quickly fixed without embarassment and without discouraging users from applying them.
It's not perfect, but it works much better than a whole sandboxed account, and it's much easier to implement and MUCH more convenient.
So: the first absolute requirement for building a secure web is for the browser manufacturers to commit to a completely closed sandbox. That means there is no mechanism inside the sandbox to get outside the sandbox even as far as to see information stored about other websites. That means: no XPI installers, no ActiveX or Active Scripting, no "open safe files after download", no use of "Desktop" applications to open documents (even if you think the document is local), nothing. Any application you hand off a document to has to be one that has an equal commitment to maintaining that sandbox. If the user wants to do anything like that, they have to explicitly download the document and so move it outside the sandbox, and THEN explicitly open it in the unsandboxed environment. Those two steps must never be shortchanged.
What does that mean to the user, then?
Not much, in most cases. For Firefox users that means they'll have to download XPI files and then load them from the menu or their desktop file manager. For Safari users, no more "open safe files", and no more warnings the first time they open an app because the browser won't ever be opening apps behind their back. For Windows, there would be a bigger impact: a few tools like Software Update would be separate applications, but the bigger impact is that some third-party applications would need to be redesigned to use the new safe API.
Windows, I can see their reluctance. The rest? I don't get it... they're not gaining all that much by having a leaky sandbox, and the fact that even such small leaks can be exploited is sure a good argument for having at the very least no designed-in holes at all.
Evolution is not a guided process, there's no "better" state that species are evolving "towards". Evolution is a description of how selective pressures have an effect on a species over time. If we're selecting for something you think is detrimental in some larger sense, and not selecting for something you think is advantageous, that doesn't mean that evolution isn't happening. It just means there's no Great Hoohoo in the sky guiding it in any particular way.
The idea that there is a "Next Step" in evolution is just as religious a position as the idea that evlution doesn't happen. There's no big "steps" in evolution, just lots of little steps all happening at the same time in every possible direction, and the observation that some of these little steps will work out better than others.
That's it.
Everything else, from the whole concept of "species" on, is our attempt to impose order on something that doesn't really fall into the tidy boxes that labels like "species" apply to. Any attempt to extract meaning or to try and describe a "Next Step", or talking about changes in technology as if they have anything to do with evolution of the "species" other than how they change the way genes are selected for, are fundamental category errors.
Yes, computers evolve. Evolution is a process, and computers have all the requirements to be subject to that process. They have inherited characteristics that are encoded in the software that controls them. Their software changes over time as a result of changes in their environment. But the evolution of computers is no more (and no less) the evolution of the human species than the evolution of the horse and dog, once humans started treating them as tools, are part of the evolution of the human species.
Finally, there are no "bad genes", there are just genes that are selected for or selected against. The gene pool has never been "clean" or "dirty", it's just been more or less variable. Right now it's going through a period where there's more variations in it, but that happens normally in any population and is itself an essential part of the process of evolution... without variations, what is there for selection to apply to?
Before Sun and Microsoft start evangelizing an identity management scheme to the rest of us, perhaps they need to sort out their own schizophrenia.
Is that why their announcement is incoherent?
I read the announcement and I read the PDF and I have to say that I know about as much as I did before I started. Can someone decode the acronyms and trademarks and explain just what this Last Great Single Sign On is really about?
I wrote: Harrison didn't credit his source
Of course I should have written "Harrison didn't credit his alleged source".
Sorry about that.
You seem to have read my message as making the exact opposite of the point that I was intending to make. I apologise for the confusion, and I'll try and clear it up.
First of all, I was contrasting the Nickelback and Waltzing Matilda examples with Paul Simon to hilight the main difference between the Harrison case and OCRemix... and that is that Harrison didn't credit his source, and OCRemix's members do.
Your Paul Simon quote implies that he might have got permission.
I'm sure he got permission, and I would be quite surprised to learn otherwise... or that he hadn't paid for the rights to use Los Incas' music. I'm not implying Paul Simon did anything wrong. What I'm getting at is that there's already all kinds of precedent for how the legal system deals with the direct use of another artist's recorded music in a new work.
But of course that precedent doesn't let OCRemix off the hook at all. Quite the contrary: when you have explicitly credited the original work you're in a whole different legal situation than when you're just dealing with music that "sounds the same". There's a whole lot of nonsense going around about remixes, but nobody speaking from experience suggests that remixes are exempt from paying for the right to use their source material. That's why the recent release of a NiN track in GarageBand format explicitly for amateur remixing is such a big deal, and why the silence on the part of Square and others shouldn't be considered approval.
Got some good music, though.
That's unacceptable when you take into account that most of the music was written for and preformed by a Z80.
Hey, most of the music out there was written and performed on instruments that had NO CPU AT ALL.
And, actually, wasn't most of the music written for and performed by a 6502 or 65816, sometimes assisted by a synthesizer chip like an AY38910 or SPC700? The only Z80 in the Nintendo lineup was in the Gameboy.
The infamous "Nickelback vs Nickelback" remix going around the net is the perfect example. There's two different songs that "everyone" knows have basically the same music. Except, if you start doing that it's amazing the things you can make line up, particularly in pop/rock where there's probably only ten basic beats that 90% of the songs use.
Besides, you can sing any of the lyrics to "Waltzing Matilda".
This has nothing to do with OCRemix, because the OCRemix remixes all explicitly acknowledge where they got their material from. This is more like Paul Simon taking the music of "If I could..." from Los Incas version of "El Condor Pasa" *. There's no secret "inspiration" involved, if anyone's going to sue they're not going to have to wait for a judge to decide if they sound the same, legal or not it's all out in the open...
Pachelbel's Ganon. Mmmmm.
Chrono Cross has some of the best "music to hack to", which is why Yasunori Mitsuda is the top artist on my Audioscrobbler page. Though I guess if I had it all tagged by Composer instead of Performer Bach would be #1.
Yes, I've seen that link. If all the "widget security model" means in Dashboard is that it pops up a one-time dialog, it shouldn't even be enforced by Dashboard. All it does is create an illusion that widgets are somehow "safer" than other classes of applets... and Apple themselves have already fallen for the illusion.
As I understand it: whether you declare these flags in your plist or not, you can't open a Widget in an arbitrary WebCore environment and get any of these rights. Only Dashboard or another front end that adds the same capabilities to its instance of WebCore can give you those rights. And THAT restriction is the important one, from the point of view of real security. Does that fit with what you know?
In my opinion installation of Widgets should be handled in very much the same way as installation of screen savers.
That's a very good way of putting it. Nobody would consider a screen saver to be a "safe", and yet installing a screen saver is by itself little more dangerous than installing a Widget: it doesn't do anything until at a later time you select and run it. A better analogy might be an iTunes Visualiser because someone might have the Random Screen Saver selected, but you've got the fundamental principle right: all these plugins... Widgets, iTunes Plugins, Internet Plugins, Audio Units, and so on... from a security perspective they're all applications. The fact that Widgets are implemented using HTML doesn't change that, and they should no more be treated specially by Safari than anything else for which opening it is equivalent to installing an application.