I see this as a double-edged sword.<p>1. It makes sense that Google wants to stop apps from abusing their storage platform. There are a lot of projects that abuse the data storage capacity. There was that one app that converted files to Base64 or something and was storing files that way as email text. Obviously not cool. However, Google needs to be explicitly clear on expectations and throw some people-power behind the reviews, since many are being denied by (seemingly) some automated process.<p>2. The second issue I see is that it will encourage less secure methods of using these apps.
SMSBackup+ in particular is discussing the possibility of moving to "App Passwords" to bypass 2FA and provide the app access it needs to upload and store the data.
Issue being, App Passwords are incredibly fragile, they provide near-unfettered access to IMAP and other account features with no auditing.
Caveat emptor and all that.<p>I think SMSBackup+, specifically, has a bit of a gray line as SMS messages can technically be sent via email and vice versa, (among other similarities). It's a shame that Google is becoming so draconian about their data storage uses.
> <i>Google's OAuth APIs have been around for years as a way for apps to get access to and control your Google data. A third-party email app, for instance, would want access to your Gmail account and the ability to send, read, and delete emails so it could control everything remotely. An IM app might just want access to your contacts and profile picture. For years this was purely an agreement between the user and the developer—the app would say what it wanted access to, and the user could deny or allow it.</i><p>Yeah, until the Cambridge Analytica scandal revealed that agreements like this aren't sufficient to protect user data. I think Google's making the only acceptable tradeoff here.
I've been expecting this. Google's attempts to get me to turn off "less secure app access" have grown increasingly obnoxious over the last couple of years. A few months ago they went so far as to send me a "prevented login from suspicious device" alert after a getmail run. Time to leave. If I can't download it with POP or IMAP, then it's not email.
As a former user of SMSBackup+, at a certain point it did seem like I was putting a lot of trust into a 3rd party to have full access to both my text messages and my email. So I can kind of see how it's a risk, but it seems sad to just shut it all down.
I wonder how long it'll take for scraping to make a comeback. I feel like we've become used to APIs being the only integration options. When API restrictions become too burdensome, however, I expect people to recall that other access options exist.
There will always be misuse of open APIs by third parties, and the company itself will be blamed in the PR fallout. After Google and Facebook I expect more services to follow suit, which is a shame but understandable.
You shouldn't be building anything that relies on a google service unless<p>A) Google would die without that service<p>B) You're just fucking around and what your building could burn to the ground without consequence<p><a href="https://killedbygoogle.com/" rel="nofollow">https://killedbygoogle.com/</a> has 143 services listed.
Slightly off topic, but Google is also discontinuing Google photos and google drive syncing feature. This is currently the only way to access your Google photos with Rclone.
how long until Google says "hey, actually, it would be cool if users used gmail.com with all the ads instead of some stupid external email clients. Let's disable POP3/IMAP/SMTP for non-business users. Oh, and let's disallow mail redirection too, so they won't even think about running away".
The email client I use - Nine - is on the list. I can't see how an email client is a problem except they want to push Googles client. Hope Nine gets fixed.
Does anyone know if this will have any impact on Gmail backup tools such as:<p><a href="https://github.com/jay0lee/got-your-back" rel="nofollow">https://github.com/jay0lee/got-your-back</a><p>Or the long term sustainability of such projects?<p>I've found gmail's own data export tools to not work <i>at all</i> for any inbox of a considerable size (100gb+) - so third party tools are the only way to actually back up / migrate email data.<p>Without such tooling, relying on Gmail would be a huge mistake for anything remotely important.
They could have gone another route than imposing a bogus security audit and have the devs pay for it. I did an integration with QuickBooks a while back, and they paid/conducted the security audit themselves.<p>Google could have added a contract that would plainly state that any data needs to be wiped out etc and enforce that contract if anything is fishy.<p>Google could have created a process to clearly inform the dev that the user wants to delete google related data and impose deadlines on it.<p>Those are simple, but I think Google was just lazy and listened to a bunch of lawyers instead of thinking out the box.<p>I have an app that allows to link your email account thru Nylas (with google), now I would have to pay the security audit? No way. I told my customers that any google account that is not a GSuite which whitelisted the app (most of my customers corporate) that they might have warning dialog when connecting their gmail account. There is a limit of 100 linked account without verification ;(
I invested a lot of time trying to publish a Gmail add-on and failed miserably [1][4] because of this lockdown. Here are some notes that may be of interest:<p>The lock down is for the Gmail API especially for API that allows reading user’s email.<p>Any App has to get OAuth 2 token to get access to the API. The user has to explicitly provide access . The approval screen will show each type of access the app is asking. See an example here [2]<p>In addition, Google will send an email to the user immediately after the approval, with a scary warning.<p>The user can withdraw the app access anytime, from Google account page.<p>The data access concern Google is projecting is that the APP can read user’s email (Remember, the app can read only those who explicitly gave the app the permission to read their email).
The “lockdown” is a direct reply to the media frenzy that “Gmail allows any app to read anyone's email” [5]. Gmail does not allow reading email automatically. The user has to allow explicitly.<p>In order to get Gmail API access, the app has to go through a Google review process where Google will ask the developer to justify each type of API access the app is requesting in addition to explaining (with videos) what the app does and how the API is used.
The first level of approval process demands you to publish a comprehensive privacy policy and in my experience, anything like “marketing” or “research” in the privacy policy will get you disapproval. [3]<p>Such a strict approval process is good and fine, and well appreciated till this point. The issue comes for the last part of the approval process.<p>Those Apps that requires read access to Gmail has to get themselves assessed, through Google appointed third party security assessors paying $75000 USD annually.<p>This is the main blocker.<p>This will kick out any app or add-on that small scale developers create. It will block new entrants. What remains will be established apps that are generating huge revenue to justify the “protection money”. They get an added advantage that there will no longer be any new competition.<p>It is not the restrictions, or the intention to protect the end user that is in question but the “first save my back” attitude in the process, and the bait and switch - that is the problem. In summary it happened like this:<p>Hey developers come, build apps using our platform, show your innovation!
Developers start investing time and effort on the platform, approval process is smooth and fare
Somewhere else, someone misuses someone’s system, huge media attention
Sorry developers, you go to Mr X , keep paying him and we will keep you here. If not, trash your product and go away.<p>[1] <a href="https://medium.com/@prasanthmj/lessons-learned-developing-an-app-using-google-apis-dff3f7b91be0" rel="nofollow">https://medium.com/@prasanthmj/lessons-learned-developing-an...</a><p>[2] <a href="https://www.youtube.com/watch?v=GGXFQUmZTf4" rel="nofollow">https://www.youtube.com/watch?v=GGXFQUmZTf4</a><p>[3] <a href="https://blog.gsmart.in/applying-for-g-suite-api-approvals/" rel="nofollow">https://blog.gsmart.in/applying-for-g-suite-api-approvals/</a><p>[4] <a href="https://medium.com/@prasanthmj/google-restricted-api-scopes-require-75k-yearly-fees-a23cad053a4c" rel="nofollow">https://medium.com/@prasanthmj/google-restricted-api-scopes-...</a><p>[5] <a href="https://www.wsj.com/articles/techs-dirty-secret-the-app-developers-sifting-through-your-gmail-1530544442" rel="nofollow">https://www.wsj.com/articles/techs-dirty-secret-the-app-deve...</a>
The changes they've been doing is somewhat annoying. It killed probably 75% of my IFTTT and now it is going to kill my SMS backup solution (SMSBackup+) unless the developer changes a bunch of stuff. Sure I can backup other ways but I like having it in my gmail, I've been saving SMS backup there since the iPhone 3gs.<p>I get why they are doing it but blah, now I have to find solutions for everything again.
The article mentions this is going to affect Drive soon too, but couldn't find any info about this on Google announcement. Anybody has any info on this?
So... if every player (and Google in particular) start locking their platform, how could this not constitute ground for antitrust trial ?<p>Even explorer was less tightly integrated 25 years ago...