User Data Security

[Matt]

I'm pretty relaxed on the issue of security but the security policy
seems weak to me.

I was able to documents stored locally just using Wordpad. I work in a
small charity with 4 workers and 3 computers. The advantage of google
is that I can access stuff at home and I guess other staff do the
same. This could lead to copies of our data ending up all over the
place.

Couldn't the data file be encrypted?

Matt



Policy
http://code.google.com/apis/gears/security.html#enduserdata

location
C:\Documents and Settings\%USERNAME%\Local Settings\Application Data
\Mozilla\Firefox\Profiles\{PROFILE}.default\Google Gears for Firefox

[Peter Kasting]

On Sat, May 24, 2008 at 12:51 AM, Matt <gro...@googlemail.com> wrote:

Couldn't the data file be encrypted?

What good would that do?  The browser still has to decrypt and process it on the client side, at which point the data is vulnerable to attack anyway.

Data that is meant to be used on the client side is pretty much inherently visible to the client.  Trying to fight that will just add a lot of complexity with no "security" win.

PK 

[Shaun ONeil]

> Policy
> http://code.google.com/apis/gears/security.html#enduserdata
>
> location
> C:\Documents and Settings\%USERNAME%\Local Settings\Application Data
> \Mozilla\Firefox\Profiles\{PROFILE}.default\Google Gears for Firefox

Hi Matt,

