No one said laziness can never be solved, only that it's a security hole, which was exactly my point: Any security system has to take laziness into account. A good example of this is the Linux repository system, which has (somewhat) been adopted by Apple with the App Store -- it rewards laziness (getting your apps through a single, easy-to-use channel) with security (all apps in that channel have been vetted and signed).
You have only given one reason and its not a security one.
Actually, it is. Any security system that ignores human factors will not work when used by humans, or won't be used by humans, rendering it useless.
You do realise that shifting the liability onto the banks doesnt actually prevent the theft?
No, but it places the responsibility on those who are most necessary for resolution. If the liability was entirely on the consumer, banks and merchants would have little incentive to improve security.
Now, I would much rather have a bit more shifted back to the consumer, so they paid a bit more attention to stuff like this, but that's tricky -- I have to think that the competing companies which assumed more responsibility (directly or through merchants) would get more business.
Please define your vulnerability. If you are talking about the banks servers themselves being attacked...
No, I'm talking about the terminal the users are connecting to -- most likely their home PC, running Windows, right?
A trojan is actually way less than what's required, but let's go with that. All it has to do is intercept communication between the user and the bank, thus allowing them to intercept the transaction the user is trying to do, and instead perform a completely different transaction.
The only way that wouldn't work is if the entire scope of the transaction is on the little "air-gapped" device, which would be both inconvenient and inflexible.
Call me defeatist but I believe there is no way the whitehats can out software manoeuvre the blackhats with software only solutions.
So what do you suggest? Hardware?
The only permanent solution I can see is mass deployment of airgapped two factor tokens specifically for transaction authentication not generic OTP which the trojans are bypassing.
Oh. I was actually being sarcastic.
This won't work. The biggest reason it won't is convenience. Say one credit card company requires such a device, and another promises that they'll be liable for any damages from fraud. Which would you go to? If they both make that promise, what does the consumer gain from the device?
And even this would be spectacularly vulnerable, if you can't trust the host system through which you're accessing whatever you're accessing.
I find it increasingly difficult to justify the performance loss for running anti malware software for the ever diminishing protection offered.
I don't run it at all. It turns out the remedy is much simpler, saner, and cheaper than what you're suggesting. Just educate.
Our immune system has an advantage over virii and bacteria due to our greater cell specialization and intelligent response.
First of all, you're only half-right here. Our bodies evolve diverse ecosystems of bacteria, actually varying quite a bit from person-to-person. The difference is that when we transmit bacteria from person-to-person, we might make each other sick, but that's unavoidable and actually healthy, to an extent -- it boosts our immune response. Computer systems don't get smarter when they get owned, and the risk seems much higher. (It won't kill you, but it could ruin your life, and it could ruin many lives very quickly, while in first world countries, deadly epidemics are far less common.)
Also, Apple's approval process doesn't have to restrict users from having the option to install third-party software. It just has to provide a good, safe marketplace so that users can choose to only install Apple-vetted software.
its API isn't compatible with the original KHTML API,
Fair enough, but is the original KHTML API better? Especially seeing as KDE completely rewrote itself recently -- wouldn't that have been the perfect time to adopt Webkit? I even remember seeing a proof-of-concept KDE4 Konqueror that used Webkit.
and the HTML support is actually worse in some respects.
Citation?
for most of that time Webkit itself was closed source.
And Apple didn't get sued?
I mean, I can see Webkit being closed development and obnoxious -- I can see where if they just provided the source as a big blob, or a big bunch of patches, without version control history and proper documentation, KHTML would be leery of it. But I don't see how that makes it closed source, so I assume that's not what you're talking about.
Whenever I've compared the machines I would need with similar Dell or HP,
Still doing it wrong. Start with the Dell or HP and configure it how you need it. Then see if Apple has anything comparable.
I admit Apple isn't going to come to my house, but then I don't want Apple coming to my house.
Wait... what? Why not?
It certainly solves one main issue -- with my laptop as my main computer, and without another machine I could readily use as a workstation, any hardware issue is a potentially serious, fix it NOW issue -- but it's also bad when I'm without a computer for a week. When my last computer died, this is exactly what happened -- I ordered the new Dell almost immediately, but I still had to use a Mac for a week.
So if I just need something simple like the CD replaced, I'd much rather have the guy come to my house, take an hour or less to fix it, and then leave, rather than ship it off somewhere. Even overnight shipping isn't enough to make the turnaround less than an hour.
They simply aren't as large company as Dell...
So what? Dell doesn't do it themselves, they hire a local contractor.
I don't think they care but I don't know their policy. If it important to you, I'm sure you can look it up.
I probably will, at some point, especially if someone wants to pay me well to do Mac development. As it is, I don't really care.
You seem to be anti-Apple at all cost.
Actually, no, cost is what started this discussion. But with what they've done with the iPhone, and with Steve Jobs' personal hypocrisy about DRM, yes, I'm anti-Apple. However, I also try to be rational -- OS X is both pretty and powerful. I have serious issues with it, but I can see a personal preference towards it and away from Linux.
I'm not anti-linux or anti-pc other than just for myself, I simply don't like the look and feel of either.
That's fine, but it also lends a lot of credibility to the idea that you spent twice as much for shininess, glossiness, and translucency.
Also read TFS, though -- the issue isn't wiping the drive, it's attempting to completely reset it at a lower level than the disk blocks exposed as a linear block device.
To do that is always device-specific, which is why he's having issues.
It's not very fun having someone on the other side of the world lagging up your game, which they seem to love doing in Warcraft 3.
I'd blame WC3, then. There's a trivial solution: Use actual servers (including dedicated servers), and make it obvious who's the server. Server lists are apparently being phased out of newer games as too technical, but there's something to be said for getting a list of open games, sorted by latency, and then knowing that if your own ping time to that server holds, it'll be other people lagging, not you.
I owned a boxed copy of Half Life, and I remember being unable to play online for most of the weekend that Steam came out, because it decided to download a new copy of the game (which took several hours), and then the servers were too loaded for the authentication to work.
If that's Half-Life 1, well, Steam has improved massively since then. I don't play heavily, but I never have Steam refuse to let me.
I like knowing that I can dig out my old games and play them whenever I want.
That's one reason I like Steam. I don't keep old game installers around, and I certainly don't keep CDs around. I like that whenever I want to play Half-Life, even if it's a fresh Windows install, all I have to do is download Steam, login, and download Half-Life. Oddly, in the case of Half-Life itself, I don't even need the full game to be downloaded to start playing.
Now, true, I have no assurance that this will continue to work, but right now, it works a lot better than sticking strictly to the old version. If I cared, it would be pretty trivial to fix offline mode to work.
I know I never did. I buy games for me to play, not because I want to resell them. I'm perfectly happy to pay $50-60 for a good new game, and I have no expectation of ever selling it -- if it was good enough for the money and the time investment, it's likely good enough I'll want to play it again in 5-10 years for nostalgia's sake.
Prime example: Portal. Worth every penny, and get your own, I'd feel worse about selling my copy than I did about the Companion Cube.
Also, I do find Steam to be a fair trade -- but when given the choice, I'll usually buy a DRM-free version of a game, rather than the Steam-ified version. Better for the developers and better for me, unless I'm an idiot and lose the copy I had, in which case, better for the developers, since I'll buy a second copy. (There are few enough DRM-free Linux games that I feel an obligation to support them.)
Maybe I didn't read carefully, but I'm also assuming that it can be activated multiple times. If there's a hard limit on the number of activations, then yes, I'd call that restrictive and I'd start to have a problem.
Here's the test: try to run the game without signing up. If you can't do that then it is a restrictive DRM.
No, then it's DRM. DRM is by definition restrictive, sure, but it's also comparatively less restrictive than most other forms of DRM, so I think it is accurate to say that it's not "restrictive DRM" when comparing it to, say, anything from Ubisoft. Requiring a single activation is considerably different than requiring a constant Internet connection.
If Google were likely to do that, I would think there would be two other directions they could go instead:
First, why upgrade to IE9 when you can upgrade to Chrome?
Second, why limit it to the browser? Do the same to ISPs which are known to violate net neutrality.
I doubt any of this is likely, though. For one, anything Google does to block people is giving marketshare to Bing. And if both Google and Bing do it, the lost revenue would be more than a "meager sum" that Microsoft might be willing to pay.
To be fair, so long as people were refusing to upgrade from XP, and so long as XP didn't support HDCP, that was a large incentive for people to avoid requiring HDCP -- and that's only a good thing.
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
If referer-checking was non-trivial, so would any solution you propose, I would think.
Ah, but since shortly after the <img> we've needed a way to inform browsers of cases when the content should or shouldn't be displayed in mixed domain pages,
I think the point I'm trying to make is that it's not always obvious how to generalize something. Again, the obvious and dead-simple solution to hotlinking is referer-checking. It's not as if people were deliberately hotlinking other content at the time. I know that when I first discovered this problem, I noticed that referer-checking existed, so I shrugged and mentally categorized it as a solved problem.
In other words, it's a bit like asking why JavaScript popups were ever allowed -- because it wasn't obvious that this would be a problem until it was.
I'm not saying that all problems are unforseeable, I just respectfully disagree that this particular one was so obvious as to be "silly".
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
I understand. However, you said:
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
In other words, people with oddly-configured browsers may be vulnerable, and may allow rogue websites to abuse them or other websites.
Well, for images, it seems useless -- referer-checking is still enough to discourage someone from pasting that image, since the majority of people don't know how to disable referer, and certainly wouldn't want to. Depending how it's implemented, it could save you the bandwidth, too.
For clickjacking, if they disable JavaScript, it seems like they'd disable just about any realistic clickjacking attack.
If we have a way of telling the average visitor's web browser that displaying certain content is not recommended, then we have a solution that security minded folk will adopt quickly; Everyone else can choose to "upgrade" (or not) as they see fit.
Assuming that it's widely implemented and comprehensive, that it has no unintended consequences...
Nothing can prevent these "exploits" if a user chooses to disable the default (recommended) security features or use an older browser (or craft their own browser).
And yet, you were trying to claim that referer-checking was "broken" because users might change settings.
It wasn't always this way, and it doesn't have to be. HTML standards have been stagnant for quite some time now...
Seems they've been evolving at a relatively rapid pace, with HTML5, WebGL, and I think there's even some proper sound APIs now. Even so, they are rightly cautious, even the working groups like HTML5.
The fact that it is hard to add simple cross domain controls (that we've needed for several versions already) to the current/next standard is at least a bit silly, no?
Not really.
Think of it this way: One of the biggest complaints people from other platforms (like Flash) have about HTML is that things can break from browser to browser, even from version to version. If changes to the standard are done too quickly and carelessly, browsers won't bother to keep up, and potential web developers will get discouraged, both at all the standards that aren't supported, and at how hard it is for them to keep up with the new developments, or even keep their browser running.
Also, the less time there is to review a change, the more likely (I think) that you'd have to reverse the change later, or at least tweak it. An example of this is the current debate about the video tag. If they'd standardized on Theora, no one would've used it, and they'd have to re-standardize on h.264 when the patents expire anyway. Of course, if they standardized on h.264 without thinking, they'd have just as many problems.
In what way is it not? I mean, while Chrome uses GTK+, WebKit certainly supports Qt. In fact, Qt embeds WebKit! It's actually kind of comical -- thanks to Konqueror still using KHTML, I now have KHTML, two versions of WebKit, and at least one version of Gecko, all on the same machine.
Granted, but it does seem both amusing and frustrating as a user to find that KHTML has now become Webkit, which is now used in Chrome, with gtk instead of qt -- but Chrome is faster in every way than Konqueror, including launching faster, even on KDE.
So while I'd love to port it -- after all, the crown jewels of Chrome are WebKit and V8, neither of which is GTK-specific -- I don't know that it'd buy much.
WebGL is hardware-accelerated video. Audio benefits from hardware acceleration, but doesn't need it. It does, however, need some amount of software control, something more than "Play this file at roughly this time."
My point was, even with a wiki, unless it's doing some pretty crazy AJAX, wget -r is probably enough to get something workable. There'll be broken links, but they'll be to things you didn't need offline anyway.
OTOH, a webserver doesn't have to be that bad. Rubygems installs RDoc documentation by default, and 'gem server' on the commandline will fire up all the webserver you need. (It uses frames by default, but there's no reason it has to.)
I hate when people make that mistake. It's the Windows NT commandline. Whenever someone sees my bash prompt, they ask me if that's "like DOS", and I have to explain that no, not even close, that it's light-years beyond cmd.exe, which is light-years beyond DOS.
Slashdot Mirror
When a company promises it's liable for user stupidity, you pay for the stupidity of other users.
So you wouldn't actually compare the rates and find out if it's actually true?
Harder than dd/dban, that's for sure. Also looks unlikely to work on SD, but I don't know.
No one said laziness can never be solved, only that it's a security hole, which was exactly my point: Any security system has to take laziness into account. A good example of this is the Linux repository system, which has (somewhat) been adopted by Apple with the App Store -- it rewards laziness (getting your apps through a single, easy-to-use channel) with security (all apps in that channel have been vetted and signed).
You have only given one reason and its not a security one.
Actually, it is. Any security system that ignores human factors will not work when used by humans, or won't be used by humans, rendering it useless.
You do realise that shifting the liability onto the banks doesnt actually prevent the theft?
No, but it places the responsibility on those who are most necessary for resolution. If the liability was entirely on the consumer, banks and merchants would have little incentive to improve security.
Now, I would much rather have a bit more shifted back to the consumer, so they paid a bit more attention to stuff like this, but that's tricky -- I have to think that the competing companies which assumed more responsibility (directly or through merchants) would get more business.
Please define your vulnerability. If you are talking about the banks servers themselves being attacked...
No, I'm talking about the terminal the users are connecting to -- most likely their home PC, running Windows, right?
A trojan is actually way less than what's required, but let's go with that. All it has to do is intercept communication between the user and the bank, thus allowing them to intercept the transaction the user is trying to do, and instead perform a completely different transaction.
The only way that wouldn't work is if the entire scope of the transaction is on the little "air-gapped" device, which would be both inconvenient and inflexible.
Call me defeatist but I believe there is no way the whitehats can out software manoeuvre the blackhats with software only solutions.
So what do you suggest? Hardware?
The only permanent solution I can see is mass deployment of airgapped two factor tokens specifically for transaction authentication not generic OTP which the trojans are bypassing.
Oh. I was actually being sarcastic.
This won't work. The biggest reason it won't is convenience. Say one credit card company requires such a device, and another promises that they'll be liable for any damages from fraud. Which would you go to? If they both make that promise, what does the consumer gain from the device?
And even this would be spectacularly vulnerable, if you can't trust the host system through which you're accessing whatever you're accessing.
I find it increasingly difficult to justify the performance loss for running anti malware software for the ever diminishing protection offered.
I don't run it at all. It turns out the remedy is much simpler, saner, and cheaper than what you're suggesting. Just educate.
Our immune system has an advantage over virii and bacteria due to our greater cell specialization and intelligent response.
First of all, you're only half-right here. Our bodies evolve diverse ecosystems of bacteria, actually varying quite a bit from person-to-person. The difference is that when we transmit bacteria from person-to-person, we might make each other sick, but that's unavoidable and actually healthy, to an extent -- it boosts our immune response. Computer systems don't get smarter when they get owned, and the risk seems much higher. (It won't kill you, but it could ruin your life, and it could ruin many lives very quickly, while in first world countries, deadly epidemics are far less common.)
Also, Apple's approval process doesn't have to restrict users from having the option to install third-party software. It just has to provide a good, safe marketplace so that users can choose to only install Apple-vetted software.
its API isn't compatible with the original KHTML API,
Fair enough, but is the original KHTML API better? Especially seeing as KDE completely rewrote itself recently -- wouldn't that have been the perfect time to adopt Webkit? I even remember seeing a proof-of-concept KDE4 Konqueror that used Webkit.
and the HTML support is actually worse in some respects.
Citation?
for most of that time Webkit itself was closed source.
And Apple didn't get sued?
I mean, I can see Webkit being closed development and obnoxious -- I can see where if they just provided the source as a big blob, or a big bunch of patches, without version control history and proper documentation, KHTML would be leery of it. But I don't see how that makes it closed source, so I assume that's not what you're talking about.
Whenever I've compared the machines I would need with similar Dell or HP,
Still doing it wrong. Start with the Dell or HP and configure it how you need it. Then see if Apple has anything comparable.
I admit Apple isn't going to come to my house, but then I don't want Apple coming to my house.
Wait... what? Why not?
It certainly solves one main issue -- with my laptop as my main computer, and without another machine I could readily use as a workstation, any hardware issue is a potentially serious, fix it NOW issue -- but it's also bad when I'm without a computer for a week. When my last computer died, this is exactly what happened -- I ordered the new Dell almost immediately, but I still had to use a Mac for a week.
So if I just need something simple like the CD replaced, I'd much rather have the guy come to my house, take an hour or less to fix it, and then leave, rather than ship it off somewhere. Even overnight shipping isn't enough to make the turnaround less than an hour.
They simply aren't as large company as Dell...
So what? Dell doesn't do it themselves, they hire a local contractor.
I don't think they care but I don't know their policy. If it important to you, I'm sure you can look it up.
I probably will, at some point, especially if someone wants to pay me well to do Mac development. As it is, I don't really care.
You seem to be anti-Apple at all cost.
Actually, no, cost is what started this discussion. But with what they've done with the iPhone, and with Steve Jobs' personal hypocrisy about DRM, yes, I'm anti-Apple. However, I also try to be rational -- OS X is both pretty and powerful. I have serious issues with it, but I can see a personal preference towards it and away from Linux.
I'm not anti-linux or anti-pc other than just for myself, I simply don't like the look and feel of either.
That's fine, but it also lends a lot of credibility to the idea that you spent twice as much for shininess, glossiness, and translucency.
Also read TFS, though -- the issue isn't wiping the drive, it's attempting to completely reset it at a lower level than the disk blocks exposed as a linear block device.
To do that is always device-specific, which is why he's having issues.
It's also not a low-level format. Google that before you make yourself look like an idiot.
It's not very fun having someone on the other side of the world lagging up your game, which they seem to love doing in Warcraft 3.
I'd blame WC3, then. There's a trivial solution: Use actual servers (including dedicated servers), and make it obvious who's the server. Server lists are apparently being phased out of newer games as too technical, but there's something to be said for getting a list of open games, sorted by latency, and then knowing that if your own ping time to that server holds, it'll be other people lagging, not you.
I owned a boxed copy of Half Life, and I remember being unable to play online for most of the weekend that Steam came out, because it decided to download a new copy of the game (which took several hours), and then the servers were too loaded for the authentication to work.
If that's Half-Life 1, well, Steam has improved massively since then. I don't play heavily, but I never have Steam refuse to let me.
I like knowing that I can dig out my old games and play them whenever I want.
That's one reason I like Steam. I don't keep old game installers around, and I certainly don't keep CDs around. I like that whenever I want to play Half-Life, even if it's a fresh Windows install, all I have to do is download Steam, login, and download Half-Life. Oddly, in the case of Half-Life itself, I don't even need the full game to be downloaded to start playing.
Now, true, I have no assurance that this will continue to work, but right now, it works a lot better than sticking strictly to the old version. If I cared, it would be pretty trivial to fix offline mode to work.
I know I never did. I buy games for me to play, not because I want to resell them. I'm perfectly happy to pay $50-60 for a good new game, and I have no expectation of ever selling it -- if it was good enough for the money and the time investment, it's likely good enough I'll want to play it again in 5-10 years for nostalgia's sake.
Prime example: Portal. Worth every penny, and get your own, I'd feel worse about selling my copy than I did about the Companion Cube.
Also, I do find Steam to be a fair trade -- but when given the choice, I'll usually buy a DRM-free version of a game, rather than the Steam-ified version. Better for the developers and better for me, unless I'm an idiot and lose the copy I had, in which case, better for the developers, since I'll buy a second copy. (There are few enough DRM-free Linux games that I feel an obligation to support them.)
...though I should clarify...
Maybe I didn't read carefully, but I'm also assuming that it can be activated multiple times. If there's a hard limit on the number of activations, then yes, I'd call that restrictive and I'd start to have a problem.
Here's the test: try to run the game without signing up. If you can't do that then it is a restrictive DRM.
No, then it's DRM. DRM is by definition restrictive, sure, but it's also comparatively less restrictive than most other forms of DRM, so I think it is accurate to say that it's not "restrictive DRM" when comparing it to, say, anything from Ubisoft. Requiring a single activation is considerably different than requiring a constant Internet connection.
If Google were likely to do that, I would think there would be two other directions they could go instead:
First, why upgrade to IE9 when you can upgrade to Chrome?
Second, why limit it to the browser? Do the same to ISPs which are known to violate net neutrality.
I doubt any of this is likely, though. For one, anything Google does to block people is giving marketshare to Bing. And if both Google and Bing do it, the lost revenue would be more than a "meager sum" that Microsoft might be willing to pay.
To be fair, so long as people were refusing to upgrade from XP, and so long as XP didn't support HDCP, that was a large incentive for people to avoid requiring HDCP -- and that's only a good thing.
As for a "trivial" solution (referrer checking): It was actually non trivial for the webmaster who confronted me about the "hot-linking".
If referer-checking was non-trivial, so would any solution you propose, I would think.
Ah, but since shortly after the <img> we've needed a way to inform browsers of cases when the content should or shouldn't be displayed in mixed domain pages,
I think the point I'm trying to make is that it's not always obvious how to generalize something. Again, the obvious and dead-simple solution to hotlinking is referer-checking. It's not as if people were deliberately hotlinking other content at the time. I know that when I first discovered this problem, I noticed that referer-checking existed, so I shrugged and mentally categorized it as a solved problem.
In other words, it's a bit like asking why JavaScript popups were ever allowed -- because it wasn't obvious that this would be a problem until it was.
I'm not saying that all problems are unforseeable, I just respectfully disagree that this particular one was so obvious as to be "silly".
You're missing the point. We want to keep rogue websites from "hot-linking" and "click-jacking" not rogue browsers.
I understand. However, you said:
Referrer validation is just as broken as TFA's frame busting JavaScript code since browsers can be configured to disable both JavaScript and the HTTP referrer.
In other words, people with oddly-configured browsers may be vulnerable, and may allow rogue websites to abuse them or other websites.
Well, for images, it seems useless -- referer-checking is still enough to discourage someone from pasting that image, since the majority of people don't know how to disable referer, and certainly wouldn't want to. Depending how it's implemented, it could save you the bandwidth, too.
For clickjacking, if they disable JavaScript, it seems like they'd disable just about any realistic clickjacking attack.
If we have a way of telling the average visitor's web browser that displaying certain content is not recommended, then we have a solution that security minded folk will adopt quickly; Everyone else can choose to "upgrade" (or not) as they see fit.
Assuming that it's widely implemented and comprehensive, that it has no unintended consequences...
Nothing can prevent these "exploits" if a user chooses to disable the default (recommended) security features or use an older browser (or craft their own browser).
And yet, you were trying to claim that referer-checking was "broken" because users might change settings.
It wasn't always this way, and it doesn't have to be. HTML standards have been stagnant for quite some time now...
Seems they've been evolving at a relatively rapid pace, with HTML5, WebGL, and I think there's even some proper sound APIs now. Even so, they are rightly cautious, even the working groups like HTML5.
The fact that it is hard to add simple cross domain controls (that we've needed for several versions already) to the current/next standard is at least a bit silly, no?
Not really.
Think of it this way: One of the biggest complaints people from other platforms (like Flash) have about HTML is that things can break from browser to browser, even from version to version. If changes to the standard are done too quickly and carelessly, browsers won't bother to keep up, and potential web developers will get discouraged, both at all the standards that aren't supported, and at how hard it is for them to keep up with the new developments, or even keep their browser running.
Also, the less time there is to review a change, the more likely (I think) that you'd have to reverse the change later, or at least tweak it. An example of this is the current debate about the video tag. If they'd standardized on Theora, no one would've used it, and they'd have to re-standardize on h.264 when the patents expire anyway. Of course, if they standardized on h.264 without thinking, they'd have just as many problems.
In what way is it not? I mean, while Chrome uses GTK+, WebKit certainly supports Qt. In fact, Qt embeds WebKit! It's actually kind of comical -- thanks to Konqueror still using KHTML, I now have KHTML, two versions of WebKit, and at least one version of Gecko, all on the same machine.
Granted, but it does seem both amusing and frustrating as a user to find that KHTML has now become Webkit, which is now used in Chrome, with gtk instead of qt -- but Chrome is faster in every way than Konqueror, including launching faster, even on KDE.
So while I'd love to port it -- after all, the crown jewels of Chrome are WebKit and V8, neither of which is GTK-specific -- I don't know that it'd buy much.
What? No, it wasn't stable. It lacked plenty of features, but it also crashed enough to be nearly unusable.
WebGL is hardware-accelerated video. Audio benefits from hardware acceleration, but doesn't need it. It does, however, need some amount of software control, something more than "Play this file at roughly this time."
My point was, even with a wiki, unless it's doing some pretty crazy AJAX, wget -r is probably enough to get something workable. There'll be broken links, but they'll be to things you didn't need offline anyway.
OTOH, a webserver doesn't have to be that bad. Rubygems installs RDoc documentation by default, and 'gem server' on the commandline will fire up all the webserver you need. (It uses frames by default, but there's no reason it has to.)
...that was needed to be able to actually make a decent 3D game in JavaScript. Sure, I'd prefer OpenAL bindings, but this'll work.
I hate when people make that mistake. It's the Windows NT commandline. Whenever someone sees my bash prompt, they ask me if that's "like DOS", and I have to explain that no, not even close, that it's light-years beyond cmd.exe, which is light-years beyond DOS.