On Saturday 05 April 2014 22:09:02 Alex Jordan wrote: > On Apr 5, 2014 6:12 PM, "Kradorex Xeron" <[email protected]> wrote: > > At this point, add-ons are no longer sufficient to protect users, this > > needs to > > > be a forced element into the core of browsers. Plugins will never have the > > level of hook access that that is needed and there will always be holes as > > these add-ons over-ride specific activities, they do not set the default > > actions by the core Javascript engine and not everything is hookable. > > This rings false to me. I cannot see anything here that isn't covered by > addons like NoScript and RequestPolicy. For any other browser, this might > be true, but in my experience Firefox's extension system is extremely > robust.
However, these do not set the default of a normal installation nor are they available by default, a user explicitly has to install these add-ons to obtain functionality that should be available as a core part of a browser. Consider what would happen if you needed an "Add-on" to your operating system to set filesystem permissions or to limit what users could do on that computer system. Most people wouldn't be able to secure their data and prevent the other users on that computer from accessing their data without installing anything. How does this relate? Easy: browsers are practically becoming an operating environment of their own with the level of code now running in their contexts and there is no way without blocking the whole browser to "firewall" specific aspects of it correctly as everything runs under the browser process. Most add-ons work by intercepting the various hook points, they do not fundamentally change how the browser is to work nor expressly disable aspects of the Javascript engine nor control how the engine may respond to calls that the extensions don't (or can't) hook, they simply get the call before it reaches the undesired point of the engine which still leaves potential attack surfaces to be quite large. One SIGNIFICANT example of this is how Javascript can leverage a Flash plugin to enumerate the fonts that computer system has installed. Many extensions cannot fix this as it and it requires relying upon Flash's mms.cfg to set 'DisableDeviceFontEnumeration'. The browser should be able to effectively disable that type of communication. Security on browsers shouldn't be an item of "extensibility", if APIs exist it's just a matter of providing a configuration interface as a core asset, even if tucked away on the "Advanced" tab sheet of the preferences. If it requires separate code of an extension to do the processing and logic of basic resource access security (think: ACLs), then the browser itself is insecure. The moment security becomes a matter of extensions and so forth is the moment security is largely forgotten by most people or it is unknown that specific asset can be restricted. Most users I talk to don't even know Firefox can have extensions installed to secure it, most think the extensions are just toolbars or buttons for "techy" types and that there's no extensions that would be pertinent to them. Security is a layered element, if the browser itself lacks security internally and permits a javascript engine to run without basic accountability without extensions, then the browser itself is insecure. Operating systems these days all have their own firewalls INTEGRATED due to the fact it was deemed needed. Prior to that operating systems needed permissions, so they were implemented. Now it is deemed needed to integrate security into the core of browsers because they too are an operating environment now where the browser executable is the kernel and the executable code originates from the Internet. Thanks, -- Kradorex Xeron <[email protected]> Founder, Executive Director Digibase Operations, Research and Development _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
