Closed gauteh closed 4 years ago
Seems to have gone through.
Apearantly it is illegal to be named or describe something with gmail in it, even in the url / domain name. Will have to get a new name if not going to require all users to create their own API key.
On Sat, 06 Apr 2019 10:53:58 -0700, Gaute Hope notifications@github.com wrote:
Apearantly it is illegal to be named or describe something with gmail in it, even in the url / domain name. Will have to get a new name if not going to require all users to create their own API key.
What a lame choice to have to make :(. Thanks for keeping things going, and posting updates!
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/gauteh/gmailieer/issues/100#issuecomment-480524107Non-text part: text/html
new name: gmuch or glieer?
maybe just lieer
? smaller chance that google will have trouble with it and a little easier to say.
notgmail
Heh, can't contain the phrase gmail
or anything else google-ish.
Now we are lieer
!
And there was much rejoicing!
\o/
On Wed, 01 May 2019 00:33:47 -0700, Gaute Hope notifications@github.com wrote:
Now we are
lieer
!-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/gauteh/lieer/issues/100#issuecomment-488227456Non-text part: text/html
Next chapter in this story, and possibly last (not in a good way)... either I've somehow managed to trigger all their red lights or a lot of apps are going to be in trouble, especially the security check on $15.000 seems a bit stiff:
Dear Developer,
Thank you for your patience while we reviewed your project.
Please make sure your request satisfies the following information:
Scopes selection and justification
Your requested scope(s) must be as granular as possible (if your
requested scope goes beyond the usage needed, then we will either reject
your request or suggest a more applicable scope). You must provide a
detailed justification for your requested scope(s) as well as an
explanation for why a narrower scope would not be sufficient. Example:
my app will use https://www.googleapis.com/auth/calendar to show a
user's Google calendar data on the scheduling screen of my app, so that
users can manage their schedules through my app and sync the changes
with their Google calendar.
App demonstration video
You must provide a YouTube link to a video, in English, that fully
demonstrates the OAuth grant process by users and shows, in detail, the
usage of restricted/sensitive scopes within the app’s functionality for
each OAuth client belonging to the project. If your app requires
registration or features a local login, please whitelist/authorize our
test email account oauthtest222@gmail.com to enable us to validate your
app’s functionality through testing. OR if your project requires
prepared conditions, please provide us with the username and password of
a test account that is registered for your app. The video must clearly
show the app's details such as the app name, OAuth Client ID, etc. as
applicable. The demo video must show usage of sensitive and restricted
scopes on each OAuth client. Including the video along with the
verification request will speed up the approval process significantly.
We will not grant approval if you don't adequately explain scope usage
on each OAuth client ID. Additionally, if any of your OAuth clients, in
the project requesting verification, are not ready to be put into
production, we will not be able to complete our review and your request
will be rejected. We require that you separate your testing/development
and production projects. We will thoroughly test your apps.
Failure to satisfy/provide the preceding information might result in a
rejection of your request. To avoid this outcome, update the applicable
information in your request to meet our requirements.
Limited Use requirements
If your app uses restricted scopes, ensure your app's privacy policy complies
with the Limited Use section of the API policies. Your privacy policy will be
thoroughly reviewed by our team following the four elements of the Limited
Use requirements.
Security assessment
As your application is sending or has the ability to send Google user data
from a Restricted Scope to remote servers, then our verification process
requires that your app undergo a security assessment to demonstrate a minimum
level of capability in handling data securely and deleting user data upon
user request. Depending on the scope and complexity of your app, the cost for
the third-party assessment might vary from $15,000 to $75,000. We will
provide further information once your project has reached this stage of the
verification process. Until then, please do not pursue a security assessment
until you have received instructions from our team.
App types not applicable for verification
Apps for internal use only (single domain use) Apps for personal use
only Apps that are Gmail SMTP plug-ins for WordPress Apps that are in
development or staging/testing
If your application is one of the not applicable app types mentioned above,
please reply to this email confirming which app type so we can provide you
with the next steps.
You can find more information in the OAuth Application Verification FAQ
Hello, Googler here! Unfortunately these new policies around data protection are pretty sweeping. I've reached out to see if there is any distinction made for Open Source projects, and I'll let you know what I hear.
So, bad news. The Google APIs Terms of Service state:
Developer credentials may not be embedded in open source projects.
https://developers.google.com/terms/#b_confidential_matters
Which you seem to be doing here: https://github.com/gauteh/lieer/blob/5f96e82f05a7093d3259c1511ba0b62eedd2739a/lieer/remote.py#L27-L35
The best course of action is likely to remove the credentials from the project and have the users register and insert their own credentials. You can provide instructions in the README, and/or partially automate part of the process like GAM does here:
That is a pity 😕 thanks for checking. Is a Gsuite setup necessary?
It did not use to be too many steps required, but it will definitely make it harder for new users to get started.
ons. 29. mai 2019 kl. 02:29 skrev Eric Koleda notifications@github.com:
So, bad news. The Google APIs Terms of Service state:
Developer credentials may not be embedded in open source projects.
https://developers.google.com/terms/#b_confidential_matters
Which you seem to be doing here: https://github.com/gauteh/lieer/blob/5f96e82f05a7093d3259c1511ba0b62eedd2739a/lieer/remote.py#L27-L35
The best course of action is likely to remove the credentials from the project and have the users register and insert their own credentials. You can provide instructions in the README, and/or partially automate part of the process like GAM does here:
https://github.com/jay0lee/GAM/wiki#configure-gam
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/gauteh/lieer/issues/100?email_source=notifications&email_token=AAAN36ZMMZXYEZJ3MOPM3BLPXXE5TA5CNFSM4GTQIDR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWN2CZI#issuecomment-496738661, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAN365F3UYZ2EEQONOYNYTPXXE5TANCNFSM4GTQIDRQ .
No, any consumer (@gmail.com) account can register a Cloud Console project and get the credentials.
Yeah, it would be meaningless to go through all this without keeping the client keys secret.
I got a response from Google recently, after having explained the situation, that the request has been approved! Hopefully everything will be good now! I was open about having to include the client secrets in the open source code.
By Feb 19th google requires the API key to be approved. In order to do that an approved domain must be supplied (together with home page and privacy policy which must also be on the same domain). However, we use the local computer as domain when authorizing gmailieer to access an account.
Privacy policy is easy (except it cannot be on github since approved domain is the same) since only the user itself is storing the data.
Would be a pity to require all users to generate their own key. And also an unnecessary hassle and security liability to set up a domain/server which gmailiier must relay authorization through.