If "I" (as another local user on a machine you're using) can read
this location, "I" can also read your documents, cookies, browser
history, etc.

Every modern, mainstream OS from Windows 2000 onwards has some
semblance of filesystem security; this is a much more sensible place
to start if you don't want others reading your files. Not allowing
"ANYONE" (I believe that's what windows calls the group) to read your
firefox profile would solve your problem, in a non-hacky, non-messy
way.

Regards,

Shaun

[Matt]

I think what's being created here is a totally new data structure. The
data resides not exclusively server side or just on a client, its
going to end up all over the place. This is good - the data will be at
our fingrertips but has security implications. You can find data using
a simple search.

The danger is that if I log on to Google docs on a different computer
my files will be copied onto that machine in a format that is openly
readable. The whole advantage of GDocs is that the data is accessible
anywhere. In another companies office, at a friends house...

At the moment data is protected behind the google login. However with
Gears a copy will be left on the hard drive after I logout of google.
In an age when we have https, SSL and on the fly encryption like
truecrypt this seems needlessly insecure to me. The google login has
lost its integrity.

What do you think?

Matt

[Ben Lisbakken]

It is highly discouraged for you to use Gears on an application that has sensitive private data on a public computer where you share login information with many people.  If you went to a public library, you wouldn't want to download a .PDF with your SS# or bank information and leave it there.  Likewise, you wouldn't want to use Gears to cache that same document from Google Docs.

Each new computer you access Google Docs from you must explicitly enable Gears on, so I don't think it is quite correct to say the Google login has lost its integrity.  To go back to the library example, it wouldn't be fair to download that .PDF from your mail client and then claim that your mail client's login has lost integrity -- rather, you have chosen to store private data in a public place.  Also note that just because you cache data on the computer doesn't mean that it gives anyone access to your Google login.

I think in your situation, you might think about storing your Firefox profile on a USB key.  Then you can take your cached information around with you and not share it with other users on the same OS login.

-Ben

[Matt]

The share login is a red herring. If google gears is installed on a
computer then all I have to do is boot the computer from a live distro
on a CD and I've got all the data used by anyone who has accessed
their google from that machine. All their document and spreadsheets.
Easy.

If someone can hack the computer from the web, which I'm told is
possible, then I can just copy the files is a jiffy.

So if I don't use gears then the google password is needed to access
my files. Or someone has to break into the google data bank held on an
undisclosed pacific island patrolled by sharks, with a firewall built
of cray supercomputers and data encrypted with layers military grade
cypher technology.

If we do use gears then the data ends up lying around on the hard
drive in a format you can read from wordpad. I can't even encrypt it
if I want to.

For me this is an issue with the security model.

Matt

[Aaron Boodman]

On Tue, May 27, 2008 at 4:03 PM, Matt <gro...@googlemail.com> wrote:
> If someone can hack the computer from the web, which I'm told is
> possible, then I can just copy the files is a jiffy.

If someone can do this, you lose, no matter what. If somebody can get
local access to a machine, they can install key loggers and get all
your passwords. They can record all the data going in and out. If the
machine you're sitting as is insecure, it's game over. Whether you use
Gears or not.

I'm not saying there's nothing we can do here. I think there may be
some interesting options. But anything we do is going to have pretty
rough usability tradeoffs, and its not a simple "just encrypt the
database file!" type of thing.

- a

[Matt]

Fair play to you guys the google desktop is a great leap forward to
enhanced collaborative working. Now we can share documents and work on
documents at the same time in 'gooland' and even do this off line.
Incredible.

I am interested in how people (and my colleagues) will use this and
this is as much a psychological issue as anything else. For example I
still have people regularly ask me where their files are. When I ask
them where they save it they say that they saved it in 'Word'. A high
percentage of people don't get file structures and another large group
of people see security as a bit of a pain. And lets face it security
is a bit annoying. Logging in every time you use the computer can take
30-60 seconds with another wait before you get on-line. Nowadays the
computer is the bookshelf and we use it to get a phone number or check
a bus timetable or print a form so are in and out of it all the time.

I think a lot of people won't get or wont care that their data is now
copied onto their machine. The advice I've got off this group has made
me think about how we work. But many people will just click to install
gears on their mate's machine or not see an issue with using it side
by side with someone else.

The level of security has to be appropriate to the problem and the
problem here is that the data is in an openly readable format. You
don't have to install a key stroke logger you just have to use
wordpad. Even the use of a live linux CD is a common skill for people
who have windows die on them and had to retrieve data. I'm not worried
about hackers, you can't really stop them, I'm more worried about the
clever dick in the office who is a bit too curious, or their mate who
thinks its funny.

Its true that there might be a performance pay off but there might be
advantages too. The data could be compressed, almost a form of
encryption in itself, which would reduce its footprint and speed up
data transfers.

But I do recognise that this is easy for me to say I don't have to
write the code.

Cheers - Matt

[Brad Garcia]

There's only so much you can do to protect people from themselves.  If you are using a shared login on a computer, then your mates can also view your browsing history and browser cache in addition to any gears stuff.  All of this information is in plaintext and viewable with notepad.  You can even view a user's saved passwords with just slightly more difficulty.  As you say, "the level of security has to be appropriate to the problem".  Given that this is the environment in which gears works, it really wouldn't make things any more secure to have gears encrypt the information that it stores.

The simplest way to secure this environment is to give every user a separate login.  You still must trust the administrator of that system, but nobody else will be able to read your files.  As Shaun stated earlier, filesystem security is the appropriate level at which to solve this problem.

You could go one step further as suggested by Ben and use one of the Firefox-on-a-stick products, where all of this data is stored on a USB memory stick that you can physically remove and take with you, again depriving others (including the system administrator) from the opportunity to see your files after you're done.

-- Brad

[sobolanul]

Let me see if I got this correctly:

You want that "data" means any document that GoogleGears cache to be
be available offline, to be kept encrypted on the hard drive? If yes,
you must admit that you want to see this data on your browser in a
readable format without internet connection. If the answer is yes,
then how you see this "decryption" to be done?
Only way that I see for that is to have the capability of decryption
in Gears plugin. This will lead to same issue. All that a user have t
do is to look at encrypted data stored locally with browser not with
wordpad. As long as the decryption is made on client is no way to stop
viewing those files if have access to the client.

[Matt]

In the course of this discussion my left hand mouse pad button has
died - that's really annoying. Somehow using a laptop with a mouse
isn't the same.

Sobo - Sure, you'd just have to enter the password in the browser. No
password no data.
Obviously, you don't save passwords and switch it off so no one else
uses it. I've always thought the password saver was an oxymoron.

For me my data is slowly moving onto googles server. I used to have
all my emails on my PC, my calendar on my palm, my data on the hard
drive. Slowly it is moving into gooland. I think this is or will
happen to a lot of people. Things were looking nice and simple but
then Gears complicates things because it crosses the server/client
boundary.

"There's only so much you can do to protect people from themselves."

You are right Brad but the security structure has to suit real humans
if it is going to work. I think its a bit of a cop out to hide behind
the machines user login when nowadays the computer is just a platform
for the browser.

Mat

[sobolanul]

On May 28, 9:49 pm, Matt <gro...@googlemail.com> wrote:


> Sobo - Sure, you'd just have to enter the password in the browser. No
> password no data.
> Obviously, you don't save passwords and switch it off so no one else
> uses it. I've always thought the password saver was an oxymoron.
>

I think this is a misunderstanding. The goal of Gears is to have the
data available offline. That means that you will not have any online
server to verify your password and if you want to have password
protection in offline mode (that I personally think that is a bad
idea) you will need to have the password stored locally and all
algorithms for validating the password also stored locally in
javascript code. Even if you encrypt the local DB and local files
with Gears, the browser need unecrypted pages to work, so decryption
will be made by Gears locally. Again you will have access to the
encrypted data and encryption/decryption mechanism because all are
stored locally. I no way to protect you data as long as encryption/
decryption algorithms and encrypted data are stored locally and you
can freely access/alter any of those.
As it is now, will look to those data only somebody that wants to do
that and not from "pure luck" or just "accidentally". How often are
you browsing on those folders? And I see no way to stop somebody that
wants to see data stored locally in conditions that you mentioned
(access to the files folder). Maybe I am mistaken, but I am 100% sure
that, if you came on my computer access with the browser a site that
stores data on my computer, then cut of the internet connection and
you can retrieve your data (even with a computer restart and no
internet connection), then I will be able to see those data too
without knowing/stealing your password.

I can see a solution by having a public/private key on a usb stick and
when Gears start sync from a site to ask to provide a public key to be
used in encryption process, then in offline mode to ask to provide the
private key for decryption. But I think this will confuse lots of
people and will dramatically limit the number of user of Gears.

Just my 2 cents....

[sobolanul]

Sorry for double post, but this can be a working solution. All is need
is to gears to support encryption with a public key and description
using the corresponding private key. This can be a feature
configurable from plugin for each/some/all sites and can be also
available via API. For example we could have on our site on user
profile the option for synchronization: unencrypted or encrypted ->
"please upload a public key that will be used for encrypting your
data. please note that you will need to provide private key when you
are in offline mode to be able to work in offline mode." Then with
this option activated, any user can sync safely our site on any
computer. Also this should be configurable from plugin also: On this
computer I want that all Gears data to be encrypted with this public
key with option to overwrite for any site. And somehow to not be able
to overwrite already encrypted sites (only force encryption for
unencrypted data).
Or, drop all idea with API encryption and keep it only as a plugin
option (unecrypted/crypted with this key). This looks achievable now,
maybe there is something that I am missing.

[Ben Lisbakken]

Matt --

We have talked about this issue a lot, and I think it's a really tough one to tackle.  As sobolanul has mentioned, if data is encrypted and decrypted on the client then there is a way for a hacker to decrypt it.  And if we create an encryption API then it's only a matter of time before there is a general solution to decrypt all data encrypted with Gears.

The argument could be made that some encryption is better than none, but we have also wondered whether it could be more harmful than helpful.  Developers will assume that because there is an encryption API, that it will secure their data.  There will be a false sense of safety and developers will use less discretion when choosing what private data is OK to store on the client.  They will also be less clear with their application users that using the offline data on a public computer is not okay.  This can have some serious repercussions.

This isn't to say that we are opposed to securing offline data -- we just haven't found a technique that is effective and useable to commit to.

One interesting idea, however, is to use the Blob API when it is released (http://code.google.com/p/google-gears/wiki/BlobAPI) to store data as blobs.  While still insecure, it adds that extra layer of obfuscation to your data without giving the false impression that it is safe.

This is a good discussion and we really want to find a solution to this problem so we appreciate your concern and vocalism.

-Ben

[Brad Garcia]

I suppose another route would be to require a user to "log in" to their browser.  Then have the browser encrypt that user's data (history, cache, gears db, etc.) so that other users cannot see it.

But you still have the same lazy-user issues, right?  If you allow somebody else to "use your browser" without logging out, then once again they have access to all of that information.

Perhaps we could drive this from the web-application side.  If you are logged into something like Google Docs, then perhaps the server can provide a key for encrypting the data that it stores locally?  But then to look at the documents offline, you'd have to also have the key.  And if you're storing the key locally, then somebody else could read it and use it to decrypt your files.

As Ben said, it's not an easy problem to solve.  Any solution requires some effort on the part of the user to maintain the security.

Are you looking for real security, or just enough to keep a "notepad attack" from working (in which case, rot-13 encryption would be "good enough").

-- Brad

[John Ripley]

(Replying in general to thread)

I think there's a bit of a false dichotomy being presented here. It's
don't think it's a case of being 100% secure or not bothering at all.
Most hacks don't escape the "sandbox" they're running in, or at least
don't get very far out of it. Root escalation is fairly rare, and I'd
hazard a guess that more laptops get physically stolen than root
hacks.

We could protect the database data by encrypting it against a user
supplied password. That would make it much less likely to be
compromised. At the moment all it takes is for the browser sandbox to
be escaped (e.g the current Flash flaw) and to POST the standard
location your mail is kept in to a remote site. Yes, you could still
figure out the password, hash or whatever used to encrypt it, but
we're going from a program a 12 year old could write to something
vastly more complex.

John.

2008/5/29 Brad Garcia <bga...@google.com>:

[el]

Hi,

I am a windows user and I use portable firefox (http://
portableapps.com/apps/internet/firefox_portable).

I was wondering - how can I get the Gears data to be saved to a
location other than standard document settings?

In terms of security - my 2 cents is - don't waste time on this. Have
a way to allow the data to be stored on a usb key (or any drive letter/
directory location...this solution would have to account for shifting
drive letters of usb). If the user wants security, then they should
use a container like truecrypt (http://www.truecrypt.org/), pgp
(http://www.pgp.com/) or bestcrypt (http://www.jetico.com/).

A warning dialog to tell the user that the their data is as secure as
their computer with a link to a page that describes using the above
containers with method of changing data location (pointing to a
different location should be easy to do...that's the only mechanism
that's needed for this). If the user is paranoid about their data -
they'll take care of it. If they're not...then they've been warned.

Eli

PS: I came across Gears at Google I/O - very cool and good
presentations...thanks for doing this!

[Matt]

Sobo. I think you might have got it. The public/private key system
(public key cryptography) is almost invented for this kind of problem.
The tricky bit is to make it usable by the punters. It has to be easy
to use - I think PGP would be more widely used if the setup were
easier. This is also the most secure solution unless there is a hole
in your suggestion. I'm not qualified or experienced enough to say.

Ben. Oh - maybe there is a hole in it. Is a client still a client when
it is offline ? Obfuscation is good but not as good as being able to
tell my boss that the company data held offsite is encrypted. But I
don't want to discourage the 'blob' solution if it makes the data
impractical to find.

Brad rot-13 is good. But if this can be done couldn't a more secure
cypher be used. - Maybe I'm being greedy.

John. I agree with your post. Any cypher is only as good as the user,
so the level of security has to be balanced by efficacy of the
solution. Since the only thing common to the points of access to the
data is the user then they are going to have to supply the password. I
do however like the idea of using public key cryptography but haven't
got my head around all the implications of it.

At the end of the day its not about what level of security I would
like. I carry my data on a jumpdrive encrypted with truecrypt. Not
[just] because I'm paranoid but because I keep loosing the bloody
things.

As gears gets used by more people the security risk will escalate,
this could happen very quickly. So its about presenting a system that
has an assurance of a good level of security so that all users, not
just private users but professional users, can have a sense of trust
that their data held by google, whatever computer it is on, is safe -
as well as being wonderfully easy to access.

Mat

[Ben Lisbakken]

Matt --

What I am saying is that encryption on the client is really only obfuscation.  If it is encrypted and decrypted on the client (how would you encrypt data for offline use if it can't be decrypted while offline, e.g. the client must do this), then there is a way to figure out how to break that mechanism.  If there is a way to break the mechanism, then it becomes a question of "how secure, is our insecure encryption"?  Which almost means that the data is just obfuscated.

This is why I mentioned blobs, because blobs obfuscated the data, but the benefit is that a developer using blobs realizes that the data is just stored as the bits and bytes in the database and can be changed back.  A developer using an encryption API will bet on it being secure, when it's not.

Matt, you mentioned that you want to be able to tell your boss that the data is encrypted and not obfuscated.  This is kind of the situation we want to avoid.  When someone breaks the encryption of your local data, your boss will breath down your neck and it will look like Gears has significant security holes.  While you might realize and explain to your boss that it is "good enough security, but not totally secure", many developers won't.

Again I want to reiterate that we are 100% FOR securing the data locally.  And, putting myself in your shoes, I would also want an encryption API so that a 12-year-old can't grab the data.  But I think maybe (my opinion) that this type of service is much more fit for a community-generated framework.  As an official Gears API developers might trust it without questioning it.  As a third party API, they might be more cautious to read the warnings e.g. "This is good-enough-encryption".

I think the USB keys are an interesting area of talk.  However, the usability is sort of a clincher.  The average Joe's of the web world are hard to convince to download a plugin for their browser.  Telling them they also need a USB key for the functionality makes things even harder.

I feel like the negative nancy of the thread :(

-Ben

[Matt]

I'm going to argue the opposite, partly because I think its done
better at the heart of the machine and partly because I see it more as
a responsibility of the core developers. Having said this I am fairly
ignorant of the project development structure so forgive me if I'm
talking ... rubbish.

Obfuscation is good and it does solve the problem of the curious 12
years old. As you and other s have said the google password is stored
client side so it is practically little different than encryption (not
that I know much about the blob API). To be honest this password
issue is a bit of a worry for me. Its not really a locked door if the
key is left in the lock.

If gears and assorted applications are going to be taken up by
professional users then these organisations are going to ask questions
about security. They might see your obfuscation solution as, well,
obfuscation. They will expect there to have been some attempt to have
the data secure. Most of these people will use login users on their
machines which will give a degree of security but they might worry
about people using gears at home, or on their friends machine.
Encryption provides a solution for this problem, but has you have
mentioned does not solve the problem as the data is vulnerable on the
client.

Either an organisation will need to have a way to switch off the
ability to activate gears on machines they don't own, and then can
rely on their login security or there has to be another way,
obfuscation or encryption.

As John said "We could protect the database data by encrypting it
against a user supplied password." - Is there any another way that
provides a level of security appropriate to a professional
environment?

Matt

[Ben Lisbakken]

Matt --

You're not talking rubbish :)  These are all valid concerns!

I think my question to you is: how is Gears data different from normal data on your computer?

Let's look at the case of e-mail.  If you have a desktop mail client and someone steals your computer (I might be wrong), I think that generally someone can just open up your client program and read your e-mails.  I guess the only thing stopping them is your OS login.  Also, I don't know that mail clients encrypt their e-mail messages while they are stored on the desktop.  So a stolen computer with a desktop mail client could have its mail read by booting from an OS on a CD.

I think that using Gears to make applications usable offline brings them into the domain of Desktop applications.  In that sense, I think that if you wanted data on your hard drive encrypted it is probably better to rely on a general solution rather than for each of your "desktop" (I'm including Gears apps in this category, now) applications to provide it.  I use FileVault for Mac (http://en.wikipedia.org/wiki/FileVault).

-Ben

[John Leach]

An interesting thread. Security is a very nasty problem, which a lot
of people just don't like to talk (or think) about. Hence Ben's worry
that developer's will 'just use it' (it being some Gears API) thinking
it's safe - nobody likes to have to handle the problem.

I feel that there is a technical and non-technical side to this
discussion. Perhaps I can help a little - this may make things
clearer, or make things worse...

I (much as you) want to save sensitive data on the user's computer,
and in Google Gears this is stored in a database in a well known
place. (Even if the docs didn't tell you, it really wouldn't be
difficult to find).

The database can be read by any SQlite compatible application, such as
SquirrelSql
http://www.squirrelsql.org/
(I haven't tested this, but it seems very likely, Ben can probably
confirm).

Unfortunately, automagic encryption doesn't really work. To encrypt/
decrypt data you need:
1. The (encrypted/decrypted) data
2. A key or password
3. An encryption/decryption algorithm

If one of these pieces is missing, the encrypted data is 'safe', or as
safe as the algorithm/key combination allows. If I assume that the bad
guys have the data, I must also assume they know the algorithm (just
read the Javascript code of the application). So really, only the key
can be 'missing'.
If the key is also available, in the database, or the code, well then
as Ben said, this is only obfuscation. The bad guy will, eventually
find the key. Probably minutes if it's in the database, hours to read
the code. None of this 1000 years stuff, that's for sure.

On a server platform, the entire user information can be protected by
a password and the algorithm. You have to provide the key (password)
to see the decrypted data, and this same password can be used to
provide other levels of security, such as authorisation to do specific
actions.
The server (usually) doesn't store the password, but encrypts it (yes,
even more encryption). When you log in, the server encrypts your typed
password, then compares that with the stored encrypted password. So
even if I could steal the database, I won't know your password.

With web applications, we're used to 'logging in', to read our mail,
or whatever. We know that the server needs to recognise us from
someone else.

This thread also talked about asymmetric encryption (public/private
keys), which is fine when you have two separate computers. I encrypt
information that I want to send to you with your public key, you
decrypt it with your private key. Everyone can (and should) know the
public key, but only you should know the private key.
These keys tend to be big and nasty (you won't be able to remember
them), and the private key should never be stored where the bad guys
can find it. So it too must be 'missing' from the equation. Here, the
USB memory stick makes sense. But don't leave it on the bus.

Conclusions:
1. Asymmetric keys aren't necessary for Google gears, because
encryption/decryption takes place on one computer. Though we could
consider the USB memory stick, holding the private key, as being the
second computer. Writing the algorithm in JavaScript will be a
challenge...
2. The only thing we can keep secret is the key or password.
3. The key or password must not be stored by the application,
shouldn't even be on the computer (and don't write them in
mypasswords.txt), so the Google Gears application must ask you for it.
4. If you have a lot of encrypted data, changing the key or password
will be expensive (decrypt the entire db with old key, encrypt it
again with new key), it could take minutes...
5. The user will think it a little strange that the Google Gears
application asks for a password even when offline (hey, you know who I
am, this is my computer), it might even be a different password to the
online password.
6. The user will forget the password, and thus loose his data, and no
the Google Gears application doesn't know what it is either, and no it
can't just 'reset' it and send you an email.

I think that, as a developer, I must give the user the choice:
a) a 'no password' version, but without sensitive data (uhm, define
sensitive, please)
b) password version, sensitive data, but encrypted, and a slower
application, and possibility of loosing the data because you forget
the password.
c) there is no option c.

I'm seriously contemplating a new career in farming...

John

[Ben Lisbakken]

John --

Thanks for taking the time to highlight the technical difficulties!  You are definitely correct about squirrelsql.org -- which brings me to a good point to drop a hint that using the FF extension SQLite Manager makes developing with Gears much easier... (or some sort of SQLite viewer).

-Ben

[John Ripley]

You can probably change passwords without the expense. I'm making this
up as I go along, but this sounds like it would work:

* User types password.
* Hash the password (e.g SHA-256 generates 256 bits).
* Generate some random data (e.g 256 bits).
* Encrypt the random data with the hashed password (XOR will do, no joke).
* Use the encrypted random data as the (256 bit) key for the database.

Accessing data would go like this:

* User types password, SHA-256 hashed to 256 bits.
* XOR with the key.
* Use the XOR'd key to access the database.

Then changing the password would involve:

* Enter old password, SHA-256 hash.
* Enter new password, SHA-256 hash.
* XOR the hashes.
* Use the result to XOR the 256 bit key. Save.
* The key can now only be used with the new password.

Basically another layer of indirection for the encryption key. I'm no
crypto expert, this probably has tons of related-key holes in it, it
needs salting, and a pinch of salt :)

As for loss of data - this isn't that big an issue for web
applications that sync offline:

* User loses password.
* Opts to reset database.
* Application syncs the entire database from remote again.

If the data only ever lives locally... it's a big problem.

I'm still wondering if it's possible to build a system where you only
need a single password for both online and offline access. That would
make the user experience uniform. I know there's a lot of fundamental
issues single password, but it still nags me that it might just be
possible.

John.

2008/5/30 John Leach <john....@syger.com>:

[Chris Prince]

> I'm still wondering if it's possible to build a system where you only
> need a single password for both online and offline access. That would
> make the user experience uniform. I know there's a lot of fundamental
> issues single password, but it still nags me that it might just be
> possible.

There is another tricky issue here. Most users choose weak passwords.
A server can rate-limit any brute force dictionary attacks. But with
client-side encryption, the dictionary attack takes just a second.

And even worse, now the attacker has your online password. (Most
users will use the same offline and online passwords.)

[John Leach]

Ben - I didn't know about the FF plugin (does FF have a plugin to make
coffee yet?). Good to know I can debug with SquirelSql though.

John - Sorry, you lost me. I'm no crypto expert either but, If
a) plain data + key + algorithm = encrypted data
and
b) encrypted data + key + algorithm = plain data
then I don't see how you can get b) if you change the key (however you
do it).
I think you'd have to do
c) ((old encrypted data + old key + algorithm = plain data) + new key
+ algorithm) = new encrypted data

