Huffman menus

2008-01-16

Idea:
Ordinarily, when you install a program on Windows, it adds its icon to the applications menu in a directory named after the program, in a directory named after the company. This is convoluted and confusing. Think about it, is your own program menu organized? Linux desktop environments have their own system which a mini-SQL-like language for deciding where icons should go based on multiple tags. While this leads to much better menus, it still isn't very flexible. Instead, the menus should be calculated using an algorithm like Huffman to minimize the number of clicks to reach all your programs. The frequency of each program can be weighted by time to favor more recently run programs (so, for example, after you beat a game and get tired of it, the new game that you're playing instead will take its spot). It can be calibrated so there are only 7 menu items at each level and popular items can rise out of their categories, so programs that you run constantly will be at the highest level of the program menu, while the less commonly run ones are in their directory. If there are too many programs of a type, it can split into subcategories.

Pros:

• Commonly run programs will be easy to find
• It will intelligently arrange itself to your preferences automatically
• Small directories will be omitted in favor of the icons they contain
• Uncommon programs will still be in a logical place

Cons:

• Menus moving around forces relearning
• Requires people who make the icons to cooperate

Public key logging

2007-03-08

Idea:
If you are worried about checking on the status of a machine that may have been compromised, the safest way to do logging is to have it go to another machine so it can be write-only as far as that machine is concerned. Another way to have a write-only log file is to make it encrypted with a public key so it can only be read with a private key. To be safe, the private key would not be stored on the same machine. If the machine was compromised, they would only be able to delete the log, or try to remove sections of it blindly. Both would leave obvious signs of tampering. To make which parts of the log were when less simple, the machine could add random nothings to the log occasionally.

Instant message logs often record private conversations. Having these logs encrypted with a public key would help keep people other than you from reading it.

Pros:

• Have, in effect, write-only logs
• Even if someone takes your whole hard drive, they can't tamper with your logs (stronger than filesystem attributes)
• Don't need another machine to see signs of log tampering
• Others can't read your private conversations

Cons:

• Need way to store private key so can read logs conveniently but logs can't be read ordinarily

HTTP public key authentication

2006-06-29

Update (2008-01-16): TLS (section 7.4.6) describes client certificates, which can be used with HTTPS

Idea:
HTTP can use a username and password for authentication. It also supports hashing the password with a nonce to be safer. While this is useful, it still requires people to have different passwords for different sites to be safe, which doesn't happen in reality due to the complexity of managing all of those passwords. Other protocols, such as SSH, in addition to supporting password authentication, support public key authentication. This also secure authentication to different sites. They only recognize you by your public key and do not know your corresponding private key, and thus cannot impersonate you to other places. This would largely eliminate the need for managing passwords. The only password that you would need would be the one for decrypting your private key.

While not quite as good, you can use my set password bookmarklet.

Pros:

• Don't need to remember so many passwords
• Creating accounts is similar to as it is now. Just has an extra upload public key section
• Much more difficult to compromise the accounts (much stronger than a weak password)
• Both sides can recognize each other by their public keys
• Could integrate with GPG

Cons:

• Have to keep track of your private key, which makes use on other computers difficult
  • Use on remote machines compromises your private key anyways
  • Private key calculations could be done on external card (see credit card idea)
  • Could keep it on a USB drive
  • Could keep encrypted private key on remote server
• People would have to remember to make backups of their private key
• Would require browser support

Stream fairness by IP address on Internet connections

2006-06-17

Idea:
TCP/IP connections have fairness built-in. This fairness is at the connection level, so no TCP/IP stream will dominate when others are trying to get bandwidth also. Unfortunately, this fact is now heavily abused. Tools such as download accelerators will just establish many connections to download 1 file. Since it has many connections, it will get approximately that many times the bandwidth to the detriment of others. P2P is similarly unfair for this same reason, but it inherently needs many connections to work. For within a building, typically you buy router. Sometimes the ISP even directly gives you a router. To make everything within the intranet fair for accessing the internet, cheap routers should automatically impose fairness by IP address, instead of trusting TCP/IP to do it. This way even if everyone is trying to download heavily, they will still get their fair share and not starve other users. This is much better than the TCP/IP only case where everyone else would starve.

Pros:

• Fair to everybody on the intranet trying to use the Internet connection
• Common abuse like using multiple TCP/IP streams would no longer work
• Decreases the need for extra protocol-based prioritization

Cons:

• Routers would be more complex and expensive
• Latency may still be an issue

Price advertisement legislation

2006-02-20

Idea:
In the United States of America, advertised prices are often intentionally made to be misleading. Unlike other parts of the world, taxes are often listed separately to make the items look cheaper. To combat this, there should be a law requiring the price listed to be the actual amount of money that you have to pay to walk out of the store with the item or service. So, you couldn't have an offer saying 1 $ when it would cost 1.1 $ to actually buy it. Similarly, you couldn't only say 110 $ (* after rebate). You would have to list the real price. For example, for a phone service, they would not be able to have different service fees, dialtone fee, etc., without listing it in their base monthly price in the first place. It would also be useful to list an average cost per unit time of a service.

Pros:

• It would be much easier to make simple economic decisions
• Less incentive for companies to try to mislabel things since they would have to put the real price anyways
• Less need for small denominations of money, such as pennies since with taxes included, they would usually be rounded beforehand

Cons:

• That companies commonly engage in deceptive practices, this might be undesirable to them

