IE is currently around 40% of the market--a far cry from the +90% they were at when they stalled adoption of PNG. And while I agree that JPEG XR is a good format, MS chose to release the code under a license that is GPL incompatible. So, a clean-room re-implementation would be necessary before most open source projects could touch it.
I've audited parts of Silveright in the past, and it's actually quite good. Most importantly, I've reported some vulnerabilities and they turned around the fixes much faster than other Microsoft product teams I've reported against.
Then the Chrome / Windows machine, which no one tried to attack (one person found an exploitable hole, but sold it to Google for $1,337 instead of entering it into the contest).
I talked to the guys who won yesterday, and one of the Team Anon guys who was originally signed up for Chrome. Some of them said their WebKit bugs affected Chrome, but no one had figured out how to break the Chrome sandbox. So, they just withdrew their names rather than waste everyone's time with an exploit they knew wouldn't work.
You're joking, right? Apple is historically months behind in patching publicly disclosed vulnerabilities in core libraries they share with other Unix-like systems (Samba and Java are two key examples). Overall code robustness is abysmal in any Apple product I've assessed--they fall over with trivial fuzzing or a few hours of analysis. They're an absolute pain in the ass to deal with when trying to resolve a responsibly reported vulnerability: they often don't seem to have qualified people triaging inbound reports, and when they do finally acknowledge the correct severity of a reported issue it can take years before they finally push out a fix. And to top it all off, their core security counter-measures (e.g. ASLR and NX) are useless as anything more than marketing fluff because they're not implemented consistently.
Seriously, I've been in the security field for almost 15 years and dealt with reporting vulnerabilities to dozens of companies. Microsoft is a pain to deal with because of their compatibility matrices and long release cycles, but they're generally competent. Whereas Apple is just an absolute train-wreck. The only reason every Mac isn't infested with malware is that they're not a big enough chunk of the market for it to be worth the effort. If they ever cross the magic 15% threshold they're in for a very rude awakening.
Your guess is correct; for rarely followed code paths it does take significantly longer to (aggressively) optimize the code than it does to run it. Also, premature optimization can generate pathologically suboptimal code, meaning the performance can be much worse than the unoptimized case.
My understanding of how Crankshaft works is that the emitted code keeps some basic information about the data and frequency for any given code path (it's probably function level, but I don't know the code so I can't say for sure). Once the data and frequency of travel crosses a threshold the code path gets flagged for aggressive optimization. This kind of housekeeping adds very little overhead, so the decision cost overall should be very low. And the useful thing about spot optimizations like this is that their relative infrequency means that you can afford to do really aggressive optimizations that would be far too expensive to run over all of the code at load time.
The funny thing is that none of this is new. It's all decades-old compiler research stuff that mostly evolved out of the Self language. And Mozilla's tracing engine attempts similar optimizations, although it uses a different technology with different strengths and weaknesses.
If you're using SunSpider as your sole benchmark then you're already behind. SunSpider has outlived its usefulness (which the article touches on). In order to get a win of a few hundredths of a percent on SunSpider you have to add in premature optimizations that hurt page-load times and the performance of long running JavaScript applications. (Or you could add some dubious optimizations that are targeted specifically to the test, but that sounds a bit like cheating on a benchmark to me.)
SunSpider was good for it's time because it set a minimum bar for all browsers. However, the beta versions of all the new browsers are now within a hair's width of each other's performance on SunSpider. Rather than split those hairs, we need a new generation of tests that more accurately models real-world usage and JavaScript in the large. Mozilla and Google are both moving in that direction with Kraken and the V8 benchmark suites (respectively), but it's just a start. I'd like to see comparable benchmarks from every JS engine maker, or maybe a broadly-scoped, independent benchmark.
This is pure marketing. If they want to prove to me it's secure, ask for a public code review and reward those who find clear problems, and compile from that reworked code.
The codebase (minus PDF, Flash, and branding) is open source. Google pays out anywhere from $500 to $3113.70 to anyone who reports Chrome/Chromium security vulnerabilities to them. And if you look at the release notes on Chrome and Safari it's obvious that Google has a full-time team searching for and fixing security issues in both Chrome and WebKit. I'm not sure what else you want them to do, because they're already going well beyond anything you suggested.
You "do a lot of internet marketing" and you don't understand the difference between returning a competitor's site as a search result (what you identified) and stealing a competitor's search results then presenting them as your own (what is being accused)? Might I suggest that you consider a different profession in which you might be more qualified?
If you don't like the single user version then install the system-wide version from the google pack. And it doesn't leave past versions around; it leaves exactly one previous version when it's updating because it uses differential compression against the old version and falls back to the previous version if the update failed.
Kraken seems biased heavily toward things like looped and nested calculations, which is where tracing should be a big win. However, it avoids property access, dynamic allocations, and other areas where JaegerMonkey doesn't shine, but are an essential part of web applications.
This is not to say that every JavaScript team doesn't take a similar approach to benchmarks, but it's really hard to assess any of them accurately when everyone is playing the benchmark game.
I'll try explaining this again. SunSpider doesn't perform sufficient runs to take advantage of the tracing logic. And given the way the test is designed you will actually take a performance hit if you burn many cycles on front-end analysis. So, you consistently hit the unoptimized path where a good implementation uses simple translation logic for emitted instructions, along with a fast and light-weight assembler. (Comparing to YASM is silly, btw, because the needs of real-time JIT are very different from compiling in advance.)
Since Mozilla already had most of the instruction generation logic from their old bytecode implementation, and the test isn't hitting their trace optimizer, the biggest improvement here is coming from the introduction of the Nitro assembler. That's not true for most other JS benchmarks, but it is true for SunSpider. This is why I said I want to see their performance on benchmarks that would take advantage of their tracing optimizations in real-world scenarios--not a test like SunSpider which is heavily weighted towards the compilation speed and baseline (unoptimized) execution speed.
Seeing that Firefox on a few weeks ago was starting to lag pretty severely behind Chrome, I applaud and thank the Firefox team for their hard work. This is also a boon for their technique, the so-called "shotgunning" method of pushing through compilation the old way if it will complete faster than the optimizations. I had become afraid I might have to move to Chrome, looks like that won't be necessary.
You don't seem to understand how JaegerMonkey works, or what the SunSpider benchmark actually tests. The entire speedup here can be attributed to Firefox not compiling JS "the old way." Instead of defaulting to bytecode like they were previously, they always emit compiled instructions via Nitro's assembler. And given how the SunSpider benchmark works, all that is being tested is their parsing plus Nitro's assembly. The SunSpider benchmark doesn't even run long enough for Mozilla's tracing engine to be a significant factor (because the benchmark was created by Apple to showcase the performance of Nitro). So, not to be dismissive, but it seems like Apple (as the creator of Nitro) is more responsible for the speed increase.
Kudos to Mozilla for the overall improvement, but I'd really like to see results on a benchmark not so heavily biased to such uncommon use cases (compilation speed without hot path optimizations). In particular, I'd like to see benchmarks of common use cases that factor in the performance of their tracing engine, which is the piece of their stack that Mozilla has invested so heavily in. The Kraken benchmark provides some interesting stress tests along those lines, but it's still very narrowly targeted and not representative of current or anticipated use cases.
Re:Conclusion: Firefox 3.6 scales best across core
on
How Do Browsers Scale?
·
· Score: 1
Except their data doesn't actually show that, and Firefox 3.6 has far worse absolute performance than the other browsers. So, the effect they're seeing is probably just the other browsers (including Firefox 4 beta) performing much better, but hitting a wall due to cache pressure and/or IO bottlenecks. Whereas Firefox 3.6 is slow enough that it appears to be scaling well, but really just runs slower than the system can perform.
It's not $400 per bug. Many of the bugs were discovered by Google employees, who don't get rewards. That pushes the average down. However, it also makes Google possibly the only company that appears to report all vulnerabilities they internally discover. MS doesn't report any internally discovered vulnerabilities, and even Mozilla will lump numerous internal discoveries under a single bug ID and CVE.
You forgot the part where the hypothetical researcher has privately reported numerous critical vulnerabilities to the hypothetical company and waited months or years for fixes. You also missed the researcher providing two different fixes for this particular vulnerability in his disclosure announcement. But hey, why make a fair comparison when you can resort to sensationalist slander?
That should be the first thing anyone familiar with Windows architecture notices. It means that it's an escalation from an account that's already running at elevated privilege (at least, it is on Vista and beyond).
So, it's definitely a security bug. But it seems like a disproportionate amount of noise for a local privilege escalation requiring higher than normal privilege to start with.
You have this backwards. I can point to every major browser, along with research directly addressing the topic. Whereas you haven't provided one iota of evidence to back up your misguided and ignorant statements.
Since it's obvious you have nothing of value to contribute, I'm just going to close this out with a suggestion. When confronted with a topic you obviously know nothing about, please resist the temptation to make noise just so people will notice you. It just wastes everyone's time and prevents you from actually learning anything.
You're conflating a few different things. There's origin security and there's local client security. Origin security is what protects you from one site accessing browser data from another site. Any discussion of extension permissions would apply primarily to origin security, because once you install anything with local client access you've already lost control. And when considering origin security, separate profiles within the same OS-level user account provide one method of strict enforcement.
Now, if your concern is client level security against exploits (not malicious extensions or plugins), then you're far better off relying on the Chrome sandbox over a separate user account. The sandbox provides vastly lower privilege and much smaller attack surface than a normal user token, and OS-level privilege escalation vulnerabilities are far more common than sandbox bypasses. You can certainly use your approach in conjunction with the --no-sandbox option in Chrome, which should allow Chrome to work with runas. However, you'd be downgrading your security with that approach.
The important thing to consider, however, is that no user should be expected to invest their own effort in a multiple profile solution. So, until someone creates something like the Chrome sandbox but with per-process origin isolation, there won't really be a general purpose solution providing a superior form of origin based security.
Not only have I read the paper, I've worked with a few of the authors on this subject matter. And that's why I know that it's essentially impossible to provide a useful extension API that is not also vulnerable to intentional abuse. Claiming the opposite is akin to claiming you've refuted Gödel's first incompleteness theorem. And if you've succeeded at either, I'd like to see the evidence. (Just a heads-up, you're starting to line up a pretty tall list of things you'll need to accomplish to support your arguments here.)
There isn't anything like "reads password data," nor could there be without drastic changes to the DOM standard and how JavaScript is implemented in modern browsers. The way the system works is that the installation manifest states what origins a content script will run in. And any script executing within an origin has access to all that origin's data. This is conveyed to the user with a message like "this extension can access data from site X.com" or "this extension can access data from all sites."
If you have a proposal for something better, then please share it. But the Chrome extension security model was well researched. And it was apparently considered good enough that Apple and Mozilla are creating similar models with Safari and JetPack.
I think you may have intended to reply to someone else. I was simply answering a question on NoScript's capabilities.
Also I'm quite familiar with running multiple profiles; my job would actually be impossible without it. In Chrome you simply pass the --user-data-dir switch. I don't see how that's any worse than running Firefox with the -P and -no-remote switches (or the old way requiring env vars). I am curious how you run IE under a separate profile without using a different Windows accounts. I didn't think that was possible, and instead use runas to get an alternate profile in IE.
It's just sad that you find it perfectly acceptable to comment like this on an application you obviously know absolutely nothing about. Chrome actually does run extensions in a sandbox. It also warns on installation of an extension, and explains what permissions that extension requires. If an extensions attempts something require a privilege that wasn't in its installation manifest the operation fails. As I said in another comment, the UI has issues and could certainly be improved, but the fact is that Chrome currently does everything you just implied it fails at.
Chrome already lists the permissions an extension requests at installation. The UI on that interaction is junk, so you need to be a fairly knowledgeable user to make heads or tails of it, but the information is definitely there.
Slashdot Mirror
IE is currently around 40% of the market--a far cry from the +90% they were at when they stalled adoption of PNG. And while I agree that JPEG XR is a good format, MS chose to release the code under a license that is GPL incompatible. So, a clean-room re-implementation would be necessary before most open source projects could touch it.
I've audited parts of Silveright in the past, and it's actually quite good. Most importantly, I've reported some vulnerabilities and they turned around the fixes much faster than other Microsoft product teams I've reported against.
You're thinking of Jon Oberheide's bug against Android, not Chrome. He's registered to go against Android today, but talking to him yesterday it sounds like the bug he reported to Google is the one he planned to use: http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/
Then the Chrome / Windows machine, which no one tried to attack (one person found an exploitable hole, but sold it to Google for $1,337 instead of entering it into the contest).
You're confusing Chrome and Android: http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/
I talked to the guys who won yesterday, and one of the Team Anon guys who was originally signed up for Chrome. Some of them said their WebKit bugs affected Chrome, but no one had figured out how to break the Chrome sandbox. So, they just withdrew their names rather than waste everyone's time with an exploit they knew wouldn't work.
You're joking, right? Apple is historically months behind in patching publicly disclosed vulnerabilities in core libraries they share with other Unix-like systems (Samba and Java are two key examples). Overall code robustness is abysmal in any Apple product I've assessed--they fall over with trivial fuzzing or a few hours of analysis. They're an absolute pain in the ass to deal with when trying to resolve a responsibly reported vulnerability: they often don't seem to have qualified people triaging inbound reports, and when they do finally acknowledge the correct severity of a reported issue it can take years before they finally push out a fix. And to top it all off, their core security counter-measures (e.g. ASLR and NX) are useless as anything more than marketing fluff because they're not implemented consistently.
Seriously, I've been in the security field for almost 15 years and dealt with reporting vulnerabilities to dozens of companies. Microsoft is a pain to deal with because of their compatibility matrices and long release cycles, but they're generally competent. Whereas Apple is just an absolute train-wreck. The only reason every Mac isn't infested with malware is that they're not a big enough chunk of the market for it to be worth the effort. If they ever cross the magic 15% threshold they're in for a very rude awakening.
Your guess is correct; for rarely followed code paths it does take significantly longer to (aggressively) optimize the code than it does to run it. Also, premature optimization can generate pathologically suboptimal code, meaning the performance can be much worse than the unoptimized case.
My understanding of how Crankshaft works is that the emitted code keeps some basic information about the data and frequency for any given code path (it's probably function level, but I don't know the code so I can't say for sure). Once the data and frequency of travel crosses a threshold the code path gets flagged for aggressive optimization. This kind of housekeeping adds very little overhead, so the decision cost overall should be very low. And the useful thing about spot optimizations like this is that their relative infrequency means that you can afford to do really aggressive optimizations that would be far too expensive to run over all of the code at load time.
The funny thing is that none of this is new. It's all decades-old compiler research stuff that mostly evolved out of the Self language. And Mozilla's tracing engine attempts similar optimizations, although it uses a different technology with different strengths and weaknesses.
If you're using SunSpider as your sole benchmark then you're already behind. SunSpider has outlived its usefulness (which the article touches on). In order to get a win of a few hundredths of a percent on SunSpider you have to add in premature optimizations that hurt page-load times and the performance of long running JavaScript applications. (Or you could add some dubious optimizations that are targeted specifically to the test, but that sounds a bit like cheating on a benchmark to me.)
SunSpider was good for it's time because it set a minimum bar for all browsers. However, the beta versions of all the new browsers are now within a hair's width of each other's performance on SunSpider. Rather than split those hairs, we need a new generation of tests that more accurately models real-world usage and JavaScript in the large. Mozilla and Google are both moving in that direction with Kraken and the V8 benchmark suites (respectively), but it's just a start. I'd like to see comparable benchmarks from every JS engine maker, or maybe a broadly-scoped, independent benchmark.
This is pure marketing. If they want to prove to me it's secure, ask for a public code review and reward those who find clear problems, and compile from that reworked code.
The codebase (minus PDF, Flash, and branding) is open source. Google pays out anywhere from $500 to $3113.70 to anyone who reports Chrome/Chromium security vulnerabilities to them. And if you look at the release notes on Chrome and Safari it's obvious that Google has a full-time team searching for and fixing security issues in both Chrome and WebKit. I'm not sure what else you want them to do, because they're already going well beyond anything you suggested.
You "do a lot of internet marketing" and you don't understand the difference between returning a competitor's site as a search result (what you identified) and stealing a competitor's search results then presenting them as your own (what is being accused)? Might I suggest that you consider a different profession in which you might be more qualified?
If you don't like the single user version then install the system-wide version from the google pack. And it doesn't leave past versions around; it leaves exactly one previous version when it's updating because it uses differential compression against the old version and falls back to the previous version if the update failed.
Kraken seems biased heavily toward things like looped and nested calculations, which is where tracing should be a big win. However, it avoids property access, dynamic allocations, and other areas where JaegerMonkey doesn't shine, but are an essential part of web applications.
This is not to say that every JavaScript team doesn't take a similar approach to benchmarks, but it's really hard to assess any of them accurately when everyone is playing the benchmark game.
I'll try explaining this again. SunSpider doesn't perform sufficient runs to take advantage of the tracing logic. And given the way the test is designed you will actually take a performance hit if you burn many cycles on front-end analysis. So, you consistently hit the unoptimized path where a good implementation uses simple translation logic for emitted instructions, along with a fast and light-weight assembler. (Comparing to YASM is silly, btw, because the needs of real-time JIT are very different from compiling in advance.)
Since Mozilla already had most of the instruction generation logic from their old bytecode implementation, and the test isn't hitting their trace optimizer, the biggest improvement here is coming from the introduction of the Nitro assembler. That's not true for most other JS benchmarks, but it is true for SunSpider. This is why I said I want to see their performance on benchmarks that would take advantage of their tracing optimizations in real-world scenarios--not a test like SunSpider which is heavily weighted towards the compilation speed and baseline (unoptimized) execution speed.
Seeing that Firefox on a few weeks ago was starting to lag pretty severely behind Chrome, I applaud and thank the Firefox team for their hard work. This is also a boon for their technique, the so-called "shotgunning" method of pushing through compilation the old way if it will complete faster than the optimizations. I had become afraid I might have to move to Chrome, looks like that won't be necessary.
You don't seem to understand how JaegerMonkey works, or what the SunSpider benchmark actually tests. The entire speedup here can be attributed to Firefox not compiling JS "the old way." Instead of defaulting to bytecode like they were previously, they always emit compiled instructions via Nitro's assembler. And given how the SunSpider benchmark works, all that is being tested is their parsing plus Nitro's assembly. The SunSpider benchmark doesn't even run long enough for Mozilla's tracing engine to be a significant factor (because the benchmark was created by Apple to showcase the performance of Nitro). So, not to be dismissive, but it seems like Apple (as the creator of Nitro) is more responsible for the speed increase.
Kudos to Mozilla for the overall improvement, but I'd really like to see results on a benchmark not so heavily biased to such uncommon use cases (compilation speed without hot path optimizations). In particular, I'd like to see benchmarks of common use cases that factor in the performance of their tracing engine, which is the piece of their stack that Mozilla has invested so heavily in. The Kraken benchmark provides some interesting stress tests along those lines, but it's still very narrowly targeted and not representative of current or anticipated use cases.
Except their data doesn't actually show that, and Firefox 3.6 has far worse absolute performance than the other browsers. So, the effect they're seeing is probably just the other browsers (including Firefox 4 beta) performing much better, but hitting a wall due to cache pressure and/or IO bottlenecks. Whereas Firefox 3.6 is slow enough that it appears to be scaling well, but really just runs slower than the system can perform.
It's not $400 per bug. Many of the bugs were discovered by Google employees, who don't get rewards. That pushes the average down. However, it also makes Google possibly the only company that appears to report all vulnerabilities they internally discover. MS doesn't report any internally discovered vulnerabilities, and even Mozilla will lump numerous internal discoveries under a single bug ID and CVE.
FWIW, they thanked members of the Chrome team a few months ago when they announced sandboxing support in an upcoming version of Acrobat Reader.
You forgot the part where the hypothetical researcher has privately reported numerous critical vulnerabilities to the hypothetical company and waited months or years for fixes. You also missed the researcher providing two different fixes for this particular vulnerability in his disclosure announcement. But hey, why make a fair comparison when you can resort to sensationalist slander?
That should be the first thing anyone familiar with Windows architecture notices. It means that it's an escalation from an account that's already running at elevated privilege (at least, it is on Vista and beyond).
So, it's definitely a security bug. But it seems like a disproportionate amount of noise for a local privilege escalation requiring higher than normal privilege to start with.
You have this backwards. I can point to every major browser, along with research directly addressing the topic. Whereas you haven't provided one iota of evidence to back up your misguided and ignorant statements.
Since it's obvious you have nothing of value to contribute, I'm just going to close this out with a suggestion. When confronted with a topic you obviously know nothing about, please resist the temptation to make noise just so people will notice you. It just wastes everyone's time and prevents you from actually learning anything.
You're conflating a few different things. There's origin security and there's local client security. Origin security is what protects you from one site accessing browser data from another site. Any discussion of extension permissions would apply primarily to origin security, because once you install anything with local client access you've already lost control. And when considering origin security, separate profiles within the same OS-level user account provide one method of strict enforcement.
Now, if your concern is client level security against exploits (not malicious extensions or plugins), then you're far better off relying on the Chrome sandbox over a separate user account. The sandbox provides vastly lower privilege and much smaller attack surface than a normal user token, and OS-level privilege escalation vulnerabilities are far more common than sandbox bypasses. You can certainly use your approach in conjunction with the --no-sandbox option in Chrome, which should allow Chrome to work with runas. However, you'd be downgrading your security with that approach.
The important thing to consider, however, is that no user should be expected to invest their own effort in a multiple profile solution. So, until someone creates something like the Chrome sandbox but with per-process origin isolation, there won't really be a general purpose solution providing a superior form of origin based security.
Not only have I read the paper, I've worked with a few of the authors on this subject matter. And that's why I know that it's essentially impossible to provide a useful extension API that is not also vulnerable to intentional abuse. Claiming the opposite is akin to claiming you've refuted Gödel's first incompleteness theorem. And if you've succeeded at either, I'd like to see the evidence. (Just a heads-up, you're starting to line up a pretty tall list of things you'll need to accomplish to support your arguments here.)
There isn't anything like "reads password data," nor could there be without drastic changes to the DOM standard and how JavaScript is implemented in modern browsers. The way the system works is that the installation manifest states what origins a content script will run in. And any script executing within an origin has access to all that origin's data. This is conveyed to the user with a message like "this extension can access data from site X.com" or "this extension can access data from all sites."
If you have a proposal for something better, then please share it. But the Chrome extension security model was well researched. And it was apparently considered good enough that Apple and Mozilla are creating similar models with Safari and JetPack.
I think you may have intended to reply to someone else. I was simply answering a question on NoScript's capabilities.
Also I'm quite familiar with running multiple profiles; my job would actually be impossible without it. In Chrome you simply pass the --user-data-dir switch. I don't see how that's any worse than running Firefox with the -P and -no-remote switches (or the old way requiring env vars). I am curious how you run IE under a separate profile without using a different Windows accounts. I didn't think that was possible, and instead use runas to get an alternate profile in IE.
It's just sad that you find it perfectly acceptable to comment like this on an application you obviously know absolutely nothing about. Chrome actually does run extensions in a sandbox. It also warns on installation of an extension, and explains what permissions that extension requires. If an extensions attempts something require a privilege that wasn't in its installation manifest the operation fails. As I said in another comment, the UI has issues and could certainly be improved, but the fact is that Chrome currently does everything you just implied it fails at.
Chrome already lists the permissions an extension requests at installation. The UI on that interaction is junk, so you need to be a fairly knowledgeable user to make heads or tails of it, but the information is definitely there.