John

> 2008/5/30 John Leach <john.le...@syger.com>:

[John Ripley]

The idea is this:

* The database is encrypted with a randomly chosen 256 bit key.
* The key is stored in the database, encrypted by a password.
* To access the database contents, you need to decrypt the key, which
needs the password.
* To change your password without losing access to the database, you
just need to decrypt the key with the old password, then re-encrypt
with the new one.

The user's password never gets stored as plain text anywhere (except
during entry), and the access key is just 256 bits of junk only useful
to that database.

John.

2008/5/30 John Leach <john....@syger.com>:
>

[John Leach]

The metallic noise you hear is simply the penny dropping.
Thanks, much simpler than what I'd been thinking of. Virtual beer
sent.

John

On May 31, 2:28 am, "John Ripley" <jrip...@google.com> wrote:
> The idea is this:
>
> * The database is encrypted with a randomly chosen 256 bit key.
> * The key is stored in the database, encrypted by a password.
> * To access the database contents, you need to decrypt the key, which
> needs the password.
> * To change your password without losing access to the database, you
> just need to decrypt the key with the old password, then re-encrypt
> with the new one.
>
> The user's password never gets stored as plain text anywhere (except
> during entry), and the access key is just 256 bits of junk only useful
> to that database.
>
> John.
>

