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

41–50 of 147 posts

Re: Gmail API

#41

Post by alooPotato »

aschwa1 wrote: post #26
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…

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.

Re: Gmail API

#43

Post by VogonWorkEthic »

aschwa1 wrote: post #26
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…

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.

Re: Gmail API

#44

Post by alex_duf »

malandrew wrote: post #40
bpodgursky wrote: post #6

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

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.

Re: Gmail API

#45

Post by ebbv »

bpodgursky wrote: post #6

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

Whether they drop support or not, clearly their idea here is to replace it.

Replacing globally supported open standards with proprietary APIs is one of the things people hated about Microsoft in the past.

Why does Google seem to get a pass from so many developers for this type of behavior? Or worse, get applauded for it?

If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way. Unless you don't care about anyone but yourself.

Re: Gmail API

#46

Post by steveklabnik »

bpodgursky wrote: post #6

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

It now says

> Note: The Gmail API should not be used to replace IMAP for full-fledged email client access. Instead, see IMAP and SMTP.

Note the NOT.

Re: Gmail API

#47

Post by dragonwriter »

ebbv wrote: post #45
bpodgursky wrote: post #6

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications. Edit: I'm going off of this sentence: >It will replace IMAP, a common but comp…

Whether they drop support or not, clearly their idea here is to replace it. Replacing globally supported open standards with proprietary APIs is one of the things people hated about Microsoft in the past. Why does Google seem to get a pass from so many developers for this type of behavior? Or worse, get applauded for it? If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilateral…

> Whether they drop support or not, clearly their idea here is to replace it.

Its clearly their idea to replace it for some use cases for which IMAP's design is completely unsuited. Beyond that seems to be speculation.

> If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way.

Actually, unilaterally creating your own API, getting some real use and experience with it, and refining it and submitting it for standardization is exactly the way that useful new standards usually get created. Attempts at creating standards not based on existing unilateral APIs often result in things that no one ever implements, like XHTML 2.

Re: Gmail API

#48

Post by xienze »

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 in the future.

Re: Gmail API

#49

Post by the-dude »

aschwa1 wrote: post #26
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…

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?

About 6 months ago I helped out a woman with some computer issues. She is/was a bit paranoid, coming out of an abusive relationship.

I didn't think much of it, until I noticed access to her Gmail from Japan I seem to recall ( we are in Western Europe ).

Streak was installed into her account.

I have no idea what someone can do who has access to the Streak account. I just removed the permissions.

Re: Gmail API

#50

Post by ossreality »

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…

Yeah, because IMAP is far more fine grained control.
Post reply on HN