Slashdot Mirror
A Mozilla Plugin to Help Overcome IE Rendering Flaw
least_weasel writes "An article on Ars Technica reveals Mozilla's intention to create and release a plugin for Internet Explorer that would allow the often-criticized IE to utilize some of the cooler rendering code developed for Firefox. The current WIP focuses on rendering using HTML5 standards, but the plans seem to be more ambitious than just fixing this one small piece of IE. The article covers some of the plans, hurdles, and potential benefits. It also spills the beans on the code name for the project: Screaming Monkey."
What's the advantage over just installing Firefox? Do people who don't have permission to install software have permission to install plugins like this?
Great idea... but if someone would have the wits and knowledge to look for this plugin, wouldn't they be using FF already? If websites prevented stuff from working without this plugin, wouldn't that just turn off viewers? Not sure how this is going to help, people have been harping at Microsoft about standards for years and all they've done is move towards them at the pace of a snail.
Comment removed based on user account deletion
Is it a sad or happy day for Microsoft, when their competitors get bored with beating them, and instead try to improve the Microsoft products to make them competitive - for free?
I run Firefox for NoScript and AdBlock...I could care less about rendering a page .002 picoseconds faster.
So I take it Balmer is involved in some way?
To: M$
From: KindFolk@mozilla.org
Subject: U JUS GOT BITCHSLAPPED!
I've been reading about this for months. Its not exactly top secret.
https://wiki.mozilla.org/Tamarin:ScreamingMonkey
FYI, Screaming Monkey was already discussed in an earlier story.
The only problem is getting people to install the plugin. My own solution was to use the market penetration of Java Applets to develop a shunt that would render Canvas using Java APIs. (Note that the events system has not been completed in that demo. Make sure you click outside the block falling area so that the browser receives the keyboard commands.)
The same sort of shunt could be done with Flash 9 or Silverlight. Which would do a nice end-run around the problem of getting plugins installed.
Javascript + Nintendo DSi = DSiCade
I think Microsoft owes Mozilla another cake. This probably saved a lot of money and a few man hours for Microsoft. Or they can just let Mozilla bask in their humble glory.
Please visit http://www.mederbil.com/ i7, GTX 275, 4 1TB Caviar Green in RAID 0+1 array, EVGA X58 3X SLI Board, Silver
Now with all of the features of Firefox, without the bother of all the security.
HTML 5: have DOM storage (session and local) and database storage. These should all be SameOrigin. Meant to block userâ(TM)s deleting of tracking cookies. Use of database storage, there can be SQL injection against the local database. Some browsers support GlobalStorage that donâ(TM)t have SameOrigin control. Lots of new attack surface in FF3. Websites can be protocol handlers (support spyware!!). Installation of protocol handler is one click. WebKit is a big supporter of HTML5 and supports these issues.
HTML5 has limited storage (~ 15 Mbytes total) allowing easy exhaustion attacks and there is no UI to manage this. DOS is easy. Can easily plant arbitrary evidence on a system. HTML 5: Security âoeneed to write this sectionâ.
We now have web developers making desktop apps without any security or privacy expertise. The Web is becoming more heterogeneous and far far more dangerous.
Hey, that's great. Do they also have plans to fix the flaws in Firefox?
Off the top of my head, could we finally have support for SVG as a native image format? Or even just SVG rendering that isn't slower than a stone cow?
Don't want to sound like the grumpy old man, I just want most of my web shit to work in *one* browser before I worry about how it works in every browser.
Never approach a vast undertaking with a half-vast plan.
Well i'll be darned, I guess someone should call the XHTML2 camp and tell them they lost the war!
Nah, don't bother them. They're busy working on the HD-DVD website.
Those who believe the Internet is private,
find their privates are on the Internet.
it will be used by ie developers to test ff compatibility ... rofl
You mean they're gonna test their websites in IE to see if they work correctly in FF? Firefox already has the superior webdeveloper add-ons. I'd like a firefox plugin that allows me to debug IE CSS with those FF add-ons.
HTML and XML are co-standards, not competing standards. There has been some talk about renaming XHTML2 to XHTML5 to emphasize this. XHTML is only needed if you're using another XML-based language on the page, and is very susceptible to errors. HTML, on the other hand, is less prone to errors, and the page will at least render. It is also supposed to be served as text/html, whereas XHTML is to be served ONLY as application/xml as of XHTML1.1. If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Learn about Photography Basics.
M$ didn't leave it broken so users had to deal with it, they left it broken so developers continued to support IE. If we have to code differently for IE, because it doesn't follow standards and many users use IE, it makes us constantly concerned with what M$ does.
It's like the ex who keeps you as a friend on facebook and makes sure you see all those new pictures with her new bf. Except with IE you just can't defriend it.
We now have web developers making desktop apps without any security or privacy expertise. The Web is becoming more heterogeneous and far far more dangerous.
What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Any person clever enough to install that plugin would be clever enough to use a real web browser to begin with.
HTML5 comes in two flavours. One is straight HTML5 which is based off HTML4 (same parsing rules), the other is XHTML5 which is strict XML and requires the application/xml content type. None of them are really related to XHTML2 which is mostly dead at this point.
can design on a sane model with sane tools, deploy the plugin when the users are IE.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
"A Mozilla Plugin to Help Overcome IE Rendering Flaw"
Should it not read: A Mozilla Plugin to add Enhanced IE Rendering?
Come on. This old fight between browsers is becoming stale. IE included many things now in the HTML specs that were not available in any other browser, such as CSS Style for shadow effects, etc. Why is it that when something new comes out for IE that it is automatically described as a "bug" fix or a workaround to a "flaw"?
Please people, I like FF and IE for different reasons. At least write unbiased stories and stop bashing each other's code efforts.
This is exactly backwards to what most of us need. We need a [multiplatform] plugin for Firefox that will allow broken IE-only sites to work under Firefox so we can continue to use the browser of our choice. Not that I want to promote the use of IE-only coding, but the reality is that if the site doesn't work, the average users always blame Firefox, not the site designer.
This is entirely correct; the market leading browser is non-standard in many ways, and that breaks standards as a concept, or might have. But that is just a tactic towards a strategic goal, and it was the strategic goal to which I alluded in my post. Standards largely won out, so today we say IE is borken rather than saying it is the One True Way. Nice play, MS.
Standards are like the white blood cells of the Internet, and are the chief way that the system is able to work at all given the complexity and chaos of its origins. Without standards, it would eventually fall apart due to internal "diseases" born of the Not Coded Here mentality of corporations. MS probably wasn't so worried about the threat of email, or IRC, or gopher-space. But a graphic application that ran over resources and data spaces not-on-the-desktop must have made Bill Gates soil himself.
Thanks for the critique.
-- act fast decide fast --
=^..^= all your rodent are belong to us
Have Mozilla send come checks to all major software companies (Adobe wink wink) - perhaps Google can through in a few $100 million in the pot too to distribute. Goal: install Firefox (if not installed yet) and make Firefox the default browser. A little taste of Microsoft's own medicine.
*nawcom sips from his glass of kool-aid*
From reading the article, it's not clear to me exactly what this will do, aside from make some HTML5 elements available. Will this fix IE's numerous CSS flaws? To me, that is *vastly* more important than adding HTML5 stuff.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works
well, my (and most people's) definition of 'works' is one that keeps me and my data secure
your argument is bogus and assumes your specification for doing something contains only *one* criterion, which is a crazy idea, and not how engineering works
...when I need them. You hit the nail on the head, pal.
Good thing I scrolled to the bottom of the page before I posted and avoided the dreaded "Redundant".
Did anyone think about pages that detect user agent strings? A lot of devs use the UA string to "fix" these rendering problems on a per browser basis. This plugin would "break" the pages that have already been "fixed" causing quite a headache to the devs who would never know that their page does not work correctly in this version of IEx because it has a nifty plugin to fix things. Sound like dev's will have yet another variable to watch out for.
And for thoes who say this plugin is somehow for devs: any developer who wants real cross browser compatibility will use the target browser not some add on crap. Any developer who says "I don't care what it looks like in IE" obviously does not have a job developing public web sites (or won't have a job doing so much longer). Even if you don't like the browser you don't ignore 70+% of your customers (or any % of your customers). I have every browser imaginable available to me to make sure my pages work properly in all browsers.
And as far as bashing IE for the rendering flaws it has, I would look first to fix FF's rending flaws. I'm not going to list the dozens of bugs and out-of-compliance standards FF has, anyone who thinks FF has no rendering bugs is seriously delusional. And no production browser has yet to pass the acid 3 test, that includes FF and IE. And even if one browser did pass the test, devs still have to cope with all the other browsers that didn't.
What's the difference between web developers and regular developers? Take a look at any desktop applications and tell me that they're programming with better security practices than web developers. Windows, apache, IIS, OSX, and many more programs include critical security holes that can be exploited externally; how is a buffer overflow any better or worse than improperly escaped SQL?
Developers as a whole have been programming without security and privacy expertise, web developers just happen to have a program that's exposed to (at best) everyone in a particular company, or often everyone in the world. With that kind of exposure, what percentage of non-web-based programs would survive without getting exploited?
Sorry, rant over. Security is a big concern, and for things which need to be very secure these features shouldn't be allowed. However, that shouldn't keep the browsers from increasing functionality and usability. Hopefully developers are learning their lessons and becoming more security conscious.
> What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You can't bolt on security as an afterthought. It has to be part of the design.
I'd rather have a protocol designed with security in mind than one that makes it easy to steal my passwords and personal information, but where the widgets are 10% flashier.
Of course, I also know that my PC is under constant attack from botnets and such (and I can get logs to prove that), being secure only because I have more sense than to install insecure software.
The average home PC I have repaired is replete with spyware because people don't patch and don't know better than to install crappy software that has the shiny widgets they want.
Looks like someone hasn't upgraded to 3 yet.
(24 opened tabs, 8 extensions, been running 5 hours and gone through hundreds of now-closed tabs - barely 200 MB RAM usage; not that I really care, since that's about 6% of my total memory)
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Really? My opinion is that the "web stack" (not sure which stack you mean here; MSIE-Windows, FF-Windows, Safari-MacOSX, Konq-Linux, etc) has by far the worst record so far. MSIE-Windows has to be the #1 vector for infection now, and has been for at least the last 6-7 years. Which alternative are you thinking of? Because the "web stack" is, in my opinion, the premier virus runtime environment.
My opinion is that web designers made a HUGE mistake in not treating network input cautiously. The emphasis has been on "rich APIs", "data structure passing", extensibility, desktop integration, and so on. These are undoubtably good things in the absence of malicious input, but the fact is, there is a lot of malicious input out there. Web browsers would benefit greatly from some simple privilege separation; the Mozilla camp could do this with some effort, but MSIE is pretty much dead in the water here due to the level of integration with the base system. I understand the HTML5 camp's worry that Flash/Flex will become a de facto standard, but in my opinion, web security has not been taken seriously enough. These kinds of vulnerabilities have become a major source of income for organized crime in the East, and still people like you are saying that security is not the most important issue? Gimme a break.
That's the attitude that made IE what it is today.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
Firefox already has the superior webdeveloper add-ons. I'd like a firefox plugin that allows me to debug IE CSS with those FF add-ons.
It's no firebug, but Internet Explorer Developer Toolbar is pretty useful for those "what the hell is it doing over there?" IE moments.
One - The project should not be called Screaming Monkey. It should be called Airborne Chair.
Two - This seems like a complete waste of the Mozilla team's time, in my opinion. I don't want to diss their hard work, but Firefox is an exceptional piece of software, so it would make more sense to concentrate on making it even better/faster/smaller, rather than waste the time fixing monkey code (or rather making an add-on that fixes functionality in monkey code).
Three - In addition to concentrating the technical abilities on improving Firefox rather than the monkey code, Mozilla's marketing people should be concentrating on getting this browser installed on as many computers as possible. I know they already do this, but they need to do even more. All too often, I find computers out there that run IE by default. This can be changed by lobbying computer manufacturers to make Firefox the default out of the box, in addition to continued press coverage, ads placed in major newspapers and other media, etc. Because when the majority of users make the switch, nobody will care how many bugs there are in IE. Hell, Microsoft might even decide that it offers them no return on the cost of developing it, and the next IE will be Firefox modified to look like IE, with an OSS license, of course. That should be the goal, not fixing someone else's problems.
McCain/Palin '08. Now THAT's hope and change!
Child
"Mommy! That mean man tricked me into installing IE again. Make it go away!"
/ Child
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
I think it's Korea with tons of IE6 dependent pages. If a plugin like this works for them, it has value.
Can we go the other way? Make a weird plugin that can fake IE6 behavior so that we can let them escape from the rusty tyrannosaurus trap?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
sounds sort of like buying an alchoholic a bottle of scotch.
I wonder why people think that "high" memory usage is related to leaks. Old firefox leaked memory. It's the same ignorance that sees "5 MB Free" in Vista and thinks it's really using up 2 Gigs (it's not, go read up on "SuperFetch", and caching, among other things). Three questions for you:
1) What version of Firefox are you running?
2) Does your memory usage change if you open a bunch more tabs? My guess would be "not much", which means it's hardly a leak (it's how it works, mhmm).
My copy of Firefox has been open for days, with three tabs open, one with pretty hefty rendering and two of slashdot - 131 MB of ram.
It also spills the beans on the code name for the project: Screaming Monkey.
Ha. Ha ha. Ha ha ha.
The higher the technology, the sharper that two-edged sword.
There had better be an easy way for web designers to tell if IE has that plugin installed or I'm going to be really pissed.
It's hard enough dealing with IE's crappy rendering... it will be so much more painful if the rendering engine in IE isn't *consistently* broken and we have no way to tell the difference in our code.
Come play free flash games on Kongregate!
What bothers me is how security is somehow pushed to the forefront as the most important issue, even more important than functionality.
You shouldn't be bothered, since it isn't. Which is a problem.
The most secure system is one that is turned off. This new stuff they're adding increases the attack surface, sure, but it's also necessary to build stuff that actually works (like a web app that doesn't die when your wifi does).
That's not the issue, at all. This new stuff could be excellent, yes. But if it is developed without keeping security in mind, it is worthless -- worse than worthless, it is harmful -- in the context of the web. If you don't tackle these (some rather obvious, some somewhat tricky) problems now, rest assured, attackers will tackle them. Successfully.
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
All in all I think the web stack is pretty secure by default, when comparing it to the alternatives.
Interesting analysis. I don't agree with it. Security being important in the browser does not stem from the feeling that it should be "more secure" than your regular client-server app. It stems from the fact that you do not trust the server to feed you valid data. Browsers get a lot of crap thrown at them during a regular browsing session; you cannot, by the very nature of it, assume to trust every website linked from everywhere else. As such, since you cannot trust your input, you should assume that it is malicious. This is why security in the browser is important. It's not just the interaction between your browser and Google Mail that's interesting -- it's the interaction between your browser, Google Mail, and the other website you have open at the moment, whose author you do not know.
So yes, security-by-default is a lot more important in a browser designed to browse lots and lots of untrusted content without that leading to a local system compromise.
And yes, by that very nature, many browsers have some measures that make them considerably more secure for running webapps and the like than executing native code would be. The design is to not let ECMAscript and other such supplied code screw with your system or other sites you may also be visiting now, have visited in the past, or will visit in the future. This is valuable.
Local storage is an interesting feature. I don't think I will like 95% of the applications it will be used for, but the other 5% might become some truly stunning stuff. So long as those 95 other % don't really, really screw it up.
The flipside of the sandbox-model we currently have with browsers is that many "web-coders" never really bother to look at the implications of security. A lot of ECMAscript out there is absolutely atrocious security-wise, and security concepts on the server side are, apparently, really really hard to grasp for many people. If you give these people more features that can cause greater harm and do not properly put sandboxing into the design, you'll end up with a lot of vulnerable, unprotected code. Right now you "just" deal with Cross-Site-Scripting, server-side SQL injection, etc. -- just imagine how much fun it'll be when you have to deal with local SQL injection, local cross-site-scripting, and the ad you just loaded off of the Slashdot adserver fetching all your site-local storage to their servers -- including all the mail you recently viewed. It'll happen.
You missed the key word there...professional. It means one who makes money from their profession. Developing to standards is great but it doesn't necessarily put food on the table. Idealism is nice, but it can cause one to starve. My guess is you are still in school and haven't had to pay any bills?
But even aside from the issue of functionality vs. security, there's the issue of security somehow being way more important in the browser, which I think is nonsense. Client-server apps have always had lousy security, and were easily hijacked. Just because they now run in a browser, the threat level hasn't changed. A hacker that is determined can break in sure, but they've always been able to break in. Nothing has truly changed, except for the perception of the threat level.
There are reasons why browsers are different from other client/server applications:
Part of the point of HTML5 is to make it easier to do things like implement a desktop application in the browser. As such, the comparison with the security of client/server applications is not appropriate. It's the equivalent desktop application's security that should be the goal.
It's also worth noting that the easiest time to add security is at the beginning. Once applications have been written to a certain model, it's expensive to change the model. Now, when there are no HTML5 applications, is the best time to make their security model robust.
For some websites and their applications, such as Netflix's Instant Watch application, the IE engine is still required. When ever I want to watch a movie over Netflix, I have to use IE7 instead of FF3.
ScreamingMonkey is a project that aimed at providing IE with a JS runtime able to run EcmaScript 4 programs.
Since ES4 is apparently dead, I'm not sure where that leaves ScreamingMonkey.
The canvas stuff is a different project that follows the same general approach, but on a different browser component.
Use of database storage, there can be SQL injection against the local database.
Depends where the SQL is coming from. And a properly designed framework should make it difficult to do this.
I'm not convinced SQL was a good choice, but SQLite is probably the simplest thing that could be implemented in all browsers that fills the requirements: decently fast, embeddable, and optimized for lots of small chunks of data.
and there is no UI to manage this.
Is there any standard that requires a UI to manage cookies?
If HTML5 gets popular, there will be a UI.
Don't thank God, thank a doctor!
XHTML is only needed if you're using another XML-based language on the page,
Doesn't mean it's a bad idea otherwise.
and is very susceptible to errors.
On purpose. That was a design feature -- so people would stop making horribly twisted and downright broken code.
HTML, on the other hand, is less prone to errors, and the page will at least render.
It does, however, require a hell of a lot more complex of a parsing engine, let alone rendering engine.
XHTML, you can just throw through any old dumb XML parser.
Which means that XHTML is more prone to you making a typo (or something like that), that you'll catch immediately, because any browser that supports XHTML will refuse to render it. HTML, on the other hand, will be prone to subtle errors in your document that the browser will silently correct.
So, additionally, HTML is much more prone to errors in the browser's parsing code, as well as subtle errors in the document, so a document may stop working after awhile.
If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Except you can make an XHTML document also appear as well-formed HTML4. Meaning you get all of the above benefits, but your users don't have to upgrade their browsers, as long as you can still serve it as text/html.
The only problem is, how do you serve it as XML to supporting browsers, and HTML to nonsupporting browsers, given that there's no way to tell (short of testing every browser) which is which?
Don't thank God, thank a doctor!
I immediately thought that it was a plugin for Firefox to fix Internet Explorer rendering. I'm like... wha?
Should read: "A Mozilla-Developed IE Plugin to Help Overcome Rendering Flaws"
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
The way to get this installed is for big websites (Google for example) to use the same drive-by-download used by spyware to install these plugins. The clueless "internet == blue E" people are most likely to just say
"yes" to such drive by downloads without bothering to check what it says and those who know better will be likely to install it too (especially if e.g. Google says "install this plugin to get a better experience with Google Maps")
I remember when Mozilla seemed to concentrate on their customers needs. Now, they seem to be behaving more and more as a subsidiary of Google. (They seem to think that you don't need a reliable, usable desktop email client anymore-- because THEY'VE decided that you're gonna be happy using GMail!) And now, maybe because Google needs IE to work better, Mozilla pours time and effort and money into fixing IE.
The corporation seems focused on making big deals, the old software which I loved since Mozilla 0.6 seems to be getting treated as "legacy crap". Hey, business people, you don't gains market share by improving your competitor! What ARE they thinking?
I agree completely with your comments about firefox, however, I think you are a little naive when it comes to vista. Every freaking version of windows since 98 has promised faster application start up time due to prefetching of data. Which leads to a larger memory usage. Now every freaking program takes the same stupid approach and pre allocates all of the memory it will need on start up. I don't think my applications start or run any faster with vista on a vastly more powerful computer than they did with windows 95 (and now I have 5mb of 2 gig free, whoopee!). I should be able to slap windows and tell it to not try to guess what I'm going to do next.
Wait, can I actually do that? If so, then I take it all back.
Well.. maybe. Or Maybe not. But Definitely not sort of.
Sql injection can be exploited more easily. To exploit buffer overflow, you need some compiler and assembly knowlege is very helpful. To exploit sql you need to type some text into a field.
Extreme Programming - Redundant Array of Inexpensive Developers
but MSIE is pretty much dead in the water here due to the level of integration with the base system
You should probably take a look at IE7's protected mode (unfortunately only available on Vista-based systems) before making that sort of sweeping assertion.
It's official. Most of you are morons.
Now we just need the Linux community to fix all the bugs in Windows 7 & M$ may just become usable.
Ah, so that's why Gates made Windows Vista?
Hmm, interesting. It looks like MSIE 7 does do privilege separation, along with a couple other protections. I stand corrected. In my defense, I do not have Vista, so I was unaware of this.
Phishing, spamming, sniffing, exploiting etc. are a fact of life for years now, and will continue to do so.
It's pretty simple, the old protocols http, dns, etc. that were developed to *function*, do function, but no longer meet the requirements.
The reason why security *has* to be pushed to the forefront is because it *is* required for today and the future.
Usually, it's about budget and security becomes an afterthought or calculated risk.
So, IMHO the GP is making an excellent point.
but the plans seem to be more ambitious than just fixing this one small piece of IE
Just just made a typo
It's supposed to be "this one small piece of crap"
Don't worry, lot of people do this mistake.
You'll thank me later.
"they sure as hell notice when things don't work right"
TFA:
"but the browser's defensive security mechanisms insist on prompting the user before every time it is used. This detracts from the seamlessness of the plugin and makes it difficult to use for conventional web applications"
Sorry, but unless MS generously decides to relax this we'll all be getting calls about how our websites "don't work right".
My turnips listen for the soft cry of your love
"It's not a perfect emulation, ofcourse, but in my experience it's good enough once you learn its limitations"
TFA:
"... ExCanvasâ"a complex library that implements many of the Canvas element's features with VML, Microsoft's proprietary alternative to SVG. Unfortunately, scripted manipulation of VML is too slow to be used for highly interactive web applications"
My turnips listen for the soft cry of your love
What, are you running on a computer with 256 megs of ram? 150 megs is about where it sits, 3 tabs or 30.
On Vista, take a look above "free" at "cached", that's how much you actually have free. As for disabling superfetch, yes, you absolutely can do it. Here is a page detailing how to enable superfetch on Sever 2008 (which is Vista based), and if you're technically proficient enough, you should easily be able to use that info to turn superfetch off or (as I actually do) turn it on for only system files (1 and 1 instead of 3 and 3 in the regkeys).
Sql injection requires knowledge of sql and either a way to get the structure of the database or some luck with guessing tables. If you're going to say that sql injection is just typing text into a field, you could say the same for buffer overflow.
Just let the dead horse die already. Fixing IE will just help to get the droves of idiots to stick with IE even more. More websites that code as they should code and not specifically for IE will create a disdane for IE when it breaks and customers can't buy stuff online or can't view this or that. This will cause droves of people to find an alternative. Whether that is Opera, Firefox, or some other alternative shouldn't matter. The fact that IE would be dead *would* matter. Microsoft needs to be shown they are not king and they need to listen to consumer's more than they listen to larger corporations. Their real end users are home users not corporate monstrosities. Sure the corps pay the bills, but the people using it are out in the homes. But I digress, it'll come down to pitchforks and torches before anything gets done. That goes for both politics & software...
"When the people fear the government, there is tyranny. When the government fears the people, there is liberty."
Thanks. I'll take a look at that. I understand how difficult it would be to write an intelligent caching scheme on a general purpose desktop, and I will need to experience the difference with it on vs off. But just having the ability( even if it is a registry modification) lowers the barrier for me to switch to vista if I have to at work.
Well.. maybe. Or Maybe not. But Definitely not sort of.
I've got FF 2.0.0.16 on up-to-date XP. I've never found the amount of memory usage to have any notable impact on my browsing experience. What I *have* noticed, though, is that browsing gets notably slower, and the CPU often gets pegged by FF, once FF's page fault count gets much above 2 million (as according to Process Explorer). The situation is gradually improving, as v.16 doesn't slow down as much as v.15 did.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
browsers that support application/xhtml+xml already send it in the Accept header with every request.
Actually, no, they don't.
I remember trying this awhile ago. Firefox sent it, but it required some weird parsing rules to detect it. I also seem to remember that Firefox didn't give it any higher a priority than it gave straight html, meaning that with things like Apache, it would just fall back to the default. I suppose I could write an app and detect any mention of it in the Accept header...
However, Safari did not send it. I remember Safari sending something more like "Accept: */*". This was a long time ago, so I may not be remembering right, and they might be sending something else by now...
Which, by the way, is the other problem with the Accept header: every browser has to accept */*, because they can always download the file, or pass it off to another application. But that */* still has meaning -- if I wrote a client that was designed to scrape it for something, I'd probably have a very limited number of content-types listed in my Accept header (if I sent one at all).
I haven't found a reliable way to detect XHTML support this other than to send it to the browser, and see if it renders, or if it presents me with a "Save As" dialog -- and then to maintain a list of known-good User-Agents. I really don't want to do User-Agent detection.
Don't thank God, thank a doctor!