Dynamic torrents

2005-08-11

Update (2008-09-02): TStream now exists and seems to match what I described.

Idea:
The BitTorrent protocol can be augmented to handle dynamic torrents by using digital signatures. You would download the file that you wanted which would have the tracker and the public key. You would connect to the tracker and get the latest regular torrent file and would verify its integrity by examining its signature. When you have the torrent, you can selectively download the files from it.

Pros:

• Can be used for any type of dynamic data
• Can be used to serve high-demand static webpages
  • Could use SSL certificate from hostname for signing
• Due to hashes, files will arrive intact
  • (Maybe Apache should have a mod_hash in the first place?)
• Can be used for RSS without so much demand on the server
• Can be used for software to always get the latest version
• Could post static and dynamic versions and seed both
• Could have information about what changed between versions to not waste time downloading parts you already have

Cons:

• Torrent could be tampered with if private key is compromised
• Would require significant changes to BitTorrent trackers
• Many webpage and RSS files are very small and would not make good use of BitTorrent, which is designed for large files

Public key encryption credit/debit card

2004-06-13

Update (2005-06-22): Idea as PDF.

Idea:
Instead of monetary transactions just using a credit card number and a secondary number, a device similar to a pocket calculator should be used. It stores your private key, public key (signed by the bank), and account number. To pay for something, it generates a receipt and you sign it with your private key. To accept the transaction, the recipient also signs it with their private key.

Details:

• Does not ever reveal private key, not even to company that makes it
• Can be used to e-mail money, like a check
• To execute transactions stored on a card, connect to any ATM or your computer
• Prompts you to verify amount on card itself, not externally
• Tracks balance since last sync (with ATM/bank)
• Can connect to other cards for person-to-person transactions

Pros:

• Can send transactions over insecure channels without worrying
• Can have special PIN that gives panic message instead of payment
• Cannot easily have credit card number stolen and abused, because account number is understood to be public to begin with
• Have to authorize every payment (no strange charges appearing)
• Don't need special device to use cards
• Can use public key cryptography to verify your identity
• Typical usage would be identical to credit/debit card
• Makes phishing scams impractical
• Won't have duplicate charges (can resend agreed upon transactions)

Cons:

• Can still have card device stolen and used (but need PIN)
• Number would be long to type in manually, but could be done
• Companies would need new machines for these new cards (replacing infrastructure)
• Cards more expensive to make
• More sophisticated cards means more likely to break
• Quantum computers might be able to break RSA soon

Formal proof archive

2004-02-06

Update (2008-01-16): MetaMath is close to what I was thinking of

Idea:
It would be very useful if there was a central archive of many formal proofs. As new proofs were discovered, they could be added. It would have an interface that served as a formal proof verifier. If it was verified, it would be added to the archive.

Pros:

• People know that their proof is correct
• There is a place to look up theorems
• Would be a great resource for math students
• Could be used with the formal programming language

Cons:

• Would require proofs to be rewritten in a easy to parse language
• Would take a long time to feed it all of the basic proofs
• Some steps that are obvious to a human might be too big for it to handle

Mathematically formal programming language

2004-02-03

Idea:
Have a new programming language based around proving that a program does what it is supposed to. It can generate code and prove that it performs a given operation. It has a library of common routines and related theorems. It can be fed and generate new theorems. The programmer assists and tries to feed it information to help fill in the gaps to make it prove faster or have a more efficient resultant program.

Pros:

• Very high level language: More oriented on what you want to do and less on how to do it
• Security: No buffer overflows or similar exploits
• Software engineering: Proven to meet technical requirements
• Memory management: No problems with malloc and free (new and delete), no garbage collection
• Speed: Can be compiled into standard, platform-independent C
• Puts the emphasis onto science in computer science
• Enforces pre- and postconditions
• Easy to transform code because it knows what aspects of it are important and which are arbitrary

Cons:

• Due to the complexity, very slow to compile
• New headaches, must decide what theorems to feed it to make it compile in a reasonable amount of time
• Very different to program in
• Being more mathematical will make it less attractive to some people

Quantum programming language

2004-02-03

Update (2005-06-22): I found such a language. QCL

Idea:
Quantum computers have been in many newspaper articles and magazines, but few people can understand them or know what they can do. It would be made much clearer if there was a short list of operations (like an assembly language) that any operation that a quantum computer can perform could be expressed in.

Pros:

• More people could understand and try to make algorithms for quantum computers
• Quantum computers could be more popular and useful (once they started making them)

Cons:

• Might not be possible or practical
• Might only represent a subset and people get the wrong idea

Peer-to-peer (P2P) instant messaging (IM)

2004-02-03

Idea:
P2P has been very popular lately. IM is usually built to use a central server. These two could be combined. Even more generally, it could be a general purpose layer above TCP and IP with its own ports to be used by any new P2P application.

Details:

• Built-in concept of identity with public key encryption
• Automatically works, even if using a local address, by connecting to peers out on the internet directly
• To find peers, can have some peers that you are connected to listed as part of your address. Always have public key in address
• Same usernames okay because different public key
• Can use Jabber's XMPP
• Can have option to use extra steps inrouting for more privacy like Freenet

Pros:

• Not dependent on particular companies
• No frequent changes in protocol in attempts to break compatibility
• Don't have to worry about server going down
• Harder to snoop

Cons:

• Can be unnecessarily slow
• Username links can get long
• Cryptography might be slow on older machines