[tor-talk] Tor as a sort of "library/dependancy" for third party software

[Fabio Pietrosanti (naif)]

On 10/3/11 6:13 PM, Nick Mathewson wrote:
> Hm.  PE resources don't look like they're designed to support
> read-write access in a generic way after the file is created; they
> seem more like a way to more read-only things as part of an .exe file.
>  I guess you could try to create a resource that was just empty space,
> and pretend that it was a quick-and-dirty filesystem, but honestly I'm
> not sure it would be worth it.

An interesting discussion on that topic it's available on:
http://stackoverflow.com/questions/4577564/modifying-resource-contents-of-a-running-executable

However let's rationale which could be the real usage for a Single
Executable.

Imho the matter it's related the usability, the single executable give
you the feeling:
- download
- execute

without having to "install" it .

Let's see the steps required to start using tor browser bundle:
https://www.torproject.org/projects/torbrowser.html.en

The user action of "installing" it's related to the fact that the user
need to make a choice of something related to a "system setup".

In TorBrowser bundle this require the user to:
- dealing with the concept of "extraction"
  Really dumb users doesn't know what file compression is, some doesn't
even know what file size.
- dealing with a decision of "where to extract".
  That relate to interacting with the system and a really dumb users
fear doing actions for which he don't know the consequence.

There are a lot of users that "are not even able to install firefox"
with his own easy to be used wizard, and that kind of users today are
not able to use Tor Browser Bundle.
And yes, that kind of users exists, i meet many of them!

Those two small usability issue could be fixed by a single executable.
Those are reasons elaborated for which i really wanted to target making
a Single Executable.

Considering that a Single Executable it's a difficult stuff, we could
maybe reach the same usability improvements goal with another approach.

The same result could also be achieved without having a "Single
executable" by following a workflow like this to TorBrowserBundle.exe:
- User click on TorBrowserBundle.exe
- A nice splashscreen popup to the user
- A progress bar inform the user that Tor it's initialing
  - Extracting to TorBrowserBundle Directory ...OK
  - Starting Tor...OK
  - Initialing Tor Connection... OK
  - Starting Firefox... OK
Then the browser show up to the user.
The browser show at first page :
- useful information about Tor
- useful information about this tor installation (informing the user
about the newly created Directory)
- include the CheckTor page to verify he is really using Tor

By using that approach the user will not have the feeling of
"installing" something and also "really dumb users" will be able to use
Tor Browser Bundle because no "technical" decision has to be taken by
the user in order to use it, no fear of breaking something, no
compression/extraction concept to be understood.

Technically, the downloaded file TorBrowserBundle.exe would transform
itself in a nice iconized link to the
TorBrowserBundle/TorBrowserBundle.exe allowing the user to later click
on it.
The user click on "what he downloaded" before, without looking around in
other places from where to start the software (that's something typical
when installing software).

That way the user actions required to use Tor Browser Bundle would
reduce to:
- Click on download link
- Accept download
- Start the software

What do you think?


> 
>> Another possible approach could be to:
>> - Start the program
>> - Create an encrypted directory using a random key (with windows
>> encryption system and/or apple filevalue)
>> - Uncompressing everything into that directory
>> - Starting the "programs"
>> - When the program close deleting the files and the encrypted directory
>>
>> This could eventually be another ugly hack to provide the end-user the
>> same experience of a "single, self contained .exe file" ?
> 
> Keep in mind that the cache files are *cache* files and the state
> files are state files: Tor isn't writing stuff to disk just for
> amusement value.  If you don't cache the stuff you're supposed to
> cache, you're going to wind up getting slower startups in the future.
> If you don't keep state, then you won't get long-term protection from
> guard nodes.  If you don't save keys, you won't be able to be a bridge
> or a relay.
That's a valid reason not to do it.
Another one would be the need to uncompress every time 50MB to the user
disk that, if running a slow computer, could take some time, doubling
the disk space requirements for running Tor (100MB instead of 50MB).