[freenet-dev] Blog comments on difficulties uninstalling Freenet

[Artefact2]

Using full disk encryption on a lower level is much simpler, and much more
secure.

On Mon, Dec 7, 2009 at 5:45 PM, Ximin Luo  wrote:

> Matthew Toseland wrote:
> > Thoughts?
>
> You should probably respond on the blog itself so the author can read it.
>
> Regardless though, it would be "nice" to have a "self-destruct" mechanism
> like
> the author describes - ie. the installer should include an uninstaller that
> removes all traces of freenet from the computer, as far as possible.
>
> Obviously this can't feasibly include browser caches and recent history
> etc,
> but it could at least reverse everything the installer does (cron jobs, key
> imports, windows registry changes, temporary files*, etc). The things that
> we
> can't remove, we can tell the user about, and they can take the necessary
> measures.
>
> It shouldn't be harder than writing a reverse-version of the installer,
> plus
> any extra state freenet itself might add to the disk.
>
> Freenet already provides the user with a way to remove all data downloaded
> by
> freenet, and tries to hide its existence on the network; there might as
> well be
> a feature to remove (or hide) its existence on the user's hard disk.
>
> X
>
> *some windows installers create temporary files and don't delete them
> afterwards
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20091207/13ab961a/attachment.html>

[freenet-dev] Blog comments on difficulties uninstalling Freenet

[Evan Daniel]

On Mon, Dec 7, 2009 at 4:53 PM, p01air3 p01air3  wrote:
> About temporary files deletion, here is a suggestion from FMS:
>
>
> Hello,
>
> When the freenet node crashes the datastore must be checked at the next node
> boot. This process creates auxiliary temporary files called
> bloom-A_BIG_NUMBER.tmp in a temporary directory (/tmp on linux).
>
> The problem is, if the node crashes quite often (for example once or twice a
> week, depending on the computer load), and the datastore is consequent 
> (several
> tens of gigabytes), the bloom tmp files begin to be very large (several tens 
> of
> megabytes once the maintenance is finished). Those files accumulates in the 
> /tmp
> directory and this can be very bad, for example when /tmp is mounted on a
> dedicated 500MB partition.
>
> AFAIK those files are not used any more once the maintenance has finished. Due
> to their very nature (temporary files in temporary directory), couldn't the 
> node
> delete them after use ? The node would thus maintain a much cleaner 
> environment.
>
>
> The problem is the same with libfec*.tmp, libNativeThread*.tmp and jcpuid*.tmp
> though those files are much smaller.

Personally, I would start by asking why the node was crashing in the
first place, not why it doesn't clean up when it does!  Have you
checked for error messages in the logs?

Evan Daniel

[freenet-dev] Blog comments on difficulties uninstalling Freenet

[Ximin Luo]

Matthew Toseland wrote:
> Thoughts?

You should probably respond on the blog itself so the author can read it.

Regardless though, it would be "nice" to have a "self-destruct" mechanism like
the author describes - ie. the installer should include an uninstaller that
removes all traces of freenet from the computer, as far as possible.

Obviously this can't feasibly include browser caches and recent history etc,
but it could at least reverse everything the installer does (cron jobs, key
imports, windows registry changes, temporary files*, etc). The things that we
can't remove, we can tell the user about, and they can take the necessary 
measures.

It shouldn't be harder than writing a reverse-version of the installer, plus
any extra state freenet itself might add to the disk.

Freenet already provides the user with a way to remove all data downloaded by
freenet, and tries to hide its existence on the network; there might as well be
a feature to remove (or hide) its existence on the user's hard disk.

X

*some windows installers create temporary files and don't delete them afterwards

Re: [freenet-dev] Blog comments on difficulties uninstalling Freenet

[Evan Daniel]

On Mon, Dec 7, 2009 at 4:53 PM, p01air3 p01air3  wrote:
> About temporary files deletion, here is a suggestion from FMS:
>
>
> Hello,
>
> When the freenet node crashes the datastore must be checked at the next node
> boot. This process creates auxiliary temporary files called
> bloom-A_BIG_NUMBER.tmp in a temporary directory (/tmp on linux).
>
> The problem is, if the node crashes quite often (for example once or twice a
> week, depending on the computer load), and the datastore is consequent 
> (several
> tens of gigabytes), the bloom tmp files begin to be very large (several tens 
> of
> megabytes once the maintenance is finished). Those files accumulates in the 
> /tmp
> directory and this can be very bad, for example when /tmp is mounted on a
> dedicated 500MB partition.
>
> AFAIK those files are not used any more once the maintenance has finished. Due
> to their very nature (temporary files in temporary directory), couldn't the 
> node
> delete them after use ? The node would thus maintain a much cleaner 
> environment.
>
>
> The problem is the same with libfec*.tmp, libNativeThread*.tmp and jcpuid*.tmp
> though those files are much smaller.

