The above post could only be considered insightful if you didn't read the article. If you look at how Google implemented this feature you'll see that, with a possible rare exception of the first point on certain searches, none of these arguments apply.
Someone please mod this post up. It's the only one that addresses the real issue. When people talk about IE's integration with the OS they are referring almost entirely to ActiveX and Browser helper objects. These are the real root of IE's security and malware holes.
So have you looked at the bug, because if you did you'd realize that even bringing up that bug is dumb. It comes down to this:
1. You install FF and manually change the install directory to %SystemRoot% 2. You Unininstall FF 3. You select the option to remove the install dir
Calling this a bug is like calling "rd %SystemRoot%/S/Q" a bug. If a user is advanced enough to change the install directory and uninstall options, they should realize the impact of what this does. End of subject.
Honestly, it shouldn't have even been a question and was just the result of poor research or caving to troll pressure. Grow up children.
Wait a second, one of the big pushes with the.NET CLR was to make assemblies that could be aggressively optimized. For example, the flatenned-tree structure of the CLR is for improved JIT efficiency. I'm no expert and honestly haven't benchmarked the two, but I question what you base your statement on. Please provide some evidence to support your point and clarify the issue.
If you compile for the CLR you should be able to run the produced assembly on Mono. Also, the Mono guys have been working on a VB.NET compiler for a while, though I have no idea what the status is.
Guess it's a personal preference thing. I like that the styles aren't nested, given the c-style format and that most people don't indent. Although, at first I thought your post meant styles aren't inherited (ie. cascading), which really confused me.
There are two main reasons that I've encountered. First, Firefox does not yet have easy integration with Windows domain policies to control system and user settings. This is considered a big drawback but could be remedied quite easily with some wrapper scripts. Second, there are a lot of corporate intranet apps that are IE proprietary, which is a real big show stopper. That said, I've seen some really large businesses that are testing the waters.
For development work they are still extremely useful. You can make a test profile and not risk screwing up your default profile. Of course, the same thing could be done with a test user, but it's easier to use a different profile. I assume that's why they buried it so deep in Firefox but didn't remove it entirely.
Given the route that MS is taking with.NET, Longhorn, and Avalon, do you think that it is important to push more focus onto using the Mozilla technologies as a rich client application platform. Specifically, can we expect to see functionality such as an XPI sandbox security model, cross-language integration, or a virtual machine implementation for more complex applications? I realize that has been proposed before and some of it exists with MonoConnect and other efforts, but is their a roadmap for this as a Mozilla Foundation sanctioned effort? If so, when should we expect to see it and in what form?
Someone mod the parent up because that is extremely pertinent question. Personally, I would love to see the Mozilla Foundation incorporate a bounty system for donations. I expect that would significantly increase the amount donated because it generates personal "buy-in" on the part of the individual. It would also give some concrete value to identify what features users really want to see.
I just have a comment on the memory usage issue. MoFo is moving the apps to a shared GRE with either FF 1.5 or 2. It's part of the whole XULRunner thing. That should result in a much smaller memory footprint for the combined apps as most of the code will be shared read only pages in memory. This will also make mozilla based apps easier to write and integrate. It's interesting that the Firefox development originally moved away from the integration, but now they're reincorporating it in a more structured and less monolithic form.
There is a trivially simple way to address damages that fits entirely into the spirit of the GPL. The license specifically requires that any modifications to the source also be open source. So, when suing for damages, you sue for unrestricted access to the source and any associated legal costs. The purpose of the GPL is not to generate revenue, it's to guarantee that the code remains open.
It's pretty easy to make Apache chrooted under linux. With Apache2 you still need to allow dynamic libraries though, which often bothers people. Having hardened both Windows and Linux servers on a regular basis, I'd pick Linux every time. It can be locked down much more than Windows. I haven't found anything that compares to a combination of PP buffer protection on binaries, chroot jailed services, iptables, and SELinux policy. I just don't understand why more vendors haven't tried to create default installs that support this level of security.
The fact remains. Unless the spyware application is run under an account with administrative privileges, it is not possible to damage anything other than your own profile (including data) on an up to date system. A non-admin user simply does not have permission to modify the files and registry keys necessary for a deeper attack. End of story.
As much as I prefer Firefox, it will eventually be vulnerable to the same type of spyware that the post SP2 versions of IE are. Firefox's extension mechanism is vulnerable to the exact same methods employed with ActiveX controls in IE. Its prompting for installation is very similar, except the limiting measure is more the server of origin than a signature. In the end, most spyware is installed through social engineering, and FF and IE are about the same at this point when it comes to warnings and prompts. Over-complicating the extension install process will generally only make end user diligence worse, so that's a bad idea.
To sum up again, the best way to avoid malware is to not run as a user with administrative privileges; use runas when you need to alter the system. It is still possible to trash your own profile of course, but the chances of damaging a properly patched system are pretty slim. If Windows software supported this more easily and everyone followed it, most of the malware we see would disappear.
Actually, the previous poster is 100% correct, and I think you misunderstood the point. For "convenience" default Windows XP does not allow you to log in as the administrator, however the account you create at installation is a member of the Administrators group. I think the previous poster was attempting to humorously point out that this is even more insecure than just logging in as administrator, because the average user doesn't even understand it's a privileged account.
Well, I had mod points to use, but I thought your comment merits an explanation rather than modding you down, so here goes. In Windows (2K, XP), if you are running as a normal (non-admin) user, then deleting the users profile should always remove any spyware infection. In fact, due to the way most spyware is written it will not even be able to infect your system if you are not running as an admin. I suppose there could be exceptions that take advantage of escalation exploits, but I have yet to see one. The root of the problem is that most people don't even know it's possible to not log in as administrator. The inherent advantage on a un*x system is that account and privilege separation is ingrained into the mind of the operator and the design of the system. Any un*x user with the smallest clue does not run regularly as root and is suspicious of anything that requires root privilege. The modern (not 9x based) Windows OS's all support this functionality also, but you really have to be an experienced admin to run a system this way. This is without question a deficiency not in the base OS, but in the policies of software developers (MS is very much included). Simply put, as long as the user browses the web at the same privilege they install software, these kinds of infections will continue. This is regardless of your browser.
JPEG 2000 compression is wavelet encoding. This type of encoding allows you to selectively increase accuracy (at an increase in data size) until the compressed image is eventually identical to the original. From what I've read it even has a very good compression ratio at the lossless level. To vastly over-simplify, think of it as a far more advanced approach than interlaced GIF for progressive image retrieval.
He's not wrong about the pitfalls of C/C++. It's just that his argument is downright silly when taken in the appropriate context. The.NET "unsafe" code segments are really no different than JNI, except that they integrate much more cleanly into the platform. As much as I dislike Microsoft in general,.NET is an extremely well designed and secure platform. I say this as someone who has spent almost a decade making a living performing software security assessments and developing secure architectures. If you take the time to research it you will find that.NET really feels like the next incremental step after Java, and it takes advantage of a decade's lessons learned in Java.
Define crash. I find it an insane nuisance that an embedded instance of IE can die and force my desktop shell to have to reinitialize, or even require a log off to fix it. And of course games will crash your system on a semi-regular basis, but that's really more of a driver issue. Plus, if you log in with admin privs a malicious app can trash everything. The first, issue was Win specific, the second will take down any OS. The admin priv issue is OS wide also. The difference being that Windows is the only OS I know that makes it painful to properly run in a multi user environment. Most modern Linux distros have been doing a good job of this even for home users. You log in as a normal user and any administrative action prompts you for root credentials. Microsoft, however, has still not caught on that multi-user is not a business only proposition. But if we're just talking about hard reboots, then you are correct. Just like any pre-emptive protected memory OS, a single app should not be able to unintentionally crash the OS.
I think the lock-in is deeper than most people understand. Exchange is not just a mail and calender server. It's a groupware application platform with email and calendaring installed out of the box. But that doesn't even really cover the half of it. Even if you could replace those two functions, you'd be left with all the other commercial and proprietary applications that are tacked on top of it. This includes everything from MS project integration to third party commercial and home brewed Exchange applications, like hours reporting and employee surveys. I've seen a lot of things built on top of Exchange, and that's what would need to be seamlessly replaced. This is the same problem with the office applications. It's an issue of existing functionality and lock-in versus the cost of change. Really is a shame that it's so painful to eliminate a dependence on MS.
The MAPI client-side API has an associated on-the-wire protocol that is undocumented; I think that is what he's referring to. Although, one could arguably skip that and use a combination of Window's LDAP, OWA Webdav, and IMAP support to provide the same functionality across platforms. I believe this is how Evolution works.
Re:Seriously... Why would you use this?
on
GIMP 2.2 Released
·
· Score: 1
I've always found this funny. 8 bits per channel should be perfectly acceptable if the values were weighted. For example, you can't see the difference between red 255 and red 254 with even weighting due to the smal difference in magnitude. However, red 1 and red 0 are quite visibly different for the opposite reason. As such, if you're really concerned about getting the most dynamic range represented in each channel, you should just weight the scale accordingly. Something like: red 0 = 0% red 1 = 0.10% red 2 = 0.22% red 3 = 0.48%...
red 252 = 96.4% red 253 = 97.2% red 254 = 98.4% red 255 = 100.0%
The numbers are totally fudged because I'm in a hurry, but it should demonstrate the point. You could still accept 12 or 16 bit values, you would just convert to find the appropriate weighted value. Of course, this does complicate the processing of the data a little, but it reduces the storage and memory requirements. Of course, this has been done forever with audio processing; I've just never seen it supported with graphics. Does anyone know why?
Slashdot Mirror
This has been in Mozilla for almost four years and it doesn't violate any standards. look at the "Is link prefetching standards compliant" item in http://www.mozilla.org/projects/netlib/Link_Prefet ching_FAQ.html.
The above post could only be considered insightful if you didn't read the article. If you look at how Google implemented this feature you'll see that, with a possible rare exception of the first point on certain searches, none of these arguments apply.
Someone please mod this post up. It's the only one that addresses the real issue. When people talk about IE's integration with the OS they are referring almost entirely to ActiveX and Browser helper objects. These are the real root of IE's security and malware holes.
So have you looked at the bug, because if you did you'd realize that even bringing up that bug is dumb. It comes down to this:
/S /Q" a bug. If a user is advanced enough to change the install directory and uninstall options, they should realize the impact of what this does. End of subject.
1. You install FF and manually change the install directory to %SystemRoot%
2. You Unininstall FF
3. You select the option to remove the install dir
Calling this a bug is like calling "rd %SystemRoot%
Honestly, it shouldn't have even been a question and was just the result of poor research or caving to troll pressure. Grow up children.
Wait a second, one of the big pushes with the .NET CLR was to make assemblies that could be aggressively optimized. For example, the flatenned-tree structure of the CLR is for improved JIT efficiency. I'm no expert and honestly haven't benchmarked the two, but I question what you base your statement on. Please provide some evidence to support your point and clarify the issue.
If you compile for the CLR you should be able to run the produced assembly on Mono. Also, the Mono guys have been working on a VB.NET compiler for a while, though I have no idea what the status is.
Guess it's a personal preference thing. I like that the styles aren't nested, given the c-style format and that most people don't indent. Although, at first I thought your post meant styles aren't inherited (ie. cascading), which really confused me.
There are two main reasons that I've encountered. First, Firefox does not yet have easy integration with Windows domain policies to control system and user settings. This is considered a big drawback but could be remedied quite easily with some wrapper scripts. Second, there are a lot of corporate intranet apps that are IE proprietary, which is a real big show stopper. That said, I've seen some really large businesses that are testing the waters.
For development work they are still extremely useful. You can make a test profile and not risk screwing up your default profile. Of course, the same thing could be done with a test user, but it's easier to use a different profile. I assume that's why they buried it so deep in Firefox but didn't remove it entirely.
Given the route that MS is taking with .NET, Longhorn, and Avalon, do you think that it is important to push more focus onto using the Mozilla technologies as a rich client application platform. Specifically, can we expect to see functionality such as an XPI sandbox security model, cross-language integration, or a virtual machine implementation for more complex applications? I realize that has been proposed before and some of it exists with MonoConnect and other efforts, but is their a roadmap for this as a Mozilla Foundation sanctioned effort? If so, when should we expect to see it and in what form?
Someone mod the parent up because that is extremely pertinent question. Personally, I would love to see the Mozilla Foundation incorporate a bounty system for donations. I expect that would significantly increase the amount donated because it generates personal "buy-in" on the part of the individual. It would also give some concrete value to identify what features users really want to see.
I just have a comment on the memory usage issue. MoFo is moving the apps to a shared GRE with either FF 1.5 or 2. It's part of the whole XULRunner thing. That should result in a much smaller memory footprint for the combined apps as most of the code will be shared read only pages in memory. This will also make mozilla based apps easier to write and integrate. It's interesting that the Firefox development originally moved away from the integration, but now they're reincorporating it in a more structured and less monolithic form.
There is a trivially simple way to address damages that fits entirely into the spirit of the GPL. The license specifically requires that any modifications to the source also be open source. So, when suing for damages, you sue for unrestricted access to the source and any associated legal costs. The purpose of the GPL is not to generate revenue, it's to guarantee that the code remains open.
They've been working on it for a while. Check out http://www.mozilla.org/projects/svg/
It's pretty easy to make Apache chrooted under linux. With Apache2 you still need to allow dynamic libraries though, which often bothers people. Having hardened both Windows and Linux servers on a regular basis, I'd pick Linux every time. It can be locked down much more than Windows. I haven't found anything that compares to a combination of PP buffer protection on binaries, chroot jailed services, iptables, and SELinux policy. I just don't understand why more vendors haven't tried to create default installs that support this level of security.
The fact remains. Unless the spyware application is run under an account with administrative privileges, it is not possible to damage anything other than your own profile (including data) on an up to date system. A non-admin user simply does not have permission to modify the files and registry keys necessary for a deeper attack. End of story.
As much as I prefer Firefox, it will eventually be vulnerable to the same type of spyware that the post SP2 versions of IE are. Firefox's extension mechanism is vulnerable to the exact same methods employed with ActiveX controls in IE. Its prompting for installation is very similar, except the limiting measure is more the server of origin than a signature. In the end, most spyware is installed through social engineering, and FF and IE are about the same at this point when it comes to warnings and prompts. Over-complicating the extension install process will generally only make end user diligence worse, so that's a bad idea.
To sum up again, the best way to avoid malware is to not run as a user with administrative privileges; use runas when you need to alter the system. It is still possible to trash your own profile of course, but the chances of damaging a properly patched system are pretty slim. If Windows software supported this more easily and everyone followed it, most of the malware we see would disappear.
Actually, the previous poster is 100% correct, and I think you misunderstood the point. For "convenience" default Windows XP does not allow you to log in as the administrator, however the account you create at installation is a member of the Administrators group. I think the previous poster was attempting to humorously point out that this is even more insecure than just logging in as administrator, because the average user doesn't even understand it's a privileged account.
Well, I had mod points to use, but I thought your comment merits an explanation rather than modding you down, so here goes. In Windows (2K, XP), if you are running as a normal (non-admin) user, then deleting the users profile should always remove any spyware infection. In fact, due to the way most spyware is written it will not even be able to infect your system if you are not running as an admin. I suppose there could be exceptions that take advantage of escalation exploits, but I have yet to see one. The root of the problem is that most people don't even know it's possible to not log in as administrator. The inherent advantage on a un*x system is that account and privilege separation is ingrained into the mind of the operator and the design of the system. Any un*x user with the smallest clue does not run regularly as root and is suspicious of anything that requires root privilege. The modern (not 9x based) Windows OS's all support this functionality also, but you really have to be an experienced admin to run a system this way. This is without question a deficiency not in the base OS, but in the policies of software developers (MS is very much included). Simply put, as long as the user browses the web at the same privilege they install software, these kinds of infections will continue. This is regardless of your browser.
JPEG 2000 compression is wavelet encoding. This type of encoding allows you to selectively increase accuracy (at an increase in data size) until the compressed image is eventually identical to the original. From what I've read it even has a very good compression ratio at the lossless level. To vastly over-simplify, think of it as a far more advanced approach than interlaced GIF for progressive image retrieval.
He's not wrong about the pitfalls of C/C++. It's just that his argument is downright silly when taken in the appropriate context. The .NET "unsafe" code segments are really no different than JNI, except that they integrate much more cleanly into the platform. As much as I dislike Microsoft in general, .NET is an extremely well designed and secure platform. I say this as someone who has spent almost a decade making a living performing software security assessments and developing secure architectures. If you take the time to research it you will find that .NET really feels like the next incremental step after Java, and it takes advantage of a decade's lessons learned in Java.
Define crash. I find it an insane nuisance that an embedded instance of IE can die and force my desktop shell to have to reinitialize, or even require a log off to fix it. And of course games will crash your system on a semi-regular basis, but that's really more of a driver issue. Plus, if you log in with admin privs a malicious app can trash everything.
The first, issue was Win specific, the second will take down any OS. The admin priv issue is OS wide also. The difference being that Windows is the only OS I know that makes it painful to properly run in a multi user environment. Most modern Linux distros have been doing a good job of this even for home users. You log in as a normal user and any administrative action prompts you for root credentials. Microsoft, however, has still not caught on that multi-user is not a business only proposition.
But if we're just talking about hard reboots, then you are correct. Just like any pre-emptive protected memory OS, a single app should not be able to unintentionally crash the OS.
I think the lock-in is deeper than most people understand. Exchange is not just a mail and calender server. It's a groupware application platform with email and calendaring installed out of the box. But that doesn't even really cover the half of it. Even if you could replace those two functions, you'd be left with all the other commercial and proprietary applications that are tacked on top of it. This includes everything from MS project integration to third party commercial and home brewed Exchange applications, like hours reporting and employee surveys. I've seen a lot of things built on top of Exchange, and that's what would need to be seamlessly replaced. This is the same problem with the office applications. It's an issue of existing functionality and lock-in versus the cost of change. Really is a shame that it's so painful to eliminate a dependence on MS.
The MAPI client-side API has an associated on-the-wire protocol that is undocumented; I think that is what he's referring to. Although, one could arguably skip that and use a combination of Window's LDAP, OWA Webdav, and IMAP support to provide the same functionality across platforms. I believe this is how Evolution works.
I've always found this funny. 8 bits per channel should be perfectly acceptable if the values were weighted. For example, you can't see the difference between red 255 and red 254 with even weighting due to the smal difference in magnitude. However, red 1 and red 0 are quite visibly different for the opposite reason. As such, if you're really concerned about getting the most dynamic range represented in each channel, you should just weight the scale accordingly. Something like: ...
red 0 = 0%
red 1 = 0.10%
red 2 = 0.22%
red 3 = 0.48%
red 252 = 96.4%
red 253 = 97.2%
red 254 = 98.4%
red 255 = 100.0%
The numbers are totally fudged because I'm in a hurry, but it should demonstrate the point. You could still accept 12 or 16 bit values, you would just convert to find the appropriate weighted value. Of course, this does complicate the processing of the data a little, but it reduces the storage and memory requirements. Of course, this has been done forever with audio processing; I've just never seen it supported with graphics. Does anyone know why?
Uhm, they are marketing it that way. It very clearly says it's a prerelease version.