Andreas Raab wrote:
> Cees De Groot wrote:
> 
>> On 11/5/05, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>>> The way I look at it it's a fact that we use images to
>>> share.
>>
>>
>> Sometimes. Often not. I share the vast majority of my images with only
>> myself. But I'm a programmer, so I share code through MC more than
>> objects.
> 
> 
> This is partly why I considered this post to be a troll to begin with - 
> it is obviously inviting one of these "files are evil - no they are not 
> - yes they are" discussions and you are jumping right on a similarly 
> irrelevant discussion. Or do you really mean to say that it's okay if we 
> "sometimes" hand out our passwords to the rest of the world?! ;-)
> 
> Like it or not, we *do* use images to share, whether that is 
> "sometimes", "once in a while" or "rarely" doesn't matter. And if (as I 
> think) we all agree that sensitive personal information should never be 
> shared without explicit consent, then the only response is that, no, 
> images are *not* reasonable places to store these passwords. Which 
> effectively says everything there is to say about the issue but I will 
> go through the motions nevertheless.
> 
>>> The "Scrub&Save" entry is completely missing the point unless you
>>> *always* Scrub&Save - the issue I was having happened because somebody
>>> asked me for an image, and I shared it without starting, checking, and
>>> realizing that this image did indeed contain sensitive passwords.
>>
>>
>> Yup - because it is hidden, MC might be an exception (or not - I don't
>> use Celeste, or eIRC, or ....). However, I'm quite sure that if the
>> World Menu had a 'Scrub&Save' right below or above the 'Save' , it'd
>> quickly become second nature.
> 
> 
> And I'm quite sure that it wouldn't matter. Because, in the case in 
> question, if I *would* have thought about the fact that this was indeed 
> an active development image I would indeed have checked it. But I 
> didn't. So, unless I always use "Scrub&Save" this would have been the 
> exact same situation - simply because when you look at that image file 
> you don't see a big red marker saying "this image contains passwords".
> 
> That's why "Scrub&Save" doesn't help - it is great if you think of it 
> (but if you think of it you don't need it), it is great if you always 
> use it because then you don't have to think of it (but if you always use 
> it you may as well not store the sensitive data in the image to begin 
> with) but unless either of the two is true, Scrub&Save is essentially 
> pointless[*].
> 
> [*] BTW, I'm not denying that Scrub&Save could be helpful for having a 
> central entry point to cleanse sensitive information but it still 
> requires one to remember that some random image contains sensitive 
> information which is why I consider it pointless. If there is no 
> sensitive data in the image, then there is nothing to remember about 
> sensitive data. What we as developers ought to do is to provide a 
> framework to store such sensitive information so that (portions of) it 
> can be shared given the explicit consent. But the image is simply not 
> the place to store such sensitive data.
> 
>> Note that I'm not saying that this is necessarily the best solution; I
>> can envision a sort of Squeak Keyring in an external file - such a
>> thing would be easy to make and secure enough for most purposes. I
>> would very much object against having to remember to pick up a
>> gazillion files when I move an image - if that'd be the end result of
>> packages stashing all sorts of stuff in external files, I rather stick
>> with everything in the image and a good scrub now and then.
> 
> 
> But this statement is absurd. I have been talking specifically about 
> passwords not "gazillion files" and there is no reason to assume that 
> storing (cached) passwords externally would lead to having to remember 
> *anything* when you move an image. To the contrary - now you do NOT have 
> to remember to cleanse sensitive information since it is not stored in 
> the image when you move it.
> 
>> So basically what I'm saying is that this is a valid problem, there
>> are alternative solutions, and especially that calling someone who
>> represents a solution that may be not the solution you'd like to see a
>> troll is hardly productive. That's indeed the sort of stuff that
>> spawns pointless discussions :)
> 
> 
> Well, okay, maybe it wasn't a troll. But the proposal sure doesn't 
> qualify as a "solution" for the problem I was describing. Simply because 
> having that option would *not* have prevented sharing the passwords (I 
> would have had to be aware of the fact that that image contains 
> passwords, and if I would have been aware I most definitely would have 
> done a quick check for any MC passwords). The three actual solutions I 
> can see are:
> 1) completely avoid sharing images, or
> 2) make people aware of the fact that a random image file contains 
> sensitive information, or
> 3) just don't store sensitive personal information in the image but 
> someplace else
> Out of these three 1) seems not feasable, 2) seems very hard, and 3) 
> seems like the obvious trivial solution to the problem. "Scrub&Save" 
> does not contribute any alternative solution that would have prevented 
> the problem under discussion.
> 

Andreas,

Originally I wasn't in the mood to discuss this further, but now that 
you put in a bit more work after your one-liner here is some more 
explanation from me.

My point was that in a random image there is other sensitive personal 
information than just passwords. If I take an arbitrary image of mine, I 
generally don't know what exactly is in it and what is not. But I know 
that it probably is mostly my private data and not MC passwords. Thus I 
am considering 2) not very hard but much easier and 3) generally very hard.

A "scrub&save" facility has its use and is overall not necessarily more 
unsecure than an external password file. Both have its weaknesses, just 
in different areas. E.g. the external password file may lure a user into 
the false believe that she is save to hand out an image, and it presents 
unencrypted passwords on a silver plate.

The optional encryption of the whole image or a project on the VM-level 
would be another interesting alternative for the broader problem (as I 
see it).

Martin