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.
|