Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] RMS is at it again...again



On 2008-10-03 12:08 +0900 (Fri), Keith Bawden wrote:

> The company hosting your service/data in a more traditional and static
> way will have at least some measure of access to it?

Certainly. But I can see two key differences here:

1. You have considerably more control of the data and software using it
if you're using a co-located server. For example, you can encrypt some
or all of it, you can easily copy it elsewhere and use it on another
system, and so on. You can also chose your encryption policy for data
transfer, which at least can give you protection against attackers
between you and the hosting provider, if not the hosting provider
itself. (For example, you could chose to force the use of TLS for
certain types of mail on a mail server, thus defeating systems such as
Carnivore.)

2. Certainly from a social point of view, and probably from a legal one
as well, there's quite a difference between someone hosting a specific
type of data in a particular format (e.g, e-mail) and merely providing
storage for any kind of data. It would seem to me reasonable in the
first case to subpeona the holder of the data to search it and turn over
specific messages, or covertly ask the provider to scan and forward
data. With the latter, it's more difficult; I expect a subpeona of the
form "turn over all data on that hard drive, regardless of relevance"
would not go very far, and "covertly send me a copy of every write to
that disk" would be rather more difficult to process, and perhaps even
ask, than "turn over mail messages to or from a particular person" or
"provide me an unecrypted message stream that I can monitor."

> Colocation (or hosting in your own server room/closet) is fine if you
> have money and a locked rack or cage, support it yourself and no
> network connection, but isn't anything else going to lead to someone
> screaming that we are "more than stupid" for putting our data in the
> hands of others to <insert nefarious evil plan here>?

Indeed. There will always be people who see things in terms of black and
white, and insist that something just short of perfect is equivalant to
the worst possible thing. But of course that's generally not the case,
and is certianly not in the security world.

> Should I panic now or some time tomorrow?

You need to panic at different times for different types of data and
threats to it. If you're not sure, I'd just start panicing in a gentle
way now, and continue indefinitely. :-)

> Am I an idiot[1] if I ask or employ others to write software for me?
> After all who knows what "they" will do with any of my data that they
> or their code touches...

We have systems for dealing with this when the risk is high enough.
For example, in some financial applications it's not uncommon to
independently audit all code before putting it into production,
carefully firewall the production systems in an inward-facing way to
prevent data from escaping, and never to let the development team have
any access to production data.

We don't do this all the time because it costs money, but it is done.

> If I had the ability to read through and understand every nuance of
> the code I would write it myself.

I would strongly disagree with this; the ability to understand something
generally does not imply the ability to create it. You can no doubt
understand Shakespeare quite well; could you write forty plays, or even
one play, as good?

> Or do I have to trust another third party or community of unknowns[2]
> to review it for me, and can I trust the result of that et cetera?

Well, you can certainly place more trust in a result if two independent,
non-cooperating parties agree on it.

This is really all about risk management. Most people aren't very good
at that, unfortunately.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links