Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gmail API

developers.google.com

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Gmail API

#51

Post by alooPotato »

ejain wrote: post #39
andybak wrote: post #27

Earlier quoted context omitted.

Yep. It would depend how granular it is. I'd like to only allow access by sender domain or something like that. However - how many people trust our email to small web hosting companies? How much better is that? For example - many of my clients use the mailbox provided by Webfaction who I'm sure are beyond reproach but do I trust them any more than I trust a well known SASS company that integrates using the GMail API?

Granularity is the key here. I run a small self-tracking service (zenobase.com), and would love to let my users pull in some "metadata" from their email (e.g. the number of messages in the inbox, or the number of messages sent by hour). But I don't want my users to trust me with unrestricted access to their email.

A meta data only permission would be cool. Access to from, to, cc, date, labels, etc for all mails but no access to the actual content would be good.

Re: Gmail API

#52

Post by icebraining »

ejain wrote: post #7

Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.

This seems great for building bridges from Google Apps' Gmail to internal applications, though, where there's no third-party to worry about.

Being able to replace my current IMAP client code - full of hacks to convert internal ids to Gmail ids and format conversion issues - into a couple of HTTP calls sounds great to me.

Re: Gmail API

#53

Post by zacharycohn »

VogonWorkEthic wrote: post #43
aschwa1 wrote: post #26

Earlier quoted context omitted.

How fine grained are the permissions? Can your snoozing app operate with a sufficiently restrictive set of permissions that you are prevented from reading my email?

Your email is the least creepy thing Streak has access to. There's also a feature that tells the user when an email they've sent has been read.

You mean "read receipts" which have been around for decades?

Re: Gmail API

#54

Post by iLoch »

alex_duf wrote: post #44
malandrew wrote: post #40

Earlier quoted context omitted.

TBH, I've never understood why more people didn't explore the multipart content type feature of email to extend email. It's typical to have plaintext and html in the same email, but why no JSON using a well defined and published JSON-schema.

I've seen an application in production using e-mails as a message broker. It worked pretty well.

Isn't there a lot more overhead with the headers? Neat idea though.

Re: Gmail API

#55

Post by mp3jeep01 »

dragonwriter wrote: post #38
mp3jeep01 wrote: post #23

If they can combine this ease of accessibility for developers with a security model on the end-user side, I think it can be a solid win. I'd love to see granularity in what the API can access, for example, TripIt may request something like "Grant access to emails from the domain travelocity.com, usairways.com, etc.," and I can know with confidence that they will not have access to the rest of my inbox.

It doesn't have that level of granularity, just four auth scopes: 1) Full access to the account 2) Do everything but permanent deletes of threads and messages 3) Read everything, but no write access 4) Create/read/update/delete drafts and send messages/drafts, but no access to anything else Finer-grained access (especially for reads, but there are some use cases for finer-grained sending controls, too) would be bette…

I immediately checked for that level of scope when they announced it, my post was merely a "this would be pretty amazing for security conscious end-users" not "this part of the API is cool" -- a wishlist item have you.

Re: Gmail API

#56

Post by pud »

alooPotato wrote: post #17

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

If anyone wants to snooze email without auth'ing your Gmail account, here's one I built in 2008 that's still going strong.

http://hitmelater.com/

It costs $30/yr for the high-end service but send me a note and I'll give you a link to signup for free.

Re: Gmail API

#57

Post by iLoch »

xienze wrote: post #48

I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes , basically apps can do a combination of a) have full control, b) read everything, c) do everything but delete emails, or d) read/write/send drafts. Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents…

While I somewhat agree with you, it's not as though these problems didn't already exist with IMAP. I think a better way of looking at it is this is the first step in removing the password from 3rd party access. Maybe at some point in the future they'll add more fine-grained access, but for now removing the credentials from the process seems like a good first step.

Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.

HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.

Re: Gmail API

#58

Post by joellarsson »

xienze wrote: post #48

I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes , basically apps can do a combination of a) have full control, b) read everything, c) do everything but delete emails, or d) read/write/send drafts. Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents…

Yep, was hoping for more fine-grained control for reading, not just 'read everything'

Re: Gmail API

#59

Post by JohnBooty »

alooPotato wrote: post #17

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

  > I'm surprised they don't recommend using this API to
  > build full email clients. I fully expected that to be
  > one of the core use cases.
I didn't see today's API announcement, but I'd be surprised if they wanted to encourage that. Similar to how Twitter doesn't want you to write full-fledged Twitter clients.

If we write full-fledged Gmail clients, won't they miss out on the ad revenue? Maybe not; maybe they're just glad to tie us to their service and data-mine our emails even if we're not using Google's web client.

Still, I'd be scared of basing a lot of work around this API, since they have a history of deprecating and discontinuing things in the past...

Re: Gmail API

#60

Post by aschwa1 »

alooPotato wrote: post #41
aschwa1 wrote: post #26

Earlier quoted context omitted.

How fine grained are the permissions? Can your snoozing app operate with a sufficiently restrictive set of permissions that you are prevented from reading my email?

Unfortunately to snooze an email we need to be able to read the message and reinsert it. That requires full read/write permission. If we instead just replied to the thread, we could probably get away with just read permissions.

Is it possible to have full read/write permission but no communication with the outside world?

Presumably, this would involve denying the ability to send emails and denying various forms of network access.

Post reply on HN