> What about using it as cheap remote backup? That's been one of my plans.
I'm the author of the Python Gmail binding libgmail GmailFS uses as its backend interface to Gmail. The library includes a demo FTP download proxy & a plan for upload is still in the works. Thought about WebDAV support as well, but most popular (unrelated) request has still been IMAP support.
Funny thing is I briefly looked at a VFS based solution a few weeks ago, but I primarily use OS X for my development and it doesn't have any VFS ported to yet that I'm aware of, so didn't go down that avenue.
> I'm surprised that having direct access to the root folders > of a gmail account (like it's a pop/imap account) is even possible. Well, considering the number (more than one) of existing POP proxies for Gmail there's no reason to be surprised.
GmailFS uses the Python Gmail binding libgmail as its backend interface to Google. It library includes demo POP, SMTP & FTP proxy servers if you're interested in seeing how it works.
> Google could very easily "break" this program simply by adding some clutter to it's currently pristine user interface. It's not quite that easy to break, check out the frame source of a Gmail folder view window sometime--there's basically no HTML, just a bunch of calls to Javascript functions with all the data contained in arrays.
> This really is an action by one kid that could > ruin the sandbox for everybody... Highly unlikely. Besides, you have to blame at least two kids, the author of GmailFS & the author of libgmail.
> Though from what I can tell from the HTTP GET string it's protected to high hell. Nah, it's not really protected--there are actually similarities between it and the existing HTML method.
The login occurs via HTTPS, then everything else is straight HTTP (which I would think would be a security hole).
> GMail notifier sends an HTTP GET query to the GMail server, > the GMail server sends back the number (and almost only the number) > of messages It actually sends back a binary data block, the content of which depends on whether you have new messages or not.
Try using Ethereal when you have new messages and you'll see sender/subject/message snippets in plain ASCII within the data block retrieved.
See these forum postings for more details I documented:
> Perhaps they're worried about coders going to next level, > and coding up entire gmail readers--or incorporating gmail account readers > into something like Thunderbird. That sort of thing has already been done for months--there's POP & SMTP proxies for Gmail already. And if one of them doesn't work on your platform you can use the Gmail Python binding project `libgmail` to write one of your own.
> Adding that word-identification script filter to the login process > would certainly prevent something like that It wouldn't really prevent that because the proxies could just start presenting the image for verification if it encountered one. This approach doesn't stop individual users, it just stops fully automated approaches, such as the apparent brute force attacks were using. (And the much more feasible reason for the addition.)
> Which leads me to wonder how google's own system tray email > notification program can still work. The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
This might mean that if you encounter the Captcha after multiple bad logins via IE the official notifier may not work either.
See these forum postings for more details I documented:
> The big deal is that they want third party apps to stop actually logging in > and pulling the full HTML for the main page, and start copying what the notifier does, > which is to pull down something much smaller, simpler, and less CPU intensive for google.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
There's no reason for existing clients to be pulling down particularly huge amounts of data, the data retrieved isn't really in HTML anyway.
For more on exactly what the official notifier retrieves see these forum postings for details I documented:
> And how can Google's official client do it any better?
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
So, as far as the client/server side of things goes there is no real difference. In fact I would guess you could probably fiddle with the official binary or registry keys to change the wait time.
> The 3rd party scenario is relatively CPU and network intensive. [snip]
> Google can set it up so that the client establishes a TCP connection and then using periodic keepalives, keeps it up.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
See these forum postings for more details I documented:
> Last time i checked there were no google notifiers for anything but windows.
Well, no other "official" ones, but there's at least two for OS X and a number for Linuxy things.
If your platform of choice runs Python then you can use the Python Gmail binding project `libgmail` to write your own...
I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:
> all traffic must be tortured through a webmail interface Most Gmail interaction doesn't rely on ordinary screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.
If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.
The upshot is that it's more reliable than "ordinary" screen-scraping.
--Phil.
P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.
I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:
> They're just ordinary screen-scrapers Most Gmail interaction doesn't rely on "ordinary" screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.
If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.
The upshot is that it's more reliable than "ordinary" screen-scraping.
--Phil.
P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.
> Earlier they were dumping anything matching *mail*. > We discovered this, this morning by searching for qmail sites.
Funnily enough, I was searching for `libgmail` (my Python binding for Gmail access) when it stopped working. But it only forbid it when I tried searching for a specific version number "0.0.6", which I eventually generalised to "..." being banned.
Initially I was like "Crap, they could've just asked me to stop working on it..!".:-)
> they are not suddenly going to grok the mysteries of sudo when switching to some other OS.
Under OS X this happens automatically, via a GUI so you don't need to know it's going via sudo. (A dialog is displayed saying something like "Application Foo is requesting something something...".
> Guilty? What an odd question. Correction...What a meaningless question
I don't think that's entirely the case. The thought I haven't seen expressed elsewhere in this story is the cause of the guilt is the idea of settling for something "less Free" because it's easier in the short term.
If you think that, overall, Free Software is a Good Thing(TM) and in an ideal world would only use it, but instead use OS X because it's "close enough" to Free and works really well then there is a dis-connect between what you wish you could do & what you actually do. Hence, guilt about the operating system you use.
This contrasts with someone like RMS who would rather write something from scratch than go the "easy way" and use something that's not Free. It all depends on whether you consider there are more important things than just getting a job done.
RMS believes that Freedom is more important than just getting the job done (and is willing to pay the price), but many others think that getting the job done is more important than holding slavishly to Free Software principles.
And still others are pretty sure that Freedom is more important than just getting the job done, but really want to get the job done and do so using whatever is "easiest"--and these are the ones that feel guilty...
Funnily enough, apparently (according to the bubblewrap company's web site) bubble wrap was originally invented to be a wall-paper, so it probably started out sticky...
> Another solution is that I have some contacts (companies, usually a friend of mine is working there) > I use to do some private work for, and they have no problem with me sitting at one of their unused desks. Yeah, finding a deal like this is *great*--if infrequent. I'm fortunate enough to have access to an office (with a carpark outside "normal" work hours--when I tend to work) and internet access, rent free. Even more of a bonus the office leaser passes clients my way too...
> keeping multiple copies of Mozilla up for days eventually eats an incredible amount of memory.
In my experience keeping *one* copy of Mozilla open is enough to do that....
Re:Not very different from google news
on
News at a Glance
·
· Score: 1
> This site doesn't strike me as being very different from Google News. What I'm suprised about is that nobody has mentioned it *is* a rip-off of Google News:
e.g.:
"International versions of Google News available in: Australia - Canada - France - Deutschland - India - Italia - New Zealand - Espana - U.K. - U.S." -- <http://news.google.com/>
vs:
"All editions U.S. Canada U.K. Espana France Deutschland Italia India Australia New-Zealand"
Slashdot Mirror
> What about using it as cheap remote backup?
That's been one of my plans.
I'm the author of the Python Gmail binding libgmail GmailFS uses as its backend interface to Gmail. The library includes a demo FTP download proxy & a plan for upload is still in the works. Thought about WebDAV support as well, but most popular (unrelated) request has still been IMAP support.
Funny thing is I briefly looked at a VFS based solution a few weeks ago, but I primarily use OS X for my development and it doesn't have any VFS ported to yet that I'm aware of, so didn't go down that avenue.
--Phil.
> I'm surprised that having direct access to the root folders
> of a gmail account (like it's a pop/imap account) is even possible.
Well, considering the number (more than one) of existing POP proxies for Gmail there's no reason to be surprised.
GmailFS uses the Python Gmail binding libgmail as its backend interface to Google. It library includes demo POP, SMTP & FTP proxy servers if you're interested in seeing how it works.
--Phil.
> Whatever interface-ripping this tool uses,
:-)
It uses the Python Gmail binding libgmail.
> Google could very easily "break" this program simply by adding some clutter to it's currently pristine user interface.
It's not quite that easy to break, check out the frame source of a Gmail folder view window sometime--there's basically no HTML, just a bunch of calls to Javascript functions with all the data contained in arrays.
> This really is an action by one kid that could
> ruin the sandbox for everybody...
Highly unlikely. Besides, you have to blame at least two kids, the author of GmailFS & the author of libgmail.
--Phil.
P.S. Heh.
> Though from what I can tell from the HTTP GET string it's protected to high hell.
Nah, it's not really protected--there are actually similarities between it and the existing HTML method.
The login occurs via HTTPS, then everything else is straight HTTP (which I would think would be a security hole).
> GMail notifier sends an HTTP GET query to the GMail server,
> the GMail server sends back the number (and almost only the number)
> of messages
It actually sends back a binary data block, the content of which depends on whether you have new messages or not.
Try using Ethereal when you have new messages and you'll see sender/subject/message snippets in plain ASCII within the data block retrieved.
See these forum postings for more details I documented:
Official Gmail Notifier protocol documented
--Phil.
> Perhaps they're worried about coders going to next level,
> and coding up entire gmail readers--or incorporating gmail account readers
> into something like Thunderbird.
That sort of thing has already been done for months--there's POP & SMTP proxies for Gmail already. And if one of them doesn't work on your platform you can use the Gmail Python binding project `libgmail` to write one of your own.
> Adding that word-identification script filter to the login process
> would certainly prevent something like that
It wouldn't really prevent that because the proxies could just start presenting the image for verification if it encountered one. This approach doesn't stop individual users, it just stops fully automated approaches, such as the apparent brute force attacks were using. (And the much more feasible reason for the addition.)
> Which leads me to wonder how google's own system tray email
> notification program can still work.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
This might mean that if you encounter the Captcha after multiple bad logins via IE the official notifier may not work either.
See these forum postings for more details I documented:
Official Gmail Notifier protocol documented
--Phil.
> The big deal is that they want third party apps to stop actually logging in
> and pulling the full HTML for the main page, and start copying what the notifier does,
> which is to pull down something much smaller, simpler, and less CPU intensive for google.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
There's no reason for existing clients to be pulling down particularly huge amounts of data, the data retrieved isn't really in HTML anyway.
For more on exactly what the official notifier retrieves see these forum postings for details I documented:
Official Gmail Notifier protocol documented
--Phil.
> And how can Google's official client do it any better?
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
So, as far as the client/server side of things goes there is no real difference. In fact I would guess you could probably fiddle with the official binary or registry keys to change the wait time.
--Phil.
> The 3rd party scenario is relatively CPU and network intensive. [snip]
> Google can set it up so that the client establishes a TCP connection and then using periodic keepalives, keeps it up.
The official Gmail notifier simply uses standard http/https requests to do its work. The only difference between it and the "unofficial" method is that it retrieves a binary encoded data block and processes that.
See these forum postings for more details I documented:
Official Gmail Notifier protocol documented
--Phil.
Well, no other "official" ones, but there's at least two for OS X and a number for Linuxy things.
If your platform of choice runs Python then you can use the Python Gmail binding project `libgmail` to write your own...
--Phil.
ObDisclosure: Yeah, of course I wrote it.
I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:
> all traffic must be tortured through a webmail interface
Most Gmail interaction doesn't rely on ordinary screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.
If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.
The upshot is that it's more reliable than "ordinary" screen-scraping.
--Phil.
P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.
I haven't seen this mentioned elsewhere in this story, so thought I'd mention it:
> They're just ordinary screen-scrapers
Most Gmail interaction doesn't rely on "ordinary" screen-scraping. Apart from the login sequence, the data is sent in mostly plain text which can be quite easily parsed, rather than extracting it from a fully formed HTML page.
If you have a Gmail account take a look at the source of the main frame--it's not HTML, the view itself is created on the fly.
The upshot is that it's more reliable than "ordinary" screen-scraping.
--Phil.
P.S. Oh, why not, ObGmailUtilityPlug: libgmail (http://libgmail.sf.net/) provides Python bindings to Gmail and demonstration utilities to provide POP3, SMTP and FTP (download) proxies.
> Earlier they were dumping anything matching *mail*.
:-)
> We discovered this, this morning by searching for qmail sites.
Funnily enough, I was searching for `libgmail` (my Python binding for Gmail access) when it stopped working. But it only forbid it when I tried searching for a specific version number "0.0.6", which I eventually generalised to "..." being banned.
Initially I was like "Crap, they could've just asked me to stop working on it..!".
> if you download a file from the Internet, the system would likely append a Originated-From-URL property
Software on Classic Mac OS did this years ago with the comment field--it was mighty handy.
> they are not suddenly going to grok the mysteries of sudo when switching to some other OS.
Under OS X this happens automatically, via a GUI so you don't need to know it's going via sudo. (A dialog is displayed saying something like "Application Foo is requesting something something...".
> I must admit that my wife and I have been good as parents, but not-so-good as spouses.
It's not possible to *be* good parents if you're not good spouses, kids need their parents to love each other first.
Glad to hear you're both working on it, your kids will thank you for it.
> I had no idea how it worked, either, but I looked it up :-)
Not exactly the easiest thing to Google for though...
> It's quite usable, but we're still adding features.
:-/
i.e. It's still quite possible to ensure it's *not* usable?
Adding features isn't always a gain...
> Guilty? What an odd question. Correction...What a meaningless question
I don't think that's entirely the case. The thought I haven't seen expressed elsewhere in this story is the cause of the guilt is the idea of settling for something "less Free" because it's easier in the short term.
If you think that, overall, Free Software is a Good Thing(TM) and in an ideal world would only use it, but instead use OS X because it's "close enough" to Free and works really well then there is a dis-connect between what you wish you could do & what you actually do. Hence, guilt about the operating system you use.
This contrasts with someone like RMS who would rather write something from scratch than go the "easy way" and use something that's not Free. It all depends on whether you consider there are more important things than just getting a job done.
RMS believes that Freedom is more important than just getting the job done (and is willing to pay the price), but many others think that getting the job done is more important than holding slavishly to Free Software principles.
And still others are pretty sure that Freedom is more important than just getting the job done, but really want to get the job done and do so using whatever is "easiest"--and these are the ones that feel guilty...
[Snip]
... I'm so *old* ... :-(
:-)
Nice 80s pop reference though...
> for suggesting they patent sticky bubblewrap
Funnily enough, apparently (according to the bubblewrap company's web site) bubble wrap was originally invented to be a wall-paper, so it probably started out sticky...
> Another solution is that I have some contacts (companies, usually a friend of mine is working there)
> I use to do some private work for, and they have no problem with me sitting at one of their unused desks.
Yeah, finding a deal like this is *great*--if infrequent. I'm fortunate enough to have access to an office (with a carpark outside "normal" work hours--when I tend to work) and internet access, rent free. Even more of a bonus the office leaser passes clients my way too...
> How about a new look altogether?
Not really necessary if you just use the "light" version--that way you can avoid all the crap "design" altogether.
Why has nobody else commented that the whole site is a rip off of news.google.com anyway? Where do people think the picture links come from?
> keeping multiple copies of Mozilla up for days eventually eats an incredible amount of memory.
In my experience keeping *one* copy of Mozilla open is enough to do that....
> This site doesn't strike me as being very different from Google News.
What I'm suprised about is that nobody has mentioned it *is* a rip-off of Google News:
e.g.:
"International versions of Google News available in:
Australia - Canada - France - Deutschland - India - Italia - New Zealand - Espana - U.K. - U.S."
-- <http://news.google.com/>
vs:
"All editions U.S. Canada U.K. Espana France Deutschland Italia India Australia New-Zealand"
-- <http://www.news-images.com/>