A stylus is great for taking notes. Try writing an equation with keyboard, mouse, or finger. It is not fun.

Parent is right in that we are ultimately at the mercy of our browser, operating system, and the individuals and tools that built this software. On the other hand I think grandparent is correct as much as it would be a good idea to spread the trust and also a good idea to have an audit of the certificate authority and its certificates. Just like when you purchase a product, you see what other individuals and organizations say about that product before buying it. The same should be of certificates and the organizations they are issued to. Also, I would prefer certificates that are signed by multiple CAs (with good reputation) over just a single CA.

That seems like a good idea to me. And when view the certificate in your browser, the browser should be able to connect to the certificate authority, and you should be able to get a bio of the certificate, check if is revoked, and write and view complaints on certificate.

Verification of SSL server certificate is not enough to protect your account. There needs to be additional 2 way authentication, so both sides can prove they know the username password/key to the account. So if the certificate does get compromised, you will still be protected from man in the middle. Here is one such protocol: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

A good, audible electronic voting system, would not rely on a specific voting machine. After you vote, you should be able go home, get online and validate that your vote record is correct. Your vote record would be stored and replicated in a number of independent databases. If fraud is detected in your record, you could bring your voting receipt and dispute your vote. If someone voted with an ID/SSN of someone not allowed to vote, that voting record could be rejected after the fact. While in such as system there is risk that someone could crack the database that ties your ID to your voting record, I would rather take that risk, than risk having my vote be diluted by fraud.

I very much wish Microsoft or Linux would take on this challenge. I very much dislike having to fully trust every application I install to be fully vetted.

I would prefer by default that applications are restricted from accessing any directory but their own and that the user can add or remove permissions to directories as needed. So if you want your editor to access only your Documents directory, you can restrict it to that directory tree. Applications you trust like file explorer or backup you allow unrestricted access. Other applications like games probably don't need access outside themselves. Most applications don't need to modify exe files. While not perfect it would give me much more peace of mind than what the current situation is.

Are you exaggerating when you say "massive handouts"? My understanding is that the oil industry is allowed tax breaks that are equivalent to what other industries get, and they do not get the direct subsidies that say wind and solar get. Depending on what tax break that is being considered this is 2-4 billion a year, maybe 2% of their profit.

http://www.usnews.com/news/blogs/rick-newman/2012/03/29/why-big-oil-should-give-up-its-tax-breaks
http://www.reuters.com/article/2012/03/29/us-obama-energy-idUSBRE82S11P20120329
http://www.nypost.com/p/news/opinion/opedcolumnists/the_prez_oil_tax_break_lies_Y2Yj6KCU9QIO0BKHs1Be7M
http://www.pbs.org/newshour/bb/politics/jan-june11/oiltax_05-12.html

Accidentally modded you down, replying to undo this.

I agree 100% that movement towards a micro kernel would be a huge improvement. Now if someone could develop a CPU intended for a micro kernel.

As for programming languages, I think it is the OS that needs to do a better job, not the language itself. I want to be able to run any application, driver, or library binary and not have it take over my system. Most components should be installed with limited permissions, and only expand permissions as needed, and it should be easy to rescind permissions later on. Libraries should be in a separate context from applications, and so if an application uses a compromised library, the library can't look at the applications memory.

There should be a way to monitor and control the OS through a 3rd party JTAG like device. Where it can inpsect any aspect of the system; verify checksums of applications, drivers, etc; freeze tasks; and halt the entire OS if it needs to.

Encryption/authentication and certificate/key management should be handled on a dedicated secure device . It only takes one security flaw, and your computer is at risk to having all of its passwords compromised. When an SSL connection is made, your computer should never get a hold of any security information necessary to establish the connection, only given the temporary key material to make a single connection, or better yet have its connection be completely controlled through the security device.

Require a patent holder to set a price for every use of their patent. For each use of the patent a 50% tax must be paid to the government. One purpose of the tax is to keep the patent holder from setting a riduclous use price on the patent.

Anyone can use that patent if they pay that price per use. Where 50% of the use fee would go to the patent holder and 50% would go to the government.