> 2008/5/30 John Leach <john.le...@syger.com>:

[Matt]

Ben, my attempt to answer your question. Sorry about the delay I have
been reading the last few posts with great interest.

First you should read this google statement on security for google
apps, if you haven't already (I like the bit about armed personnel
protecting our data). Interestingly there is no mention of gears in
the security statement but maybe gears is excluded from this version
of Google apps somehow?
http://www.google.com/a/help/intl/en-GB/admins/security.html

"I think my question to you is: how is Gears data different from
normal data on your computer?"

My argument is as follows.

how is gears different from e-mail? :
1) e-mail is a shared experience and is always intended for someone
else. so people think about it before they write an e-mail. There is a
process of evolution selecting out those that don't. 2) most people
would not be able to install an e-mail client on their home PC and
their work administrator would be concerned if they did. Webmail is a
useful intermediary and users have switched to it in droves. 3) people
don't often really want to collaborate over writing an e-mail, and if
they do they can just e-mail drafts to each other.

Users want accessibility and will take steps to improve access to
their data - and this might mean installing gears here there and all
over the place. This is great, as the whole point is to have the data
as accessible as possible. This is why even I, as a paranoid truecrypt
user, don't want to see any significant loss of accessibility to my
google docs due to improved security. There is no point having a
secure system that nobody uses. What constitutes significant loss of
access is an interesting question.