Personally, I would start by asking why the node was crashing in the
first place, not why it doesn't clean up when it does!  Have you
checked for error messages in the logs?

Evan Daniel
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Blog comments on difficulties uninstalling Freenet

[p01air3 p01air3]

About temporary files deletion, here is a suggestion from FMS:


Hello,

When the freenet node crashes the datastore must be checked at the next node
boot. This process creates auxiliary temporary files called
bloom-A_BIG_NUMBER.tmp in a temporary directory (/tmp on linux).

The problem is, if the node crashes quite often (for example once or twice a
week, depending on the computer load), and the datastore is consequent (several
tens of gigabytes), the bloom tmp files begin to be very large (several tens of
megabytes once the maintenance is finished). Those files accumulates in the /tmp
directory and this can be very bad, for example when /tmp is mounted on a
dedicated 500MB partition.

AFAIK those files are not used any more once the maintenance has finished. Due
to their very nature (temporary files in temporary directory), couldn't the node
delete them after use ? The node would thus maintain a much cleaner environment.


The problem is the same with libfec*.tmp, libNativeThread*.tmp and jcpuid*.tmp
though those files are much smaller.

Thanks in advance 
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Blog comments on difficulties uninstalling Freenet

[Matthew Toseland]

On Sun, Dec 06, 2009 at 04:58:21PM -0600, Ian Clarke wrote:
> This guy raises concerns about uninstalling Freenet:
> 
> http://truefalsebollox.blogspot.com/2009/11/freenet-users-watch-your-back.html

"First of all, there is talk in the scant guide offered with Freenet of ?a 
panic button? ? I imagined something to hit if the heavy jackboots start 
thudding up the stairs. What would the panic button do? Immediately wipe all 
Freenet-associated files from my hard disk? Hmm, I don?t know, because I 
couldn?t find the panic button in the copy I downloaded and ran. Even if there 
was one somewhere, the fact that it isn?t under my nose means it wouldn?t be 
much use in a hurry."

The "panic button":
- Shows up on the downloads/uploads page.
- Doesn't show up in LOW physical security level. You already said you have 
nothing to hide, right? Maybe we should change this.
- Wipes everything that might relate to incriminating data: the client cache, 
downloads in progress etc (but not files already downloaded to disk, only files 
downloaded to temporary space).

IT EXPLICITLY DOES NOT DELETE FREENET ITSELF. Writing a portable 
without-a-trace uninstaller is a seriously nontrivial project which we are not 
competent to embark on, and it is outside our mandate.

"The uninstaller provided with each download merely removed the program files 
from my Applications list into my Trash list. It did not remove them from the 
computer."

This is some OS/X bull. mrsteveman1 can you fix this?

"Further, even though I was running my browser in ?Privacy mode?, links to 
Freenet ?keys? were stored in my browser Cache history."

Then your browser is defective! Privacy mode by definition should not 
persistently store any trace of your browsing after you close it. If it does IT 
IS NOT A MEANINGFUL PRIVACY MODE. If anyone is aware of browsers which behave 
in this way, providing a dangerously false sense of security, please let us 
know and we can warn users against them.

"This is particularly worrying if you don?t bother to check, since the advice 
from Freenet is to use a separate and dedicated browser ? meaning everything in 
your cache will be freenet related. No need for anyone examining your computer 
to sort through thousands of innocuous logs to find the Freenet ones."

Any browser that stores cache or history on disk in plaintext for "privacy 
mode" is broken by design and SHOULD NOT BE USED. The advice we give is based 
on the simple fact that if you use the same browser, with the exception of a 
meaningfu,l non-history-preserving privacy mode, for browsing the internet as 
for browsing freenet, the internet sites you visit can probe your freenet 
browsing history.

