Removing DRM from Vista would only result in users being unable to playback DVDs, BlueRay, and other DRMed media.
If you are unhappy with DRM (who isn't?) go bug your government, senator etc.
You are not still buying into that Peter Gutmanns BS are you? If so then I have some stocks left for a very popular tower in central Paris. I will let you have them really cheap, their high profile considered.
UAC will only redirect read/write operations for files and registry for virtualized processes. Apps compiled with a proper manifest are assumed to be well-behaved. Only older apps without a proper manifest is assumed to be "broken" and to keep them running the write operations will be redirected per user. It is by no means a perfect solution, but it does allow some apps to run which would otherwise have failed badly.
Personally, I like to think of myself as a continuously modified script, running a bio-mechanical machine.
Ok, then open PowerShell (or cmd - but that sucks) with the "run as administrator".
Also, as an admin you *do* have the right to write/modify those files (when properly elevated), although you *may* want to remove the "read only" attribute from the files first;-)
What about applications that have system-wide (NOT per-user) configuration that is changed very infrequently?
They go into "\Users\All Users\" which is a symlink to (usually) "\ProgramData".
Or they go into the registry (if it is not large binary data). Yeah, I know this is/. and everyone is supposed to hate the registry. But that's the standard, anyway.
What's the problem with me, the system administrator, editing those so that when the service next reads its config it can grab them?
What's wrong is that it is a *nix paradigm used on a non-nix platform. When in Rome...
Silently redirecting things to a secret, non-shared location is just wrong.
Perhaps. It was merely intended to help those app which had blatantly been ignoring coding-standard for years. Really, using "program files" for sharing users' data is pretty horrific, once you think about it. It was always an abuse.
What is generally discussed (and ridiculed) on/. is what is termed UAC prompts
UAC prompts are merely the visible part of UAC. It's no surprise that the most important parts are hidden beneath the surface (and why it is so stupid to turn it off).
UAC introduces a concept called process integrity. One can consider it a subdivision of user accounts as it works by modifying the security token associated with the process.
If a process is running in "low integrity" it has virtually no rights to file system, registry database, IPC etc. It may render on the designated desktop and may also use an isolated storage. It is important to point out that because this sits in the security token, it is an intrinsic protection. IE7 and Chrome leverages low integrity mode, so even if an "exploitable" bug is found in IE7/Chrome or in an addin, this presents a formidable barrier to compromising the machine or even to get to sensitive or personal data.
Because a low integrity process is so limited, the browsers cannot even download files, except to their local, isolated storage. Therefore UAC calls for a separate broker process which drives the familar "save" dialog and reaches into the isolated storage and marshals the downloaded files out to userland.
Aside: When Vista was compromised at last years pwn2own it was through a custom broker process which Adobe had bundled with Flash. In their wisdom they had allowed the broker process to launch external programs. They needed at to perform updates or something. Go figure.
Other integrity level are normal and elevated. In normal integrity level you cannot perform any actions which requires administrative privileges. In that case you need to elevate your privileges. That is where the UAC prompt comes in.
To summarize, while UAC addresses some of the same concerns as SELinux, it does so by reigning in the process as opposed to SELinux/AppArmour which reigns in applications by defining profiles with allowable actions per app. I suppose you could build something like UAC by using SELinux and inspecting the process, but I'm not aware that this is what SELinux does.
One obvious difference - an advantage to UAC if you will - is apparent in the case of browsers. If a browser needs to be able to upload and download files, it must have a policy defined for that under SELinux. Hence, a compromised browser can also read/write files from/to those same locations without the users' knowledge or consent. That's not possible with UAC and IE7/Chrome. There is only one way (if UAC is not buggy) to have files transferred, and that's through the broker process. Assuming that process is not buggy (looking at you, Adobe) the user *will* know when a file is being downloaded and saved.
My wife stole my old cool acer ferrari 3400 when I got a new dell. It wasn't that it was faster than what she had, but she really liked the color of that thing (all shiny Ferreri red).
Anyways - she runs Vista Business. She's on a user account and she does not know my admin pw. She went a good 6 months using it every day before she experienced the UAC prompt. She had to install a new homebanking app.
I'd say it works as intended. For everyday work - even with Visual Studio 2008 - I don't get UAC prompts. (I did with VS2005, though)
Yeah - but apparently some of the less-technical MS brass preempted the engineers with a knee-jerk reaction something in the line of: "There's nothing wrong; it is as it is by design; you asked for it; move along!"
What's significant here is that they actually did an about face very shortly thereafter. Presumably when the real engineers and UX experts had told the brass what they thought.
Which is actually pretty significant as it hints that the actual MS engineers powers are growing.
And explanation of how what Windows does is different from what KDE, Gnome or OSX do.
From the style of the statement I'd gather that it is not something Windows does or does not do. It's about something Windows is not: Linux. Very mature.
I *have* run into problems with the Program Files folder in Vista. Some applications need to write in there and sometimes *I* want to write in there,
NO you do not want to write into program files. UNLESS you are an installer. Period.
YES some programs do - buggy programs violating coding practices for years. For THOSE there is another part of UAC (it is not all about prompts) called file system virtualization. As the name gives away it virtualizes some of the file system, such as "program files" and "windows". When switched on it lets the program believe it writes to the folders, while in reality the files are being stores below the current users folder below "Users". This little trick cheats some older apps into running, even though they perform the stupid action of writing into the hand-off folders. This little feature can be configured in the app's manifest.
Problem is that they assume that when the security bulletin says that successful exploitation will allow the attacker to run as the current user, this does not mean that the attacker will be able to run as admin, even though the user is an admin.
Indeed (with UAC on) IE7 runs in protected mode which is a "sandbox" where the users' security tokens have very limited rights, thus intrinsically protecting the OS.
The Vista protected mode effectively runs the process as a limited user, even though it preserves the users identity.
Even if the attacker can somehow trick the browser or user into downloading a malicious file and start it, it will still need elevation (yes, the cancel/allow thingy) to assert admin privileges.
So, another way to spin this would be "Vista UAC protects against exploitation of 92% of vulnerabilities".
sed is pretty much covered by the script language. Text files are by default processed as a "sequence of strings". Through the pipeline those strings can be changed, filtered; new string can be inserted etc.
First thing to realize about awk is that it was really only necessary because bash pipelines are text-only. You need awk, cut etc. to "find" the correct columns and emit something as a result.
Once you move to an object-based pipeline the need for something like awk disappears, at least for combining commands.
Example: The PS ls command is an alias for the Get-ChildItem cmdlet. Executed on a filesystem it will return a sequence of DirectoryInfo and FileInfo objects. Standard formatting rules (the ToString method) of those objects ensures that if they are written to the console they will appear as (somewhat) familar ls lines.
But you can also pipe then thorugh another cmdlet, e.g. filtering on size *without* needing to parse the "filesize column":
ls | ?{ $_.Length -gt 30kb }
? is an alias for the Where-Object cmdlet.
{... } is a script block
$_ is the FileInfo/DirectoryInfo object
Length is a property of that object
-gt is the "greater than" operator
30kb should be intuitive
Forgot: The BIG problem with ActiveX is that it has a very poor security model. Because it really is binary code executing on your machine it can do everything the executing account can do. Which is why ActiveX have got such a bad security rep.
MS has progressively restricted ActiveX controls to the point where they are actually comparable to plugins (which share the same security issues). You now have to permit websites to run even the standard ActiveX controls.
Most of the problems around MSIE in terms of standards compliance have been fixed in IE 8. The other half of the problem, though, is ActiveX
They sure have good CSS 2.1 compliance with IE8. The other half of the problem is not ActiveX, though, it is EcmaScript (javascript) compliance and DOM binding compliance. It is not too much of a problem if you use one of the many good JavaScript libraries, but all of those have had to build provisions specifically for IE because of the poor compliance.
... ActiveX, which other browsers cannot implement on platform other than Windows. If ActiveX where implemented aa true open standard, without moving targets, without reliance on the underlying platform, then it would be possible to produce browsers on competing platforms that supported ActiveX.
Since Microsoft has deliberately chosen to keep certain details of ActiveX a complete an utter secret and tie it into Windows, there's no way for anyone to implement on a non-Windows platform.
This deliberate tie-in is an effort by Microsoft to create vendor lock-in. Microsoft can either compete fairly or they can fight dirty. They've consistently chosen to fight dirty and until they stop, they're always going to face criticism for it.
ActiveX is really COM objects. COM is a binary Windows standard for object oriented APIs. Incidently it inspired Gnome which uses a binary standard very much like it. There is *nothing* secretive about ActiveX. There is tons of documentation. Anyone can implement ActiveX objects, anyone can implement ActiveX containers. The problem is that it is exactly a binary standard. With no virtual execution system involved objects are always tied to the platform. It is compiled code calling Windows APIs. That's why ActiveX does not exist on other platforms. It should be possible to implement through Wine, though. Wondering is somebody already did it...
bash? No - Windows 7 comes with PowerShell. In many areas it is much more powerful than bash - and it is certainly a better "fit" for Windows than bash would be (PS is object-oriented and object-based and practically all of Windows API is now exposed as objects either through COM, WMI or.NET). Note, that is not saying that PS would be better for *nix than bash.
wget - System.Net.WebClient
grep - is the ? cmdlet (alias for Where-Object)
tail - is part of the select cmdlet (alias for Select-Object)
touch - is still an executable file - but you can also manage a fileinfo's attributes by simple assignments.
top - sort and select.
Windows is moving towards xml config files - not the line-based delimiter-of-the-day config files of *nix. Xml files are arguably better for describing many more complicated structures. They also are more bloated;-) . PS has support for reading/writing/manipulating xml files
Incidently, PowerShell treats the registry, certificate store, the PW function list etc. just as a file system. It means that to manipulate the registry you access registry keys/values just like directories/files - using the same commands.
Still drinking the Gutmann kool-aid? That myth has been thoroughly debunked. DRM does not come into play unless you play a DRMed media. In which case you would need decryption on *every* platform *including* XP.
It would be stupid if it was correct. However, that is why Vista also has a unique memory priority feature. It is exactly to ensure that a process with lower priority memory requirements (such as the cache, readyboost, disk defrag, defender etc) does *not* page out normal priority memory. What's stupid is how some people are all prepared to make all kind of assumptions about Vista and then use those - often false - assumptions to knock it.
Somehow I doubt that you have a lot of experience with C#. If you had you would know that:
.NET 3.0 and.NET 3.5 are not really new versions, they are additions to the 2.0 platform. The 3.0 added stuff like WPF, WCF, WF, CardSpace. The 3.5 added LINQ. *ALL* of it still runs on the 2.0 runtime. Both additions leverage the extensible configuration of 2.0 to configure new modules. In other words your claim that it "Every time MS puts out some patch...stuff breaks" is totally and utterly bunk. Admittedly MS used a stupid versioning for this.
Even.NET 1.0 and 1.1 assemblies continue to run on the 2.0, 3.0 and 3.5 versions (which are all just the 2.0 runtime, per above).
There is no difference between.NET datatypes on 32 and 64 bit platforms. If you are calling native APIs you may want to check whether you use P/Invoke correctly.
There is no such thing as "3.5 binaries". You should know that. There are some 3.5 specific assemblies (LINQ) which are 2.0 binaries.And yes they *do* run on 2.0.
You need to find another explanation for why your stuff breaks. Stop blaming patches. It just shows your incompetence.
Take a look at IE protected mode. Vista allows processes started by the user to run with different "integrity levels", effectively subdividing the user account into multiple ad-hoc roles while preserving the identity. IE protected mode is run in "low integrity" - where Vista on intrinsic level protects against modifications to the file system, registry, network access etc.
Every plugin is executed in the same process under the same restrictions. IE offers a standard broker process which can be requested when a file has been downloaded (into a protected cache) and needs to be moved to the user-selected download location. The browser process has very limited capabilities.
If a plugin needs more advanced access than what is provided by his broker process then it must install and invoke its own broker process, as the plugin itself runs under the restricted mode. Flash does this, circumventing the standard IE broker process. It was a bug in the Flash broker process (along with a Java vulnerability)which enabled a security researcher to execute a program on the Vista in the pwn2own contest.
Presumably Adobe will use the same approach on other browsers with a similar model such as Chrome. That is why the security researcher was adament that the Flash flaw could have been used against *any* of the OSes.
Chrome actually *also* uses the Vista low integrity feature. Presumably Google will emulate this Vista feature by using separate accounts on other OS'es which do not have process integrity levels (or other role subdivisions of user accounts) as a standard feature.
Chrome does use separate processes (in low-integrity mode) for each tab. That does not provide more security against a rouge process taking over the machine, but it does provide more robustness and protect the individual tabs against other tabs going rogue because of browser bugs.
You could have just used Windows SteadyState
Hint: Can revert harddisks state at each reboot while still allowing windows update to run and make persistent changes, can leverage much of the same policies (restrictions) Windows allows in a domain, but without the central AD. Among other things.
HACKED BY BENJYMOUSE HACKED BY BENJYMOUSE HACKED BY BENJYMOUSE
There, now I "hacked" slashdot the very same way. The "hacked" and "defaced" site is nothing more than submissions (like comments on slashdot) with "HACKED BY OVERLORD" text. No JavaScript injection, no SQL injection, no nothing. Some medias will go to any length to capture traffic. sheesh.
Slashdot Mirror
Removing DRM from Vista would only result in users being unable to playback DVDs, BlueRay, and other DRMed media.
If you are unhappy with DRM (who isn't?) go bug your government, senator etc.
You are not still buying into that Peter Gutmanns BS are you? If so then I have some stocks left for a very popular tower in central Paris. I will let you have them really cheap, their high profile considered.
UAC will only redirect read/write operations for files and registry for virtualized processes. Apps compiled with a proper manifest are assumed to be well-behaved. Only older apps without a proper manifest is assumed to be "broken" and to keep them running the write operations will be redirected per user. It is by no means a perfect solution, but it does allow some apps to run which would otherwise have failed badly.
Personally, I like to think of myself as a continuously modified script, running a bio-mechanical machine.
Ok, then open PowerShell (or cmd - but that sucks) with the "run as administrator".
Also, as an admin you *do* have the right to write/modify those files (when properly elevated), although you *may* want to remove the "read only" attribute from the files first ;-)
What about applications that have system-wide (NOT per-user) configuration that is changed very infrequently?
They go into "\Users\All Users\" which is a symlink to (usually) "\ProgramData".
Or they go into the registry (if it is not large binary data). Yeah, I know this is /. and everyone is supposed to hate the registry. But that's the standard, anyway.
What's the problem with me, the system administrator, editing those so that when the service next reads its config it can grab them?
What's wrong is that it is a *nix paradigm used on a non-nix platform. When in Rome...
Silently redirecting things to a secret, non-shared location is just wrong.
Perhaps. It was merely intended to help those app which had blatantly been ignoring coding-standard for years. Really, using "program files" for sharing users' data is pretty horrific, once you think about it. It was always an abuse.
Imagine that, as taken from the Apple iTunes/Safari/Quicktime playbook. Sneak in your other software when users update. Who'd thought that?
What is generally discussed (and ridiculed) on /. is what is termed UAC prompts
UAC prompts are merely the visible part of UAC. It's no surprise that the most important parts are hidden beneath the surface (and why it is so stupid to turn it off).
UAC introduces a concept called process integrity. One can consider it a subdivision of user accounts as it works by modifying the security token associated with the process.
If a process is running in "low integrity" it has virtually no rights to file system, registry database, IPC etc. It may render on the designated desktop and may also use an isolated storage. It is important to point out that because this sits in the security token, it is an intrinsic protection. IE7 and Chrome leverages low integrity mode, so even if an "exploitable" bug is found in IE7/Chrome or in an addin, this presents a formidable barrier to compromising the machine or even to get to sensitive or personal data.
Because a low integrity process is so limited, the browsers cannot even download files, except to their local, isolated storage. Therefore UAC calls for a separate broker process which drives the familar "save" dialog and reaches into the isolated storage and marshals the downloaded files out to userland.
Aside: When Vista was compromised at last years pwn2own it was through a custom broker process which Adobe had bundled with Flash. In their wisdom they had allowed the broker process to launch external programs. They needed at to perform updates or something. Go figure. Other integrity level are normal and elevated. In normal integrity level you cannot perform any actions which requires administrative privileges. In that case you need to elevate your privileges. That is where the UAC prompt comes in. To summarize, while UAC addresses some of the same concerns as SELinux, it does so by reigning in the process as opposed to SELinux/AppArmour which reigns in applications by defining profiles with allowable actions per app. I suppose you could build something like UAC by using SELinux and inspecting the process, but I'm not aware that this is what SELinux does.
One obvious difference - an advantage to UAC if you will - is apparent in the case of browsers. If a browser needs to be able to upload and download files, it must have a policy defined for that under SELinux. Hence, a compromised browser can also read/write files from/to those same locations without the users' knowledge or consent. That's not possible with UAC and IE7/Chrome. There is only one way (if UAC is not buggy) to have files transferred, and that's through the broker process. Assuming that process is not buggy (looking at you, Adobe) the user *will* know when a file is being downloaded and saved.
My wife stole my old cool acer ferrari 3400 when I got a new dell. It wasn't that it was faster than what she had, but she really liked the color of that thing (all shiny Ferreri red).
Anyways - she runs Vista Business. She's on a user account and she does not know my admin pw. She went a good 6 months using it every day before she experienced the UAC prompt. She had to install a new homebanking app.
I'd say it works as intended. For everyday work - even with Visual Studio 2008 - I don't get UAC prompts. (I did with VS2005, though)
Yeah - but apparently some of the less-technical MS brass preempted the engineers with a knee-jerk reaction something in the line of: "There's nothing wrong; it is as it is by design; you asked for it; move along!"
What's significant here is that they actually did an about face very shortly thereafter. Presumably when the real engineers and UX experts had told the brass what they thought.
Which is actually pretty significant as it hints that the actual MS engineers powers are growing.
And explanation of how what Windows does is different from what KDE, Gnome or OSX do.
From the style of the statement I'd gather that it is not something Windows does or does not do. It's about something Windows is not: Linux. Very mature.
I *have* run into problems with the Program Files folder in Vista. Some applications need to write in there and sometimes *I* want to write in there,
NO you do not want to write into program files. UNLESS you are an installer. Period.
YES some programs do - buggy programs violating coding practices for years. For THOSE there is another part of UAC (it is not all about prompts) called file system virtualization. As the name gives away it virtualizes some of the file system, such as "program files" and "windows". When switched on it lets the program believe it writes to the folders, while in reality the files are being stores below the current users folder below "Users". This little trick cheats some older apps into running, even though they perform the stupid action of writing into the hand-off folders. This little feature can be configured in the app's manifest.
Problem is that they assume that when the security bulletin says that successful exploitation will allow the attacker to run as the current user, this does not mean that the attacker will be able to run as admin, even though the user is an admin.
Indeed (with UAC on) IE7 runs in protected mode which is a "sandbox" where the users' security tokens have very limited rights, thus intrinsically protecting the OS.
The Vista protected mode effectively runs the process as a limited user, even though it preserves the users identity.
Even if the attacker can somehow trick the browser or user into downloading a malicious file and start it, it will still need elevation (yes, the cancel/allow thingy) to assert admin privileges.
So, another way to spin this would be "Vista UAC protects against exploitation of 92% of vulnerabilities".
sed is pretty much covered by the script language. Text files are by default processed as a "sequence of strings". Through the pipeline those strings can be changed, filtered; new string can be inserted etc.
First thing to realize about awk is that it was really only necessary because bash pipelines are text-only. You need awk, cut etc. to "find" the correct columns and emit something as a result.
Once you move to an object-based pipeline the need for something like awk disappears, at least for combining commands.
Example: The PS ls command is an alias for the Get-ChildItem cmdlet. Executed on a filesystem it will return a sequence of DirectoryInfo and FileInfo objects. Standard formatting rules (the ToString method) of those objects ensures that if they are written to the console they will appear as (somewhat) familar ls lines. But you can also pipe then thorugh another cmdlet, e.g. filtering on size *without* needing to parse the "filesize column":
ls | ?{ $_.Length -gt 30kb }
Why don't you just do a regular ping? Jeez, anyone can come up with an artificially lame example in any language.
I agree that the name is lame. The technology is not, however.
Forgot: The BIG problem with ActiveX is that it has a very poor security model. Because it really is binary code executing on your machine it can do everything the executing account can do. Which is why ActiveX have got such a bad security rep.
MS has progressively restricted ActiveX controls to the point where they are actually comparable to plugins (which share the same security issues). You now have to permit websites to run even the standard ActiveX controls.
Most of the problems around MSIE in terms of standards compliance have been fixed in IE 8. The other half of the problem, though, is ActiveX
They sure have good CSS 2.1 compliance with IE8. The other half of the problem is not ActiveX, though, it is EcmaScript (javascript) compliance and DOM binding compliance. It is not too much of a problem if you use one of the many good JavaScript libraries, but all of those have had to build provisions specifically for IE because of the poor compliance.
... ActiveX, which other browsers cannot implement on platform other than Windows. If ActiveX where implemented aa true open standard, without moving targets, without reliance on the underlying platform, then it would be possible to produce browsers on competing platforms that supported ActiveX.
Since Microsoft has deliberately chosen to keep certain details of ActiveX a complete an utter secret and tie it into Windows, there's no way for anyone to implement on a non-Windows platform.
This deliberate tie-in is an effort by Microsoft to create vendor lock-in. Microsoft can either compete fairly or they can fight dirty. They've consistently chosen to fight dirty and until they stop, they're always going to face criticism for it.
ActiveX is really COM objects. COM is a binary Windows standard for object oriented APIs. Incidently it inspired Gnome which uses a binary standard very much like it. There is *nothing* secretive about ActiveX. There is tons of documentation. Anyone can implement ActiveX objects, anyone can implement ActiveX containers. The problem is that it is exactly a binary standard. With no virtual execution system involved objects are always tied to the platform. It is compiled code calling Windows APIs. That's why ActiveX does not exist on other platforms. It should be possible to implement through Wine, though. Wondering is somebody already did it...
bash? No - Windows 7 comes with PowerShell. In many areas it is much more powerful than bash - and it is certainly a better "fit" for Windows than bash would be (PS is object-oriented and object-based and practically all of Windows API is now exposed as objects either through COM, WMI or .NET). Note, that is not saying that PS would be better for *nix than bash.
Windows is moving towards xml config files - not the line-based delimiter-of-the-day config files of *nix. Xml files are arguably better for describing many more complicated structures. They also are more bloated ;-) . PS has support for reading/writing/manipulating xml files
Incidently, PowerShell treats the registry, certificate store, the PW function list etc. just as a file system. It means that to manipulate the registry you access registry keys/values just like directories/files - using the same commands.
Still drinking the Gutmann kool-aid? That myth has been thoroughly debunked. DRM does not come into play unless you play a DRMed media. In which case you would need decryption on *every* platform *including* XP.
Some of Intels Atom processors used in many netbooks are still 32bit.
It would be stupid if it was correct. However, that is why Vista also has a unique memory priority feature. It is exactly to ensure that a process with lower priority memory requirements (such as the cache, readyboost, disk defrag, defender etc) does *not* page out normal priority memory. What's stupid is how some people are all prepared to make all kind of assumptions about Vista and then use those - often false - assumptions to knock it.
Take a look at IE protected mode. Vista allows processes started by the user to run with different "integrity levels", effectively subdividing the user account into multiple ad-hoc roles while preserving the identity. IE protected mode is run in "low integrity" - where Vista on intrinsic level protects against modifications to the file system, registry, network access etc.
Every plugin is executed in the same process under the same restrictions. IE offers a standard broker process which can be requested when a file has been downloaded (into a protected cache) and needs to be moved to the user-selected download location. The browser process has very limited capabilities.
If a plugin needs more advanced access than what is provided by his broker process then it must install and invoke its own broker process, as the plugin itself runs under the restricted mode. Flash does this, circumventing the standard IE broker process. It was a bug in the Flash broker process (along with a Java vulnerability)which enabled a security researcher to execute a program on the Vista in the pwn2own contest.
Presumably Adobe will use the same approach on other browsers with a similar model such as Chrome. That is why the security researcher was adament that the Flash flaw could have been used against *any* of the OSes. Chrome actually *also* uses the Vista low integrity feature. Presumably Google will emulate this Vista feature by using separate accounts on other OS'es which do not have process integrity levels (or other role subdivisions of user accounts) as a standard feature. Chrome does use separate processes (in low-integrity mode) for each tab. That does not provide more security against a rouge process taking over the machine, but it does provide more robustness and protect the individual tabs against other tabs going rogue because of browser bugs.
You could have just used Windows SteadyState Hint: Can revert harddisks state at each reboot while still allowing windows update to run and make persistent changes, can leverage much of the same policies (restrictions) Windows allows in a domain, but without the central AD. Among other things.
HACKED BY BENJYMOUSE HACKED BY BENJYMOUSE HACKED BY BENJYMOUSE There, now I "hacked" slashdot the very same way. The "hacked" and "defaced" site is nothing more than submissions (like comments on slashdot) with "HACKED BY OVERLORD" text. No JavaScript injection, no SQL injection, no nothing. Some medias will go to any length to capture traffic. sheesh.