As far as normal data on the hard drive, if people trusted the
security provided by the client login then people wouldn't use
encrypted volumes on their hard drives. Its clear from this discussion
that many people do.

The bottom line issue for me and I think other system administrators,
or people who have to do this as part of their job, is that we want to
have the advantage of having data stored by google but we don't want
to loose control over company data. For example I know that
administrators have deliberately prevented their organisations from
using systems that pass data from the company servers to employee's
home computers. It would be a pity if concerns over security reduced
take up of the gears solution.

As you said, the key security points to accessing the data are the
client side user login and the google login. If gears based apps are
to be downloadable apps that can be used on the client through the
browser then the client login should drive the security. However, if
we really want these 'client side' apps to behave as an extension of
google, the data to be interchangeable and the off-line experience to
be the same as the experience of server side applications; then the
google login should drive security. However, it appears that this
might not be possible off-line, and their might have to be another
password to achieve off-line security. This might be an annoyance for
the occasional user but a necessity for a more serious users, and you
want ot encourage serious users. The technical solutions (and their
boundaries) seem clearer, John's solution is so clearly out that even
I understand it, but the issues of ergonomics still need to be mapped
out.

Suggestions
1) One of the great aspects to google is the ability to collaborate
over writing documents. For the sake of clarity there should be a
clear relationship between this and any user or administrator options
over security.
2) Users should have as much control over this function as possible.
3) Corporate users will want to have to power for administrators to
set all documents (and spreadsheets) on the client side as encrypted,
to include data held offsite.
4) Encryption should be the default so people who don't understand it
don't take unnecessary risks.
5) We should not forget the point about the potential for opening a
backdoor into google through local storage of the google login. People
store their credit card details in google!

