Specific features |
References |
- Flash content
- Ability to handle Flash content per page view* There exists extensions for blocking Flash content already. Build this into the browser natively. I would like to see some Flash content handling similar to how pop-up advertisments are handled in Mozilla version 1.5.x today. Make a dialog box for each new webpage wanting to show Flash content, with Allow, Block or Deal with later option. And this filter should otherwise block any content if enabled by the user.
|
n/a
|
- AJAX
- Ability to disable XMLHTTP* javascript calls entirely. AJAX rocks, but it could be a potential security threat (for example, I enter in my credit card number, and then think better of it. But too late! The asynchronous javascript has already sent my details back to some nefarious web site before I clicked "submit").
- Ability to see graphically if asynchronous calls are being made on my behalf (mabye add a flashing icon to the status bar?)
- Ability to selectively allow/disallow certain sites from using AJAX.
|
n/a
|
- Surf by IP protection
- Two new security options, which should be checked by default...
[ ] Disallow visiting sites by IP address (IP anywhere in the URL)
[ ] Allow local LAN IPs
(192.168.x, etc. for getting to your home router, access-point configuration pages, or some corporate intranets) By using these security options, you will quickly kill off all the "lasy phishers" who don't setup or register a domain-name for thier false site.
|
n/a
|
- Security preferences
- Automated user preference auditing with user notification of potentially problematic preference settings.
|
n/a
|
- Phishing protection
- Make it easier to report phishing sites
- Implement a phishing filter that learns automatically
- Consider intergration with something like PhishTank [1]
- Multi-provider support for local list checking (depending upon provider demand)
|
n/a
|
- Safer Browsing
- Like anti-phishing, but with a list of sites that are known or suspected of being a source of malware (virii, spyware, etc)
|
See bug 347849
|
- Script execution
- Integrate script execution whitelisting
- Allow cross-site scripting between whitelisted sites (for mashups)
|
NoScript
bug 320522
|
- Pop-ups
- Implement one-click viewing of blocked pop-ups
- Make printing popup windows possible
- Implement a way to block every pop-up window, regardless of the way it was requested.
|
- More on printing pop-ups
|
- Restricted Javascript
- Prevent window resizing
- Prevent hiding toolbar/controls
- Prevent capturing mouse events (overriding clicks, and obnoxious mouse-tracking scripts)
- Prevent floaters (or have some way to hide these layers)
- Prevent automatic form submission (or "Did you really want to submit this?")
- Trace window/panel with the history of form submissions and visited URLs, with the option of ask before submit everytime.
- Provide a way to prevent a browser window from being locked up by a Javascript loop which repeatedly produces a Javascript dialog, e.g. a "Stop script" button in Javascript dialogs.
- Per-site javascript settings, i.e. allow users to choose to enable "move/resize window", "replace context menu" etc, on a per-site basis, instead of just a single global option.
- Please, PLEASE don't forget Intranet and Web Application usage scenarios when considering the Restricted Javascript proposal. There are countless weblications that depend on one or more of the above. If the Javascript restrictions are not (at least) configurable, and possibly defaulted to 'no restrictions' for local or LAN-accessed files, then those applications will break or mis-function. Jabbott 10:32, 16 October 2006 (PDT)
|
n/a
|
- Cookies
- Add cookie whitelist funcitonality
- One-click block/allow cookies1
- Allow cookies from sites (on request) remain persistant even after the browser has been restarted
- Allow session cookies per window/tab so that multiple logins can be had to services such as gmail/hotmail simultaneously.2
- "Supercookies"
- Never accept cookies associated with invisuble images: single, pixel GIFs and so forth
- Extensions like "Extended Cookie Manager" allow you to enable or disable cookies for the current site. However, it is common that sites use redirection, and a different site for actual authentication. Something like login.google.com when browsing www.google.com. So, simple "enable cookies for this site" features are not effective.
- The "ask every time" cookie dialog box should have another checkbox: "Don't ask again". This is so you can deny a cookie, and not have many more dialogs pop up to deny. This would complement a "One-click block/allow cookies" feature.
- More granular cookie controls - allowing regex definitions of what cookies should be accepted or declined. Not just based on the source site but also on the contents of the cookie. E.g. I don't care what site it is from, I never want to accept a cookie that contains the string AD_ID, even if I accept other cookies from a site.
- Have an option to automatically allow session cookies, even if I asked to ask every time, like in Internet Explorer. The main use of asking every time is to be able to allow permanent cookies only for those sites you trust, and to make every one else to last only for the session. But session cookies will do it anyway, so it's a waste of time having to opt in each one.
- Cookie-Editor
|
1 Like "CookieCuller"
2 Like "CookiePie"
|
- Exploit Mitigation
- Please consider splitting all page rendering code into a seperate process running with reduced permissions, either using ACL on Windows, or as a seperate low-privilege user on Unix-style systems. Use IPC mechanisms to handle network interaction and requests to save files in non-sandboxed directories. Assume that a network deliverable attack will exist, please ensure that the worse that happens is that the rendering engine must be restarted.
- To secure a process on Linux, simply write to the /proc/self/seccomp file. The process will then only be able to communicate via existing file descriptors (be sure to close the X11 one) and existing shared memory regions. Only about four system calls are allowed for a process in secure mode: read, write, exit, and signal handler return.
- To secure a process on a domain/type enforcement system like SE Linux, use a separate executable for handling untrusted content. A separate executable is required so that the security system can wall it off, permitting only communication with the other components of the browser. (components being: separate UI, network, config file access, cookie access, cache access, other disk access)
|
|
- Extension installation
- One-click to permanently add site to whitelist
- One-click to temporarily add site to whitelist for this session
- Third-party signing and authentication by Mozilla
|
Extension Blacklisting UI Spec
|
- Virus/Malware protection
- Intergrate a sandboxing feature automatically. (Like Sandboxie -http://www.sandboxie.com/)
- Integrate virus scanning and malware protection for retrieved content/files
- Integrated support for 3rd party Anti-virus scanners
- Firefox to run in a "Protected mode" like IE7/Vista (see the Sandboxing above)
- See Exploit Mitigation comment above.
|
n/a
|
- Spoofing
- Employ some shared-secret anti-spoofing techniques1
- Prevent content and scripts from being able to spoof or mimic protected chrome
- SSL auth required for send password
- This is an optional, but strongly recommended feature suggested during install
- Sending password with FORM.send or Javascript.Send check if the page is SSL encrypted and will display an error message if there's no valid SSL certificate.
- Do not allow adding "*" to FORM.edit field from Javascript (avoid spoof)
- This way a user will get warning when tries to log in to an unsafe service, like phishing sites. All sites with authentication should have valid SSL certificate or should be added to "safe to login" list.2
- Add some indication of which site produced a Javascript dialog, to prevent dialogs appearing to come from another site in a tabbed session.
- Check digital signature of a web page based on some extended DNS records. That way if a site is defaced, it will be obvious. Note that SSL does not guard against defacement, but this will.
|
1 PassPet
2 details & discussion
|
- New technology support
- Extended Validation Certificate support
- Integrated PGP/GPG to sign/encrypt/authenticate text (eg Web Mail)
|
n/a
|
- HTTP authentication improvements
- Support for logging out of basic or digest HTTP authentication (RFC 2617 style)
- Implement a somewhat secure HTTP shared-secret authentication scheme based on SRP. The RFC2617 schemes are both very vulnerable to phishing.
- Show content of 401-unauthorized pages, and add widgets to login via forms instead of modal dialogs
|
See bug 355319
|
- Keychain support for MAC OS X / KDE / Gnome
- Save passwords in the OS-level Keychain on OS X, so that passwords can be shared between Safari / FIrefox / Camino / etc.
- Ability to switch to external password manager like kwallet etc. and to disable firefox standard password manager
|
n/a
|
General tasks |
- Improve user notification of insecure browsing situations
- Rather than pop up annoying dialogs when a site has a bad security certificate, simply perform the encryption without showing the lock icon. (make the https site happy without bothering or misleading the user)
- Improve handling of digital certificates
- Improve phishing protection UI
- Improve overall security UI
- Improve pop-up blocking UI and options
|
n/a
|
Integrated something like adblock.
|
n/a
|