This might not solve every issue with patents, but it is a step in making patents more fair. It prevents complete monopolization of an idea. It prevents someone from making ridculous claims on worthless patents. It puts a fixed value on the patent use, preventing someone from suing an infringer for some arbitrary amount.

I agree; I have a hard time understanding how Republicans can argue the current practice is free market. I generally believe in the principles Republicans espouse, but in practice I often do not see how policies align with principles, and this is another example.

I have heard the arguments that service will suffer if there is not complete ownership of a given band and I think that is a reasonable argument. How will different carriers share the spectrum? I do not think the strategy used with the 2.4 GHZ spectrum will be acceptable in all cases. So I would like to hear what types of strategies will be implemented to make this work.

There's also no such thing as 100% bug-free.

int main() { return 0; }

Are you sure your are correct in saying Browser ID "doesn't give the authorities full power to access your accounts"? Your email authority has your email password, which is what you use to setup the certificate and keys. What information does it lack to prevent it from setting up its own keys and establishing a connection and logging into to one of your accounts?

One other nice feature to add to the secure device, is being able to break an existing connection. So if maleware did compromise your browser, and once you logged out, the maleware kept the connection up, it could start pulling money out of your account. It would be nice to be able to break that connection by requiring periodic rekeying or in the case that the secure device is just a proxy then it would be as easy as being able to disconnect the connection at the secure device (like a safety valve).

Also adding ability to audit the data over the secure connection by your secure device, looking for insertions would be another nice plus. This would be possible if your secure device was a proxy.

Also another feature is a simple side band communication protocol that could be used for confirmations between the site and your secure device to confirm transactions between the browser and the site . Like do you really want to transfer the money to some account? In other words the browser would never see this confirmation, and so maleware would never be able to function.

Your on the right track with the UI being part of the problem.

We should never give anyone our password, including the site were connecting to or our own computers which could have maleware.

Instead passwords should be stored encrypted on a personal secure device with say a USB connector, whos software and hardware have been well audited, with a touch screen keypad for entering passwords.

It could work in this way. With your browser you make a SSL connection to the site, the site challenges you, your browser sends the site's public key and challenge over encrypted connection to your secure device. Upon receiving the challenge, your device asks you if you would like to connect to site with this public key, on behalf of browser xyz with session id xyz, where browser is previously authenticated, and session id is a random id displayed by your browser. Then it asks you to enter the password/pin/fingerprint, or whatever security you have setup on your secure device. However before sending out its challenge response, the secure device sends its own challenge to the site, asking for confirmation that the site is really the same site you originally setup the password for. After getting the challenge response from the site, and verifying the site, the secure device sends the challenge response to the browser, and the browser forwards that response to the site, and then use of the site can go forward.

This has a number advantages: 1) You never gave our your password to anyone, but instead a key is generated based on the public key of the site you are connecting to, and a random key generated by your secure device, and the generated key is encrypted to the site itself, so that only the site can see this.

2) Additonal authentication over the existing signed certificate scheme is done. This does not protect the first time connection, but does protect additional connections made, which gives you a lot more protection in that all aspects of a given site must be compromised for you to get spoofed, in otherwords the site's private key, trusted cert, and the key you share.

If for whatever reason you lose your secure device or it is compromised there will need to be a way to invalidate your accounts, and so that will require some kind of group of trusted 3rd parties such as bank, email, or whatever you choose. This might be another set of passwords, background questions, etc. but this is not something you are going to do every day.

Also for additonal security, it would be nice for servers to be able to quickly see if a secure device has been compromised by auditing with the trusted 3rd parties when it is able to do so. The site could take the first quick measure of suspending an account, and then require the much more careful measure of reestablishing an account to its full capability.

For first time connection to a site, there would have to be additional security measures, and that is where a 3rd party (or group of 3rd parties) make sense to help in that establishment of trust. Where your secure device could force authentication of a site with 3rd parties, and the site could force authentication of your secure device with 3rd parties, before you agree that you are both trust worthy.

Might as well tie this secure device to credit cards as well, in that your secure device becomes your credit card.

Perhaps what I just described could be better implemented in a new SSL like protocol using the secure device as a proxy setup by your browser.

This would require an overhaul of websites, browsers, and so on, but it is about time we develop and industry standard for solving this nagging problem.