gmailagent-devel

[Gmailagent-devel] RFC: libgmail contacts

[Stas Z <sta...@gm...>]

Hello

Just some random thoughts about the contacts support in libgmail
including the extended notes stuff andrew cooked up.

1. Do we really need the extended data from the contacts?
I think that a person that really wants to keep all kinds of
data about their contacts will use evolution of some other app
but probably doesn't use Gmail contacts.

2. We *must* consider adding some sort of delay between page
requests to Gmail. We are risking "Lockdown error in sector 4"
situations when users have a lot of contacts.
"Lockdown...." is when Gmail disables the account for a period of
time due to usual Gmail usage.
User 'posey_p' has reported this:
"""=20
  I am calling getSpecInfo() for each entry to get their notes fields for e=
ach
gmail contact. After a certain number of requests, Gmail sends me an "Unusu=
al
usage error" and disables my account!
 """

3. Should we use Andrews approach of 'parsing' javascript by using Python's
exec statement or use libgmail's text processing?
The exec approach seems to be better when it comes to unusual characters
inside the page but I feel that the libgmail way is much more secure.

Cheers,
Stas

--=20
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.

[Gmailagent-devel] Re: RFC: libgmail contacts

[Andrew L. <one...@gm...>]

Hi Stas et al.,

I've subscribed myself to gmailagent-devel, so you won't need to cc me anym=
ore.

1. A good point.  The reason I wanted this functionality is that gmail
is my primary email system (in fact, the only other one I use is
Outlook/Exchange, against my will...) and as such I wanted to keep my
primary address book in the same place.  I don't know how many other
people are in that boat.

2. An optimization you could look at is not reading a contact in full
(i.e., in your case calling _getSpecInfo()) if you can tell that the
notes field is empty.  I guess there may be corner cases (what happens
if the first line of notes is blank?) to investigate; I'm sure that
that won't happen in my personal address book, so I didn't bother
checking before putting this in my module.

3. I actually believe my code is safer.  I tried for some time to
break out of the restricted evaluation mode you get by setting
__builtins__ to None, to no avail.  Furthermore, I'm fairly sure that
even if you could get out of that with carefully constructed code, it
would require Google programmers to deliberately inject that code into
their returned Javascript to exploit it.

On the other hand, since you got me to thinking about it, I think I
can show how libgmail's parser is currently unsafe.  Because I'm not
sure how serious a security hole this is, I'll send details to Stas
and await his approval to mail the list.

Andrew


On 9/17/05, Stas Z <sta...@gm...> wrote:
> Hello
>=20
> Just some random thoughts about the contacts support in libgmail
> including the extended notes stuff andrew cooked up.
>=20
> 1. Do we really need the extended data from the contacts?
> I think that a person that really wants to keep all kinds of
> data about their contacts will use evolution of some other app
> but probably doesn't use Gmail contacts.
>=20
> 2. We *must* consider adding some sort of delay between page
> requests to Gmail. We are risking "Lockdown error in sector 4"
> situations when users have a lot of contacts.
> "Lockdown...." is when Gmail disables the account for a period of
> time due to usual Gmail usage.
> User 'posey_p' has reported this:
> """
>   I am calling getSpecInfo() for each entry to get their notes fields for=
 each
> gmail contact. After a certain number of requests, Gmail sends me an "Unu=
sual
> usage error" and disables my account!
>  """
>=20
> 3. Should we use Andrews approach of 'parsing' javascript by using Python=
's
> exec statement or use libgmail's text processing?
> The exec approach seems to be better when it comes to unusual characters
> inside the page but I feel that the libgmail way is much more secure.
>=20
> Cheers,
> Stas
>=20
> --
> A nation that continues year after year to spend more money on military d=
efense
> than on programs of social uplift is approaching spiritual doom.
> Martin Luther King, Jr.
>

Re: [Gmailagent-devel] Re: RFC: libgmail contacts

[Stas Z <sta...@gm...>]

As of this moment the contacts support seems broken due to a change in Gmai=
l.
I suspect they have a cron job for changing the pages at random just for fu=
n :-/

On 9/18/05, Andrew Lin <one...@gm...> wrote:
> Hi Stas et al.,
>=20
> I've subscribed myself to gmailagent-devel, so you won't need to cc me an=
ymore.
>=20
> 1. A good point.  The reason I wanted this functionality is that gmail
> is my primary email system (in fact, the only other one I use is
> Outlook/Exchange, against my will...) and as such I wanted to keep my
> primary address book in the same place.  I don't know how many other
> people are in that boat.
Ok, so there's a need for extended contacts.
=20
> 2. An optimization you could look at is not reading a contact in full
> (i.e., in your case calling _getSpecInfo()) if you can tell that the
> notes field is empty.  I guess there may be corner cases (what happens
> if the first line of notes is blank?) to investigate; I'm sure that
> that won't happen in my personal address book, so I didn't bother
> checking before putting this in my module.
I think we could use the 'old'  notes retrieval and use the full notes
as a option
with a time delay.

> 3. I actually believe my code is safer.  I tried for some time to
> break out of the restricted evaluation mode you get by setting
> __builtins__ to None, to no avail.  Furthermore, I'm fairly sure that
> even if you could get out of that with carefully constructed code, it
> would require Google programmers to deliberately inject that code into
> their returned Javascript to exploit it.
Your probably right, I must confess I forgot that our parser uses
unsave stuff :-(

> On the other hand, since you got me to thinking about it, I think I
> can show how libgmail's parser is currently unsafe.  Because I'm not
> sure how serious a security hole this is, I'll send details to Stas
> and await his approval to mail the list.
Thanks, I will forward it to Waseem too.

@Waseem, it's a security risk indeed :-(

Stas

--=20
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.