"Still, none of that is of as much concern as this: manually deleting Freenet 
from my computer was not as simple as emptying the cache and Trash files. The 
cache went into the trash, so to speak, but the Trash folder with Freenet files 
in it could not be emptied from the desktop no matter what I did. Some files 
had been automatically locked by Freenet, and the whole Trash application froze 
trying to unsuccessfully delete them. In short, I had to do a ?sudo? from the 
command line to forcibly remove them, a process that if you don?t know how to 
do you?d better learn if you plan on using Freenet in a hostile environment. 
I?d also say you?d better learn how to do it quick (maybe write yourself a 
script), because wiping all trace of Freenet off my computer took me the best 
part of an hour the first time I tried it."

This is more Mac bullshit. We should work around it.

HOWEVER, there is a deeper fundamental fact here: No portable application is 
going to wipe every trace of its presence when you uninstall it. It's just not 
practical in terms of the amount of deeply platform specific work involved. 
There are third party tools that may provide such functionality.

Or is it? Most unixes have "shred" now??

All this is a matter of poor documentation. However, better documentation would 
involve more reading for the user and therefore put users off running Freenet 
at all. Thus it is a largely unsolvable problem, apart from the OS/X 
perversities which hopefully mrsteveman1 will have time to resolve.

So we cannot expect to tell the user the full range of things they need to know 
to keep their privacy in the installer. The solution is to bundle a README file 
that nobody will read, and then when somebody gets killed because of our 
negligence we can say it was because they didn't read the README. Oh and we can 
make it prominent by e.g. making it available from the web interface.

Thoughts?
-- 
The theory that the earth is round has been repeatedly debunked. Therefore it 
must be false.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20091207/60094d54/attachment.pgp>

Re: [freenet-dev] Blog comments on difficulties uninstalling Freenet

[Artefact2]

Using full disk encryption on a lower level is much simpler, and much more
secure.

On Mon, Dec 7, 2009 at 5:45 PM, Ximin Luo  wrote:

> Matthew Toseland wrote:
> > Thoughts?
>
> You should probably respond on the blog itself so the author can read it.
>
> Regardless though, it would be "nice" to have a "self-destruct" mechanism
> like
> the author describes - ie. the installer should include an uninstaller that
> removes all traces of freenet from the computer, as far as possible.
>
> Obviously this can't feasibly include browser caches and recent history
> etc,
> but it could at least reverse everything the installer does (cron jobs, key
> imports, windows registry changes, temporary files*, etc). The things that
> we
> can't remove, we can tell the user about, and they can take the necessary
> measures.
>
> It shouldn't be harder than writing a reverse-version of the installer,
> plus
> any extra state freenet itself might add to the disk.
>
> Freenet already provides the user with a way to remove all data downloaded
> by
> freenet, and tries to hide its existence on the network; there might as
> well be
> a feature to remove (or hide) its existence on the user's hard disk.
>
> X
>
> *some windows installers create temporary files and don't delete them
> afterwards
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Blog comments on difficulties uninstalling Freenet

[Ximin Luo]

Matthew Toseland wrote:
> Thoughts?

You should probably respond on the blog itself so the author can read it.

Regardless though, it would be "nice" to have a "self-destruct" mechanism like
the author describes - ie. the installer should include an uninstaller that
removes all traces of freenet from the computer, as far as possible.

Obviously this can't feasibly include browser caches and recent history etc,
but it could at least reverse everything the installer does (cron jobs, key
imports, windows registry changes, temporary files*, etc). The things that we
can't remove, we can tell the user about, and they can take the necessary 
measures.

It shouldn't be harder than writing a reverse-version of the installer, plus
any extra state freenet itself might add to the disk.

Freenet already provides the user with a way to remove all data downloaded by
freenet, and tries to hide its existence on the network; there might as well be
a feature to remove (or hide) its existence on the user's hard disk.

X

*some windows installers create temporary files and don't delete them afterwards

___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Blog comments on difficulties uninstalling Freenet

[Matthew Toseland]

On Sun, Dec 06, 2009 at 04:58:21PM -0600, Ian Clarke wrote:
> This guy raises concerns about uninstalling Freenet:
> 
> http://truefalsebollox.blogspot.com/2009/11/freenet-users-watch-your-back.html

