It may have happened to you. You're typing a password in a web page, and suddenly, a window pops up, with a text field inside it, and since you did not notice it at once, you password displays in clear in the other window.

There are sometimes very critical security updates for applications (like the last Pidign-Update).

Unfortunately the Update Manager doesn't inform the user, that the update is only effective, if the application is restarted after it.

Since suspend-2-ram works for now on many computers, some applications are only seldom restarted (e.g. Pidgin may run for several weeks).

In the case of pidgin this is even a security risk, since an application with a security leak might run for several weeks until the last security fixes will apply.

Currently, there is no way of knowing how secure a password is. This often leads to users making insecure passwords, which is a risk to security.

DNSSEC is going to be the next "big thing" in DNS. Fedora is implementing it, Microsofts implements it in Windows 7 and Windows Server 2008 R2.

Ubuntu must have good support.

See http://fedoraproject.org/wiki/Features/DNSSEC for affected packages etc.

It sometimes happens that a network connection is dropped while using a VPN. The network connection is quickly re-established without problem, however the VPN remains disconnected.

This is a security issue and very inconvenient for the users.

I propose that if a network connection drops while connected to a VPN, after the network manager reconnects to the network it also automatically reconnects to the VPN.

Right now, if you are using a terminal, sudo timeouts after 15 minutes. Great! However, if I close that terminal and open up another one, that second terminal magically has sudo privileges until the timeout. This is not intuitive - if I give Terminal A sudo access, why should Terminal B also get it? Uninhibited root access for 15 minutes on any machine is not a good idea. Having all sudo privileges cut when the terminal is closed (and confining them to only that terminal) would give an immediate seal from malicious (or ignorant) users, increasing the local security of our Ubuntu system. Keep the 15 min timeout in place as well, and you have yourself a very secure computer.

Users should be warned when they connect to a network which is obviously insecure (such as connected to a Hub instead of Switch).

Its quite easy to program. If SYN|ACK or ACK packets are received which are directed to another MAC address, we know its insecure.

There are algorithms too which can even help detect Man-in-the-middle attacks (to identify when its very likely someone is trying to intercept/change your traffic),however, this is more difficult to program.

We should be trying to provide the highest level of security possible to users.

Many of the time, I hear complains from my friends that they are getting infected after receiving files from Linux Users. The problem is that, 99.99% of the malwares are targetted towards Windows, thanks to its ill configuration and user-base. So, it is very possible that any malware gets introduced into a Linux Box, and resides there. We won't be able to detect it, and won't find it necessary too, since Ubuntu is nearly unbeatable by Viruses. But when sharing files with Windows users, the virus infects their System, giving rise to an ill conception that Ubuntu is infected.

I would appreciate it if both the brainstorm and ubuntuforums.org would be protected via SSL for login and cookie exchanges.

Virtually all other sites related to the wiki, documentation, launchpad, etc, use SSL, and I wish the same could be said about these as well.

In a recent forum discussion, some felt that there's no point to protecting those sites. But most will agree that many people use the same password for everything, and even though a compromise of a forum password may not seem like much, it could be an issue elsewhere.

Case in point, all wiki modifications show the IP address of those that make the changes. If this person uses the same password for the wiki as their forum account, not only is it a risk to the wiki, but if their personal machine is remotely accessible via SSH, etc, then that user is also at risk if the password is also the same on their computer.

Yes... people need to follow best practices... but if you have the ability to help people and it comes at virtually no cost to you, then why not?

Hope others feel the same way. Thanks for listening.

Ubuntu updates are currently delivered via standard HTTP calls to the repos. This is problematic for a number of reasons, including the following:

1. Possession of certain software (e.g., strong crypto [GnuPG], unapproved chat protocols, Tor) is illegal under certain repressive regimes. Plain HTTP fetching of these packages exposes users living without basic human rights to legal liability for possession of certain software. Any police state monitoring its subjects' Internet usage can identify and arrest those using these packages with trivial ease. This is the most practical of the problems with HTTP updates.

2. The update process lacks end-to-end integrity. While it is true that packages are signed, adding SSL to the update process adds another layer of security and integrity to the process by ensuring that the update stream cannot be intercepted or tampered with. This could, hypothetically, avert an attack should a future vulnerability be discovered in signing verification logic, or should a crucial signing key be compromised. End-to-end SSL, with verification of Canonical's certificate by the update manager, ensures that all update packages must pass through official servers. This problem is currently more hypothetical than practical.

3. The update process exposes the identity of software running on client systems. End-to-end SSL increases the difficulty of identifying which packages are actively in use, and deprives an attacker with read access to network traffic of important intelligence which might be useful in future attacks (such as in the case of an attacker who compromises an enterprise router). While it is true that active packages can be guessed at by watching the times and sizes of downloaded updates, this adds additional difficulty to an attacker's efforts. This problem is quite hypothetical.