However, I am not sure how much of this is down to gears and how much
or other development groups in gooland but would rather the problem
wasn't ignored because it is someone else's job

Matt

[Andy9]

I am delighted to see this discussion, but will also be glad to wait
for its outcome, as I don't feel competent to contribute to the
details. Being in the field of public health, I can say that
questions about security are often asked by those who know the least
about it, but have power to accept or reject software use based on
their own dim (or maybe clear) understanding.

So good security means
1. Hacker resistance
2. User-misuse resistance
3. Clarity and test results for those in the front room (or upstairs)
The first two have been well-discussed, although not solved, in the
discussion so far, mainly based on passwords of various types.

How about some discussion of biomarker-based security, such as facial
recognition or fingerprints, in combination with passwords? Once a
method is found, how about a worldwide contest with a prize for the
first person to crack the method and suggest a better one? $50,000 or
a job at Google would be a good prize. You'd want to count the number
of people trying in order to use the results for "accreditation" of
the method.

I know that from down in the trenches, this seems pretty remote, but
we're on the Internet, and Clouds are supported and propelled by air.

On Jun 1, 5:37 am, Matt <gro...@googlemail.com> wrote:
> Ben, my attempt to answer your question. Sorry about the delay I have
> been reading the last few posts with great interest.
>
> First you should read this google statement on security for google
> apps, if you haven't already (I like the bit about armed personnel
> protecting our data). Interestingly there is no mention of gears in
> the security statement but maybe gears is excluded from this version