"First of all, there is talk in the scant guide offered with Freenet of ‘a 
panic button’ – I imagined something to hit if the heavy jackboots start 
thudding up the stairs. What would the panic button do? Immediately wipe all 
Freenet-associated files from my hard disk? Hmm, I don’t know, because I 
couldn’t find the panic button in the copy I downloaded and ran. Even if there 
was one somewhere, the fact that it isn’t under my nose means it wouldn’t be 
much use in a hurry."

The "panic button":
- Shows up on the downloads/uploads page.
- Doesn't show up in LOW physical security level. You already said you have 
nothing to hide, right? Maybe we should change this.
- Wipes everything that might relate to incriminating data: the client cache, 
downloads in progress etc (but not files already downloaded to disk, only files 
downloaded to temporary space).

IT EXPLICITLY DOES NOT DELETE FREENET ITSELF. Writing a portable 
without-a-trace uninstaller is a seriously nontrivial project which we are not 
competent to embark on, and it is outside our mandate.

"The uninstaller provided with each download merely removed the program files 
from my Applications list into my Trash list. It did not remove them from the 
computer."

This is some OS/X bull. mrsteveman1 can you fix this?

"Further, even though I was running my browser in ‘Privacy mode’, links to 
Freenet ‘keys’ were stored in my browser Cache history."

Then your browser is defective! Privacy mode by definition should not 
persistently store any trace of your browsing after you close it. If it does IT 
IS NOT A MEANINGFUL PRIVACY MODE. If anyone is aware of browsers which behave 
in this way, providing a dangerously false sense of security, please let us 
know and we can warn users against them.

"This is particularly worrying if you don’t bother to check, since the advice 
from Freenet is to use a separate and dedicated browser – meaning everything in 
your cache will be freenet related. No need for anyone examining your computer 
to sort through thousands of innocuous logs to find the Freenet ones."

Any browser that stores cache or history on disk in plaintext for "privacy 
mode" is broken by design and SHOULD NOT BE USED. The advice we give is based 
on the simple fact that if you use the same browser, with the exception of a 
meaningfu,l non-history-preserving privacy mode, for browsing the internet as 
for browsing freenet, the internet sites you visit can probe your freenet 
browsing history.

"Still, none of that is of as much concern as this: manually deleting Freenet 
from my computer was not as simple as emptying the cache and Trash files. The 
cache went into the trash, so to speak, but the Trash folder with Freenet files 
in it could not be emptied from the desktop no matter what I did. Some files 
had been automatically locked by Freenet, and the whole Trash application froze 
trying to unsuccessfully delete them. In short, I had to do a ‘sudo’ from the 
command line to forcibly remove them, a process that if you don’t know how to 
do you’d better learn if you plan on using Freenet in a hostile environment. 
I’d also say you’d better learn how to do it quick (maybe write yourself a 
script), because wiping all trace of Freenet off my computer took me the best 
part of an hour the first time I tried it."

This is more Mac bullshit. We should work around it.

HOWEVER, there is a deeper fundamental fact here: No portable application is 
going to wipe every trace of its presence when you uninstall it. It's just not 
practical in terms of the amount of deeply platform specific work involved. 
There are third party tools that may provide such functionality.

Or is it? Most unixes have "shred" now??

All this is a matter of poor documentation. However, better documentation would 
involve more reading for the user and therefore put users off running Freenet 
at all. Thus it is a largely unsolvable problem, apart from the OS/X 
perversities which hopefully mrsteveman1 will have time to resolve.

So we cannot expect to tell the user the full range of things they need to know 
to keep their privacy in the installer. The solution is to bundle a README file 
that nobody will read, and then when somebody gets killed because of our 
negligence we can say it was because they didn't read the README. Oh and we can 
make it prominent by e.g. making it available from the web interface.

Thoughts?
-- 
The theory that the earth is round has been repeatedly debunked. Therefore it 
must be false.


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Blog comments on difficulties uninstalling Freenet

[Christian Funder Sommerlund (Zero3)]

(This is about the Linux installer)

- Zero3

Ian Clarke skrev:
> This guy raises concerns about uninstalling Freenet:
> 
>   
> http://truefalsebollox.blogspot.com/2009/11/freenet-users-watch-your-back.html
> 
> Ian.
> 
> -- 
> Ian Clarke
> CEO, Uprizer Labs
> Email: ian at uprizer.com 
> Ph: +1 512 422 3588
> 
> 
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl