Frank Hecker writes: > I think this comes down to the intended use case: Is our primary concern > protecting the typical Firefox, etc., user, who's primarily concerned > with surfing the public internet, or is our primary concern protecting > intranet users and providing tools for intranet admins?
Both goals are the same. For "typical" users, you simply provide a default security configuration that matches their likely requirements. For administrators and power users, you provide flexibility in the configuration to allow it to be customized to any security requirements. Remember, AOL went with MSIE as its browser even after it bought Netscape because MSIE provided tools and flexibility, whereas Netscape did not. > Arguably a typical Firefox user isn't concerned with what "zone" a site > is in; instead they consider each site individually: First they go to > Google, and then they go to eBay, and then they go to Citibank, and then > they go to "Joe's Parrot Blog", and so on. They make security-relevant > decisions for each site individually, and different users may make > different decisions for each site: For example, one user may allow > popups, etc., for Citibank (because they bank there) but not do so for > Bank of America; another user may do the exact reverse. That's why you have default binding to different zones, like MSIE (but perhaps with greater granularity). Unknown Internet sites with http go into one category; those with https go into another. And sites on the LAN go into still another category. Etc. The user can override any of this by specifically identifying sites or groups of sites to be placed into other categories, and/or by changing the default bindings. > Typical users (if they're anything like me) also make each "yes/no" > decision separately as they encounter new sites; for example, IMO a > typical user is not likely to sit down and say "let's create a > 'financial services' zone and populate it with Citibank, Schwab, > Fidelity, etc.", even if the user happens to be customers of all those > companies. Then provide something that lets them instantly assign a site to a specific category. You cannot provide flexible security without asking the user _something_. > Now, it's legitimate to argue that Firefox should provide better support > for intranet use, with use cases like the one you suggest. However > traditionally the Firefox developers have prioritized consumer Internet > use over enterprise intranet use, and IMO were and are right to do so. Considering how large a market the enterprise is, they might wish to reconsider. Also, many people use intranets and similar configurations even outside the enterprise. More importantly, the interests of individual users and enterprises are mostly identical. The same mechanisms that are useful for enterprises are useful for individual users, so there's no reason not to have them. > Again, I'm not arguing against ignoring the needs of enterprise users, > I'm just saying that they are not necessarily relevant to the needs of > typical users. I think it's also the case that a lot of the complexity > that you advocate doesn't need to be directly visible to users, whether > on the internet or intranet. In theory there's no need for even intranet > users to be exposed to an IE-style "security zones" model in terms of > the standard preferences dialogs; instead that complexity could be > pushed off to the tools used by admins to produce customized Firefox > versions and configurations for distribution to intranet users. How it's done is less important than the ability to do it. Ideally, security should be settable in every detail, for every site, individually. Since that is impractical to administer, though, having a generous number of categories with finely settable security and flexible binding to individual sites or site groups is the best compromise. This is how security has been done in other systems for decades, and its has proven its usefulness. -- Anthony _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
