Posted by: Anonymous
[ip: 74.225.160.107]
on July 26, 2007 05:42 AM
>> The problem is that many sites allow anyone to create their own pages on their site.
Could not have said it better myself. The question still remains if Firefox can find a way to give end users the convenience without this particular inconvenience. It can be argued that Firefox should not allow this just like it can be argued that end users should know better and website/portal makers should know better.
Ordinarily, if you go into someone's house and get attacked, you expect that the host failed with security. But what happens when the host disclaims responsibility and opens up land for any and all to come and set up shop?
One way to attack the problem is by specifically finding websites that fit this pattern (open to public and allow strangers to mingle underneath the same domain) and then trying to find specific solutions that work for the particular site. This can be laborious and can be subverted at any time by the website owners by readjusting their code.
A simpler more general solution is to have a blacklist of sites known to be problematic.
Perhaps abolishing integrated password managers is actually an even better solution.
The simplest way to get security has always been by recognizing that the domain name or url path (excluding the parameters passed to the page) separates attackers from the desired website. Once you use custom parameters to divide up a desired web destination from a competing web destination, it becomes almost impossible to find such a fine grained solutions. The most conservative approach would never even recognize the same webpage if visited under slightly different conditions (eg, if session state is maintained).
Because of how difficult it is for the browser to solve the problem (it can't without disabling a lot of functionality), I "blame" the website developers who effectively are delegating away power over items within their site to strangers. It's a business decision on their part. It may lead to millions, followed by lawsuits or to losing millions in lost opportunities. However, browser makers can add band-aids and do things to help their user base. The browser makers would be foolish to blame the website makers if in fact other browsers have some kind of solution in place (including disabling password management accross the board).
Here is my last hack at this: why not force super strong security with pop up flashing buttons whenever a "sudo" kind of action is required? We can build icons that represent various things. Through the icon use (visual feedback) and proper words of caution at the right time in a user friendly way, people will learn to identify dangerous features of sites and in what ways they may be dangerous. If in doubt, they go to the very fine manual button and read up on that icon before enabling that potential security risk. The very fine manual can explain well the risks of password fill-in, cookie use, javascript function X use, etc. In short, all the knives and ropes that can be used for both good and bad can have various icons. Users should be encourages to always surf with icon safety lock on. They can then remove the lock selectively for various pages (or portions of pages) or under various contexts (the FF people will have to design this well for useability). The key is making the security easy to unset and set back, have clear explanations, and not be overly bothersome. For the specific case being discussed in this story, Firefox can further allow for a quick way for the end user to see a picture of what the webpage looked like at the time when they entered the passwords (or other potentially sensitive information). The user can then quickly realize, this is the same site basically and accept or this isn't the same site and reject.
The moral of the story is that some problems do not reveal enough of their context to enable clear-cut solutions that can be invoked without any need for user intervention. This case of auto fill-in is one such scenario. Firefox should then focus on getting the end user to see the problem clearly (and timely) and without being burdened too much, eg, without too many false positives (limiting false positives without resorting to another MS Clippy is a goal). Websites that want to make things difficult for browsers and dangerous for users shall have their rewards.
Learn about Linux
Download Linux
Get Linux help
Knives to cut; ropes to hang
Posted by: Anonymous [ip: 74.225.160.107] on July 26, 2007 05:42 AMCould not have said it better myself. The question still remains if Firefox can find a way to give end users the convenience without this particular inconvenience. It can be argued that Firefox should not allow this just like it can be argued that end users should know better and website/portal makers should know better.
Ordinarily, if you go into someone's house and get attacked, you expect that the host failed with security. But what happens when the host disclaims responsibility and opens up land for any and all to come and set up shop?
One way to attack the problem is by specifically finding websites that fit this pattern (open to public and allow strangers to mingle underneath the same domain) and then trying to find specific solutions that work for the particular site. This can be laborious and can be subverted at any time by the website owners by readjusting their code.
A simpler more general solution is to have a blacklist of sites known to be problematic.
Perhaps abolishing integrated password managers is actually an even better solution.
The simplest way to get security has always been by recognizing that the domain name or url path (excluding the parameters passed to the page) separates attackers from the desired website. Once you use custom parameters to divide up a desired web destination from a competing web destination, it becomes almost impossible to find such a fine grained solutions. The most conservative approach would never even recognize the same webpage if visited under slightly different conditions (eg, if session state is maintained).
Because of how difficult it is for the browser to solve the problem (it can't without disabling a lot of functionality), I "blame" the website developers who effectively are delegating away power over items within their site to strangers. It's a business decision on their part. It may lead to millions, followed by lawsuits or to losing millions in lost opportunities. However, browser makers can add band-aids and do things to help their user base. The browser makers would be foolish to blame the website makers if in fact other browsers have some kind of solution in place (including disabling password management accross the board).
Here is my last hack at this: why not force super strong security with pop up flashing buttons whenever a "sudo" kind of action is required? We can build icons that represent various things. Through the icon use (visual feedback) and proper words of caution at the right time in a user friendly way, people will learn to identify dangerous features of sites and in what ways they may be dangerous. If in doubt, they go to the very fine manual button and read up on that icon before enabling that potential security risk. The very fine manual can explain well the risks of password fill-in, cookie use, javascript function X use, etc. In short, all the knives and ropes that can be used for both good and bad can have various icons. Users should be encourages to always surf with icon safety lock on. They can then remove the lock selectively for various pages (or portions of pages) or under various contexts (the FF people will have to design this well for useability). The key is making the security easy to unset and set back, have clear explanations, and not be overly bothersome. For the specific case being discussed in this story, Firefox can further allow for a quick way for the end user to see a picture of what the webpage looked like at the time when they entered the passwords (or other potentially sensitive information). The user can then quickly realize, this is the same site basically and accept or this isn't the same site and reject.
The moral of the story is that some problems do not reveal enough of their context to enable clear-cut solutions that can be invoked without any need for user intervention. This case of auto fill-in is one such scenario. Firefox should then focus on getting the end user to see the problem clearly (and timely) and without being burdened too much, eg, without too many false positives (limiting false positives without resorting to another MS Clippy is a goal). Websites that want to make things difficult for browsers and dangerous for users shall have their rewards.
#