Various thoughts

Old thoughts on various subjects


Search engine personal profile

Hidden partitions

Search engine personal profile

A suggestion I made to various search engines. (Not the only one, but an important idea which has high chances to be implemented.)

As you know, today's Internet searches return overwhelming amounts of garbage.

To solve this problem, allow users to create personal accounts on your search engine. This would let each user to create its own list of links where your search engine would search the given keywords.

Users can collect links from everywhere (including from places dedicated to gather manually-checked sites) and add them to their search engine personal profile, and later search through these links (instead of the entire Internet). This can add up tens or even hundreds of thousands of links (a lot of data to transfer for every search from the user's computer, so you can't put this list in cookies, and thus you need personal accounts).

Also, you could use these lists of links to see which websites users think are good enough to search (and you can improve their ranks). Monitor if these links are actually used for search, and don't just sit there; the more they are used, the higher ranking you give them. Basically, people do the sorting for you, for free.

Of course, some people might want to profit from this by creating accounts with garbage links which are only intended to improve the ranks of various websites.

One way to combat this would be to charge users to open a personal account, like 5 USD / account, but you have to charge only to open the account (not for searches).

Hidden partitions

A suggestion I made to various developers of applications which can manage a partition in an encrypted file.

Hidden containers, as they are implemented now, is a useless feature from my point of view because data can't be written in the outer container (without worry of destroying the hidden container). In order for this feature to be useful, I personally need to be able to store all my work in an encrypted container (and so make changes to it all the time), and also, perhaps, have a hidden container for truly private data.

Previously, I told you about splitting a container in two parts, one of which would be the "hidden" one, but you rejected that idea. (I don't even know if Windows is able to handle two partitions in the same file.)

Since I don't want to do significant changes to your program and use my own version, I have a suggestion which you may want to implement as a choice when the program's API will be released.

I would like to be able to create my own GUI for the program's driver. From there, I want to create the hidden container as another encrypted file in the outer encrypted file. Basically, when the user would create a new encrypted container A, my application would tell to your program to also create another encrypted file B inside A, of a specified size (which would be, for example, 30% from the size of A).

So, the "hidden" container B would actually be a simple file inside container A. Since B would always be created, there is plausible deniability for users because they have no choice to not create B.

Of course, a password for container B would be asked when container A is created. If none is provided, a random password would be used and the file for hidden data is basically a dummy file; the random password is necessary for plausible deniability. If later the user wants to use container B, he would have to go through a process which resets the password for container B, because he can't just change the password (since this is random).

Dummy files ( or any other data containers) are a form of steganography: they might contain precious data, or they might not. Nobody can tell even though everyone sees them.

There is one issue. The file for container B could be deleted by the user. For this, there is a solution which has to be implemented in your encryption driver. Every time when container A is mounted, check if the file for container B exists (and has the right size) and if it doesn't then recreate it (if there is enough space).

If there is not enough space, then there is no problem since at this point is not essential to recreate B. Actually, this is an advantage since users can simply delete the file for container B in order to use the entire space of container A. Plausible deniability is still maintained because if there is enough space, the file for container B would be recreated anyway.

As a safety measure, never allow the deletion of the file for container B from a file manager, but only from your program.

The advantages of this method are:

  • Both containers would have all the advantages of NTFS formatted partitions.

  • The user could write data in both containers without worry.

  • Both containers could be used at the same time, that is, both partitions could be mounted simultaneously.

  • There could be 3 or 4 such dummy files to mitigate rubber-hose attacks.

  • Is compatible with any other operating system.

The disadvantages of this method are:

  • Your developing effort, but this would be small.

  • A slightly lower access speed for container B, since there would be a double encryption.

And, who knows, maybe you'll think this method is good enough for you to implement it directly in your program.

License | Contact