> of Google apps somehow?http://www.google.com/a/help/intl/en-GB/admins/security.html

[John Leach]

Matt,

I know you didn't direct your suggestions to me, and I'm just a
developer who doesn't work for Google, but...

I think Google Gears will be used by both large and small players in
the web application industry, not just Google.

> First you should read this google statement on security for google
> apps, if you haven't already (I like the bit about armed personnel
> protecting our data). Interestingly there is no mention of gears in
> the security statement but maybe gears is excluded from this version
> of Google apps somehow?http://www.google.com/a/help/intl/en-GB/admins/security.html

Well, I did read it - gives you a nice warm fuzzy feeling, doesn't it?
Pity not all players in the industry are that good.

> The technical solutions (and their
> boundaries) seem clearer, John's solution is so clearly out that even
> I understand it, but the issues of ergonomics still need to be mapped
> out.

Er, "so clearly out"? Verb missing, or just a non starter?

Personally, I think John Ripley's suggestion is quite far reaching,
the data records can be pre encrypted using either the user's password
or a special "offline" password.
I'm still no crypto expert, but unless I watch you type the password,
John's suggestion would be difficult to break, because I'd have to
test my decryption attempt against the data...

BTW, I agree with Ben, it would be wrong of Google to offer an API as
'the encryption solution', but I do think that an encryption helper
methods API would be nice here.
SHA1, DES, MD5, et al in JavaScript anyone?

> Suggestions
> 1) One of the great aspects to google is the ability to collaborate
> over writing documents. For the sake of clarity there should be a
> clear relationship between this and any user or administrator options
> over security.

... and not just Google. However, it's one thing to provide a 'warm
fuzzy feeling' document on security, and another to visually explain
to the user what they can or cannot do, and what the potential
consequences will be. For example, I frequently buy things via credit
card. I like to think that the web application does *not* store my CC
information permanently, but just for the period of the transaction
(usually a few seconds to a few minutes), however, it frightens the
willies out of me when I go back to the site and it says "Welcome
back, John, want to buy something with your American Express card #XYZ
today?" - actually I got an email for a new service - "Your
subscription expires in 10 days, but don't worry, with our new service
if you don't do anything we'll charge your credit card automatically".
Aaaargh!

> 2) Users should have as much control over this function as possible.

Agreed, even if that means 'no functionality', that is, the web
application cannot offer offline or local storage functionality at
all.

> 3) Corporate users will want to have to power for administrators to
> set all documents (and spreadsheets) on the client side as encrypted,
> to include data held offsite.

And a 'delete all data on exit' option, methinks.

> 4) Encryption should be the default so people who don't understand it
> don't take unnecessary risks.

Yeees, so therefore passwords et al.

> 5) We should not forget the point about the potential for opening a
> backdoor into google through local storage of the google login. People
> store their credit card details in google!

No, there are plenty of other backdoors, such as Cross Site Scripting
(XSS)
http://en.wikipedia.org/wiki/Cross-site_scripting
or Cross Site Request Forgery (XSRF)
http://en.wikipedia.org/wiki/Cross-site_request_forgery
However my understanding is that Google Gears WorkerPools are
protected from XSS, and therefore from XSRF, but the main page is, er,
well just a poor vulnerable web page (and that's my fault, partlially
the browser's, but not Google Gear's fault).

> However, I am not sure how much of this is down to gears and how much
> or other development groups in gooland but would rather the problem
> wasn't ignored because it is someone else's job

It's not just a Google problem. It is the responsibility of all web
developers. Whether they all take that responsibility seriously or not
is another question.

Andy9,

> So good security means
> 1. Hacker resistance
> 2. User-misuse resistance
> 3. Clarity and test results for those in the front room (or upstairs)
> The first two have been well-discussed, although not solved, in the
> discussion so far, mainly based on passwords of various types.

It's like securing your house. Leave the front door open, and even I
could steal your TV. Lock the door, and I'd need some experience
picking locks(or poackets, for the key). Use a security lock and steel
door (like most apartments in Italy) and I'd need a bit more
experience. You'll need an armed guard with closed circuit TV, and
other James Bond gadgets to keep a real professional out of your
house, though the guard could be bought off, etc, etc. The Loeuvre,
Buckingham Palace, both spring to mind here...

> How about some discussion of biomarker-based security, such as facial
> recognition or fingerprints, in combination with passwords? Once a
> method is found, how about a worldwide contest with a prize for the
> first person to crack the method and suggest a better one? $50,000 or
> a job at Google would be a good prize. You'd want to count the number
> of people trying in order to use the results for "accreditation" of
> the method.

It sounds very secure - biometrics are very personal, like DNA, and
great for recognizing someone. Especially in a court of law.

After your iris or thumbprint has been through the scanner it becomes
digital data - which can be stolen, just like your car keys, credit
card or ipod.
Unfortunately, I've only got one DNA, two eyes and ten fingers...

Believe me, I'm not being facetious, I just think that the bad guys
are one step ahead most of the time...
And the goog guys can be a little, er, lax sometimes...
http://news.bbc.co.uk/1/hi/uk_politics/7103566.stm

> I know that from down in the trenches, this seems pretty remote, but
> we're on the Internet, and Clouds are supported and propelled by air.

Lovely thought. Fortunately, the Internet is also a solid indication
that 95% of the users simply want to use it in an efficient and honest
way. For them we wouldn't need any protection at all. And I'd just
have to concentrate on writing code that, er, works.

John L.

[John Leach]

Typo sorry (nasty one too)
For
"And the goog guys can be a little lax"
read
"And the good guys can be a little lax"
Nothing to do with Google, much to do with the British Government.

John

> (XSS)http://en.wikipedia.org/wiki/Cross-site_scripting
> or Cross Site Request Forgery (XSRF)http://en.wikipedia.org/wiki/Cross-site_request_forgery

> And the goog guys can be a little, er, lax sometimes...http://news.bbc.co.uk/1/hi/uk_politics/7103566.stm

[Matt]

I have been looking at the security extensions available for firefox.

Of which fire gpg looks the most interesting:
https://addons.mozilla.org/en-US/firefox/search?q=gpg&cat=all
and fireencrypter looks fun to play with:
https://addons.mozilla.org/en-US/firefox/addon/3208

However, these fail to proved the kind of security we have been
talking about. Firepgp looks good but is a pain to use and
fireencrypeter is more an educational tool, but could be used to try
out John Ripley's 'well mapped out' solution.

This makes me think that an extension is not a practical solution.
*It is not an opt out but an opt in process ie the secure option is
not default
*It is not an accessible solution for Joe user
*Its an awkward solution and likely to remain so

Other extensions do offer protections for the CSS backdoor but this
might interfere with gears or other browser run functions (this is the
point of them I guess). And other extensions I would not want anyone
to install on a computer I ever used because they do strange and
insecure things. I'm not sure I'd want to encourage any user at work
to use them at all, and would rather they didn't know of their
existence just in case.

I did think about the idea of different levels of security, ie
protection from the curious 12 year old or the hard core hacker. But
after a lot of thought it really only comes down to a binary
opposition. Either its open or closed. The area in between usually
comes down to levels of motivation and indiscretion.

This is important because people may well say they want security but
will actually vote with their feet and use an less secure system
because its convenient. I was going to cite the example of amazon
where I recently bought a book by mistake (I didn't think buy it now
meant now now) but I think this applies to the whole internet to some
extent.

I was wondering when someone would suggest biometrics. I hadn't
thought about it before but there is a security laps here too. With
biometrics it is a hard to change your password. I think this might be
a weak solution if a system were tied into it.

Matt

PS Gears & security: http://code.google.com/apis/gears/security.html#model