Allow use without creating a Google developer project about gmailctl HOT 8 CLOSED

I honestly don't know if that information should be secret or not. Anyhow I see the current approach having two advantages:

• I don't have to explain anyone what I'm doing with your data (in fact I have no access), because the project is yours, the credentials are yours, etc. No need to check or explain.
• I don't have to pay your bill. If my project is shared with the world, I'm pretty sure all API calls are billed to me, and I honestly don't wanna do that.

Makes sense?

from gmailctl.

The first makes sense at least from an appearance-of-proprietary perspective, but if I'm worried about it I can always replace your credentials file with my own. I don't know if this worry actually makes sense from a security perspective, because I don't know what data you have access to just from owning the product.

For the second, I'm surprised I can't find anybody else worrying about that for client-side applications. The free-tier limits seem high enough that I doubt you'd run into issues as long as everybody uses the application as intended, and you can decrease the per-user quotas to prevent hitting your per-application usage limits even with deliberate abuse.

from gmailctl.

Since I’m sure that 2. isn’t supposed to be a problem, I’ve asked this SO question in case the answer is more than “adjust the per-user quota and hope that nobody puts in the effort to DOS your project”.

from gmailctl.

The first makes sense at least from an appearance-of-proprietary perspective, but if I'm worried about it I can always replace your credentials file with my own. I don't know if this worry actually makes sense from a security perspective, because I don't know what data you have access to just from owning the product.

You're right on this.

For the second, I'm surprised I can't find anybody else worrying about that for client-side applications. The free-tier limits seem high enough that I doubt you'd run into issues as long as everybody uses the application as intended, and you can decrease the per-user quotas to prevent hitting your per-application usage limits even with deliberate abuse.

The problem is that I don't have a backend where I can store the credentials. All of that is in the client, so I can't prevent anyone from grabbing that and creating their own applications and using my quota. Not having a backend is also a feature for me, since I have nothing to maintain and worry about.

from gmailctl.

That makes sense, but if you limit the per-user quota to 5 quota units per second (enough to on average create or delete one filter per second, but with the 100-second burstiness allowed that would actually allow creation/deletion of 100 filters at a time. This would make it very difficult to actually burn all your quota, but not impossible.

from gmailctl.

The data in question – the OAUTH token – is password-equivalent for anything in scope, which means at minimum access to the filters. (I have not looked to see what else it may be requesting, I'm doing my due diligence before getting started here.)

It absolutely makes sense to ensure it is protected as well as the, eg, ssh config / keys, which is to demand some reasonable permissions, etc, for it. Documentation should match.

I offer nothing on the question of who would own the GCP project or whatever at this time.

obDisclaimer:
This comment is just me, not speaking for my employer. I have no meaningful knowledge of the systems in question beyond what any random developer would.

from gmailctl.

There are two types of tokens we're discussing. There's the user-specific kind, which should definitely be protected and gives access like you say, and the app-specific kind, which doesn't allow access to any particular Google account by itself.

The steps recommended for creating a project get you app-specific credentials, which you then use for user-specific credentials.

from gmailctl.

This issue is stale because it has been open for 30 days without activity.
This will be closed in 7 days, unless you add the 'lifecycle/keep-alive' label or comment.

from gmailctl.