sms-backup-plus
sms-backup-plus copied to clipboard
jberkel
G Suite notice about SMS Backup+ becoming restricted
[Note added by @kurahaupo, 2020-07-08]
- This thread does have useful information but it is somewhat buried because the thread is so long. Please read through it before adding more comments. If you're just looking for a quick fix, there's an explanation at the top of #972.
- Although this report dates from June 2019, in July 2020 G-suite users are being notified (again) that new installations of SMS Backup+ won't get Gmail sensitive scope access; it's the same problem, just different timing.
- This policy change should not affect access to Calendars. If you have a problem with calendars, raise a separate ticket. (Note: do not enable
Connect your Gmail account (unsupported), as that's only for Gmail, not for Calendars.)- The changes to sensitive scope access are explained at https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes A major use-case is being able to read SMS & MMS alongside email & hangouts messages, and that ought to be sufficient justification under term 3 of the rules "Applications that enhance the email experience for productivity purposes", but it's hard to argue that case when the name says "Backup".
[Original report follows]
I received the attached email from Google that your app will become restricted on 7/8. Thought you'd like to know. SMS Backup.pdf
A similar email is being sent to ordinary users of Gmail. This one refers to a restriction commencing July 15, 2019. SMS+ Backup.pdf
I had the same experience as @MarkMessinger. Very worried that we'll lose THE best SMS backup app around.
Same - July 15 will stop working if "unable to meet the deadline to comply with our updated data policy requirements"
Same email.
Hi,
Although you don’t need to do anything, we wanted to let you know that the following apps may no longer be able to access some data in your Google Account, including your Gmail content. If these apps are unable to meet the deadline to comply with our updated data policy requirements, they'll lose access to your Account starting July 15th, 2019.
SMS Backup+ We are making this change as part of ongoing efforts to make sure your data is protected and private.
You can always view, manage and remove apps you’ve given access to your account by visiting your Google Account.
Thanks, The Google Accounts team
It seems that the app must pass a verification process to continue accessing GMail accounts the way it does.
The Google API scopes to create and read GMail messages (used by SMS Backup+ to backup and restore SMS messages) are now restricted scopes, and apps that use them need to be audited by Google to verify that they comply with the OAuth security policies and to verify that they do not make an ilegitimate use of that APIs.
And for the app to be verified, the developer must apply for that verification. There are limit dates for that too. The too-late deadline is July 15th, when the app will loose access to that APIs if nothing is done.
About restricted API scopes: https://developers.google.com/terms/api-services-user-data-policy#additional-requirements-for-specific-api-scopes
About the verification process: https://support.google.com/cloud/answer/9110914#restricted-scopes
We need the developer urgently.
Please, do not clutter this thread by repeating the same information a hundred times. We all have received the same message today, Jun 25th, so there is no need to post it more than once nor repeating ”me too” once and again.
Let's try to get a solution, not to make a whinning cry of this.
It's worth pointing out that, while it will be a bit obnoxious, you don't need to use the default OAuth-based mechanism to back up your texts. As stated in the docs here you can configure the app to use plain old vanilla IMAP.
It's worth pointing out that, while it will be a bit obnoxious, you don't need to use the default OAuth-based mechanism to back up your texts. As stated in the docs here you can configure the app to use plain old vanilla IMAP.
We can keep backing up to gmail, just through IMAP? Would it still track the same SMS label that we've applied to the texts?
I think using GMail IMAP is subject to the same restrictions that require the aforementioned verification process.
Asides, using another IMAP server is a no go for me. This app is not only a backup utility, it also allows to search for specific SMSs using GMail and search for calls you issued using Google Calendar. It's not just a backup, it's much more when combined with a Google account.
The fact is that I think the app already complies with the OAuth security requirements claimed by the Google verification process. So we only need the developer to apply the app for that verification process. I have just emailed him asking for his help. I hope he has a bit of time and interest in keeping his awesome creature alive.
It's worth pointing out that, while it will be a bit obnoxious, you don't need to use the default OAuth-based mechanism to back up your texts. As stated in the docs here you can configure the app to use plain old vanilla IMAP.
Yes, we can fallback to vanilla IMAP. And no, Gmail won't let it happen. According to experience from K-9 mail, Gmail will do its best to prevent you access IMAP even with "less secure apps ON" or "2-factor-authentication OFF". (See https://github.com/k9mail/k-9/issues/655)
Hello everyone. I'm sorry about this situation, SMS Backup+ will no longer have access to Gmail, mainly because it's not an email reading app.
I applied for an exception but it was declined, as expected. Vanilla IMAP might work, but for how long I wonder. And it's very tricky to set up for a casual user. Unfortunately the Android platform is getting more and more closed.
I'm not sure what to do at this point, either remove the app from the store or release a new version which removes the automatic account setup, since that is broken / will be broken soon.
Off topic: I took the opportunity to hit Donate in the app, thanks for years of great software @jberkel & the other committers.
Is it possible to use some kind of personal developer key (assuming such a thing exists)?
I was able to whitelist the app in my Google Apps domain. Do you think that will eventually stop working as well?
Oh no! This is an unwelcomed shock to me. Thank you @jberkel for your wonderful app. Like so many others, I am not happy about Google's decision. SMS Backup+ has proved invaluable to me over many years. Please, please provide an alternative prior to 15 July 2019 if possible. Ho hum. Google (along with Apple and Microsoft) are controlling too much (IMHO). Please let us know if you are able to provide another app which Google deem acceptable. Thank you.
@jberkel Great work on the app. It has served us all so well for so long. Keep up the great work!!
Forgive my ignorance, but what will happen to my backup of messages already on my google account?
What will happen to my backup of messages already on my google account?
Probably nothing. They're uploaded and currently indistinguishable (from Google's perspective) from regular email messages, save for the unique label if you used it.
So does that mean, that the app cannot save sms back to gmail anymore? Or just restore them from there?
Im perfectly fine, if the app can just copy them to gmail, that is why i use this application, not for restore.
You will have to go to advance setting SMS Backup+ then go into customize imap and set the imap.gmail.com:993 and use you email as user ID and your password. Make sure the authinication is set to clear text and security is tls.
After that go to a PC and login to gmail, in the right hand corner click the cog then setting then goto the tab "forward and pop/imap". Under the imap access change it to enable.
Now go to you gmail account settings on the left side click security. Scroll down to less secure settings and turn it on.
Now you should be able to continue to use the app. It is just not as secure.
Google will probably not close this method down anytime soon to many developers and admins you this method for logs
I'm not sure what to do at this point, either remove the app from the store or release a new version which removes the automatic account setup, since that is broken / will be broken soon.
Personally, I'm happy to keep using this app via IMAP(with gmail or any other IMAP service), so I hope you don't remove it :)
Silly question perhaps but could you fork something open like Thunderbird and add in the and backup feature as a feature of that?
I also have made a donation. Thanks very much. It was a great service while it lasted.
Oh, that's so sad. It was the best SMS backup app. Will there be any option to backup to somewhere else, if Gmail doesn't work?
but could you fork something open like Thunderbird and add in the and backup feature as a feature of that?
Was thinking the same thing! Happy to contribute to the effort as well.
Many thanks @jberkel and anyone else that has helped for years of really great service.
For wich reason your application was denied, @jberkel? Was that finally, or are there any thing d for could change or provide to them to keep the app working?
I described situation to https://news.ycombinator.com/item?id=20282361 Please upvote it and/or comment.
There is a high chance we might get it higher to google echelons this way and get the exemption.
@jberkel Sorry to hear what's happening. Let not Google's policies discourage you. Your app is needed, and whether sync is done to gmail or other services is kind of secondary.
May I suggest that the first course of action would be the possibility to do a "full export" to other imap/services. Or is it already somehow implemented ?
Thanks
Hello everyone. I'm sorry about this situation, SMS Backup+ will no longer have access to Gmail, mainly because it's not an email reading app.
I applied for an exception but it was declined, as expected. Vanilla IMAP might work, but for how long I wonder. And it's very tricky to set up for a casual user. Unfortunately the Android platform is getting more and more closed.
I'm not sure what to do at this point, either remove the app from the store or release a new version which removes the automatic account setup, since that is broken / will be broken soon.
@jberkel thanks for updating us all.
Just to clarify, would the change also impact the syncing of the call log to Google Calendar, or does the verification requirement not affect this functionality? If the latter, I'd appreciate the app remaining in the Play Store even in abbreviated form as both my wife and I rely on the Google Calendar call logs.
This is the second app that I use which has lost the gmail connectivity. I assumed the previous app developer (Gnotes) had chosen not to go through the hoops but now I wonder. A real shame. I have donated too in the hope that there can be an alternative solution.
Hello everyone. I'm sorry about this situation, SMS Backup+ will no longer have access to Gmail, mainly because it's not an email reading app.
I applied for an exception but it was declined, as expected. Vanilla IMAP might work, but for how long I wonder. And it's very tricky to set up for a casual user. Unfortunately the Android platform is getting more and more closed.
I'm not sure what to do at this point, either remove the app from the store or release a new version which removes the automatic account setup, since that is broken / will be broken soon.
First of all, thanks a lot for your efforts.
Please, do not remove any features by now. Some of us use your app not only for backup purposes, but also for search and logging purposes. Searching SMS messages in GMail and looking for calls in the Google Calendar are great additional features that your app provides. And as long as I understand, Google should not ban your access to GMail using pure IMAP protocol, neither the access to the Google Calendar API, only the GMail API should be restricted.
A question for you, @jberkel: Could the Google Calendar entries be managed using pure IMAP protocol? Are they, currently? If so, by setting "Less secure apps" access in our Google accounts, we could get rid of the entire Google API and the automatic account setup.
By the way, could you please provide a Google email address where I can politely address a good reason not to ban SMS Backup+ access to the GMail API? Better provide it in private, to avoid cluttering them with complaints from ranting people.
@malversan - unfortunately, the IMAP protocol is purely for syncing emails, so it wouldn't be possible to sync calendar entries using that :(
(For more info: https://support.office.com/en-us/article/sync-basics-what-you-can-and-cannot-sync-5537d587-4930-4ac2-b044-3568509b1294)
@malversan - unfortunately, the IMAP protocol is purely for syncing emails, so it wouldn't be possible to sync calendar entries using that :( (For more info: https://support.office.com/en-us/article/sync-basics-what-you-can-and-cannot-sync-5537d587-4930-4ac2-b044-3568509b1294)
@jamgregory, as long as I can see that link only refers to Outlook client syncronization, so it does not answer the question I asked.
I have discovered that Google Calendar also supports being managed using the CalDAV protocol, but unfortunately I am afraid it does not allow to get rid of the OAuth credentials setup. https://developers.google.com/calendar/caldav/v2/guide
Some apps already use it: http://www.ubuntubuzz.com/2017/07/how-to-setup-thunderbird-for-google-calendar-caldav-read-write-access.html
But I cannot foresee the impact that using CalDAV protocol would have in the app usability and workload.
Just throwing out an idea here. If the app were to include some very basic functionality that allowed you to browse the previously backed up SMS/call records in your Gmail account, would that perhaps qualify the app for the exception as an "email reading app"?
Just throwing out an idea here. If the app were to include some very basic functionality that allowed you to browse the previously backed up SMS/call records in your Gmail account, would that perhaps qualify the app for the exception as an "email reading app"?
That is a pretty good idea. Maybe making statistics with the inbound/outbound call times and SMS messages sent/received.
Altough I suppose that the developer would better accept solutions that do not imply a heavy workload. Anybody here could implement something like that? All in all, the app is open source so the sources are public.
I have just posted an issue in the Google issue tracker, under the GMail API category, exposing why restricting too much the access to the Google APIs for security reasons can paradoxically lead to the Google accounts being less and less secure. I also sent the same message to "[email protected]".
https://issuetracker.google.com/issues/136079176
Of course I use the SMS Backup+ app as an example to defend the argument, so maybe it could lead to someone reconsidering the ban of this app from the GMail API. I do not expect great results from that "political" via, but it is worth trying.
Anyone who cares about this product, make your voice heard HERE: https://issuetracker.google.com/issues/136079176
Thanks, @malversan, for getting the ball rolling. If we can do any more to salvage this amazing app, let us know!!!
Hi,
Like everyone else, I'm enormously grateful for the many years of hard work you've put into such an excellent App, though I'm infinitely aggravated at Google since this is the second of my top two utilities they've killed, or announced they're killing on the Android operating system in the last 30 days! Both of the Apps I use many times HOURLY and both have either increased my productivity multi-fold, or saved me countless times, as is the case of your App, either legally, or from a he-said, she-said debate, or from just having a chronological history of my life since 90% of my communication is via text messaging. In the very least your App has enabled me to reconstruct events via the timeline inherent in text messages, which up until now were safely protected in Gmail, which I also backup frequently. I've been self-employed as a computer consultant for 30 years and the ability to go back YEARS and pull up often valuable information has been priceless and has prevented several liability issues because I had in time-stamped digital format, saved by SMSBackup+, a record of what someone said. So for Google to kill your App by fixing something that "ain't" broken and CONSTANTLY dinking with products that work just fine as is, is REALLY about to drive me over the edge, or more specifically, away from technology altogether! (this is by no means the first time they've killed a great product, with Picasa being one that to this DAY I've never been able to find an equal to). That's a big statement coming from someone who has made a ton of money over 30 years in this industry. But the industry continues to be so fragmented, and in such a perpetual state of change, often just for the sake of change, that I'm rethinking whether I want to continue investing a rapidly increasing portion of my time RE-DOING something that was working just fine as it was. It's funny that 25 years ago I figured that the time would come when my services would no longer be needed because computers would be so easy to operate and EVERYONE would know how to use them. In fact, it's gotten WORSE! The average user still can't format a letter in MS Word, or use even 2% of the potential a computer has, yet they keep buying new ones because they're forced to by the industry.
Like the others, I've used your App since you introduced it, and as far as I know, there IS no equal. So where does that leave us users (not pointing at you of course)? We're all going to end up investing vast amounts of time trying to create a poor-at-best workaround for what is currently a flawless system. I could ramble on forever about how aggravated I am at the first program Google just killed, which I hardly go 10 minutes without using, and now they've hit my second of two priceless Apps, SMSBackup+, and NEITHER have a solution as far as I know. How many years has it been since they killed Picasa and again, there's STILL no viable alternative. Throw in the Google+ fiasco, which I knew from day one was a loser, NEVER used, though the attempt was made to force me to use it, and it makes me wonder who's driving the boat at Google?
OK, complaining over. But I do have one hopefully simple question. Like I read someone else say, ALL I need from SMSBackup+ is to BACKUP to Gmail, so I can do searches and of course HAVE a backup. I will NEVER need to restore from Gmail, so will your App still be able to do a one-way backup to Gmail, or is that part of what's being killed?
Thanks again for all you've done for how many ever years since you wrote your MOST excellent App. It has again been priceless to me and I HOPE that the backup function will NOT go away. If it does, I'm still grateful to you, but even more aggravated with Google. With all of my spare time after finding workarounds for the loss of my most key apps day after day, I plan to write them a letter expressing my dissatisfaction with their fixing things that aren't broken. There are risks with EVERYTHING online that are NEVER going away, so to try and fix what they consider a risk, I have to wonder how many times has that hole been breached that makes it worth them investing their time and money to fix it, plus crippling thousands, if not millions of the people that actually USE the software they're killing?
On a personal level though, sincerely, thank you and continued success, Jay...
On Tue, Jun 25, 2019 at 6:25 PM Jan Berkel [email protected] wrote:
Hello everyone. I'm sorry about this situation, SMS Backup+ will no longer have access to Gmail, mainly because it's not an email reading app.
I applied for an exception but it was declined, as expected. Vanilla IMAP might work, but for how long I wonder. And it's very tricky to set up for a casual user. Unfortunately the Android platform is getting more and more closed.
I'm not sure what to do at this point, either remove the app from the store or release a new version which removes the automatic account setup, since that is broken / will be broken soon.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jberkel/sms-backup-plus/issues/959?email_source=notifications&email_token=AJMQPABOOZL4RNNAJTTY4NTP4KLMVA5CNFSM4HYI7LT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRYUCI#issuecomment-505645577, or mute the thread https://github.com/notifications/unsubscribe-auth/AJMQPADK7GHBL544Y2NTT4TP4KLMVANCNFSM4HYI7LTQ .
Anyone who cares about this product, make your voice heard HERE: https://issuetracker.google.com/issues/136079176
What the heck...? That was NOT the intended strategy, @arnaldop. What I subtly tried to do was to present the indiscriminated API restrictions as a potential threat for Google by forcing users to abandon cautions and good security practices. And by putting the SMS Backup+ case as an example maybe they would rethink about shutting down its access to the GMail API.
But it seems the subtlety is not an extended skill around here. Now you have converted that issue report in a joke, with tenths of messages saying they love this app, thus completely revealing the intention. Even worse, now it clearly appears as a coordinated plot, something that was not. That issue report is not an issue report anymore, it has become the complaint of a bunch of spammers about the problems of a third-party app that Google does not care about. So the tracker administrators will probably delete the entire post without reading past the third irrelevant message of the tenths you have written. You all ruined the attempt to convince Google of something THEY care about.
Understand this: Nobody at Google cares a damn about you liking or needing this app. That was definitely NOT the idea. You can only convince someone with issues that concern HIM, NOT YOU.
By the way, @JKS258, I can only congratulate you for completely ruining any possibility of Google gaining sympathy for this app. Do you know the meaning of politics, diplomacy, or even intelligence? What is all that shit you wrote there about Picasa and spaceships? In which universe do you believe that it is a good strategy to attack frontally the one you want to obtain something from? That is not a shitty forum for you to rant, it is the Google official products issue tracker, and the idea was to gain Google sympathy and confidence on the security of SMS Backup+. Now your rants and not-so-subtile threats against Google have assured that nobody will take seriously any argument in that report. Worse than that, you exposed all that unrelated and inappropiate comments talking as if you were the developer of the app, so you have also assured 100% that Google will never listen to him either. Congratulations, heartly.
Definitely I must learn to avoid trusting in people´s intelligence.
First many thanks for an app used for many many years.
Is it possible for the app to upload to "another" imap server to record sms and call log?. Could caldav be used with say NextCloud for calendar content?
I hope there is a rethink over this decision.
Honestly any political strategy that is transparently stated on a public forum (which Googlers will probably find pretty quickly, given that [a] they work on, you know, search and [b] you included a link directly to this project) probably isn't going to work anyways. I've always been under the impression that part of any effective political strategy is to keep your cards close to your chest. At this point, you might as well just keep telling them directly that they're being [SILLY COWS] for refusing to allow this app.
@malversan ignoring the potential validity of your argument, the hostility is unnecessary.
@jpellman, finding this forum does not invalidate anything, I expected it to happen and my argument would still be completely valid. What invalidates the entire thing it is to convert that issue report in a spamming circus about a problem that Google just does not care at all.
You have to understand that any attempt goes through talking about things they care, not about what you care.
(And of course insulting them never helps to attract their favorable attention, that should be evident for everyone)
@weaversam8, the hostility comes from the fact that I vainly spent a certain amount of time to carefully write that report to accomplish the goal, thinking that I was surrounded by intelligent adults who knew how to do things right. Believe me I do not care about you understanding it or not. If you don't know what an issue tracker is (and all who posted there clearly don't), you simply should not have posted anything there. Period.
In fact there is still people posting love cards in the issue tracker right now. I bet my head that most of them have not even read the report I wrote and simply don´t care what it is about. They just think that´s Twitter. To be honest, I can only think they are stupid and can´t distinguish where and when to do each thing.
To all on this thread, please be aware that every message is sent to all 35 active participants as well as all 172 watchers. I believe we've all made it clear that the issue exists and many have said their piece. @jberkel may choose to lock the thread if the hostile communications continue.
For the sake of keeping items on task, please refrain from adding anything additional unless it's precisely related to resolving the issue; either code suggestions or documentation (from Google or other affected applications) indicating a workaround.
Long time SMS Backup+ user. Admittedly I haven't reviewed this app's source but I don't suspect writing call logs to the Calendar will be affected. I believe this app uses the Android calendar provider to write directly to the user's selected calendar on their Android device, rather than calling out to the Google API (https://www.googleapis.com/auth/calendar). Even if it did call the Google API, per Google's OATH API Verification FAQ[1] the restricted scopes are only GMail related (https://www.googleapis.com/auth/gmail*).
Suggest the following way forward, in parallel:
-
Author documents meeting Limited Use criteria (see Google FAQ) and applies for a "restricted scope app verification". Author requests waiver of the security assessment ($15K+) or convinces a third-party assessor to complete the assessment without charge. EDIT: This may be an issue. One app type not permitted to restricted scopes are those that "store or backup data other than email messages in Gmail."
-
We start working on a branch that guides users through setting up GMail backups with IMAP. This will require manually generating an "App Password" [2] (avoids 2FA issues). Looks like Google treats labels as folders over IMAP [3] so that should still be possible.
Thoughts?
[1] https://support.google.com/cloud/answer/9110914#restricted-scopes [2] https://support.google.com/accounts/answer/185833?hl=en [3] https://developers.google.com/gmail/imap/imap-extensions
I think your second point is the only direction at this moment. The solution can be to separate the Calendar API access (which is not going to be banned) from the GMail API access, and then use the IMAP protocol to access GMail, as you say. That would require some development work to change a bit how the app works internally, but hopefully not a lot.
The first way you expose is missing the point that the security verification (I´m afraid) has not been denied for technical security concerns, but because it is not clear for Google what has to do with the user emails an app that is not an email app. By reading their verification process requirements, I think they have not bothered in analyzing the app security (the app already complied with XOAuth2 security, and I think we all know that it doesn´t resend any data to any obscure external storage). They simply have looked what the app is for, and then denied the use of the API restricted scope for that purpose. That light and insufficient evaluation is Google´s standard and automated way of doing things. An exceptional treatment should be required to get the app unbanned from the GMail API (and that was I was trying to get).
P.S.: I could be wrong, but I think that $15K+ security assesment is only required by Google for server infrastructures that make use of the Google APIs. An Android app is a simple client application running in an environment already secured by Google (Android), so that shouldn't apply in this case. Otherwise any developer making apps that use any sensitive Google API should be able to afford that expensive audit, and that´s clearly irrealistic.
Maybe pinging the Googlers who actually have enough interest to star this project will help the ticket @malversan opened gain traction. That seems a reasonable strategy to me.
Hey @kcc, @sio4, @kevincox, @smike, @kynan :
Suggest the following way forward, in parallel:
- Author documents meeting Limited Use criteria (see Google FAQ) and applies for a "restricted scope app verification". Author requests waiver of the security assessment ($15K+) or convinces a third-party assessor to complete the assessment without charge. EDIT: This may be an issue. One app type not permitted to restricted scopes are those that "store or backup data other than email messages in Gmail."
I think a good case for this is to emphasize the fact that there's a very blurry line between SMS and email, insofar that it's possible to send emails that get delivered as SMS [1], among other similarities.
However, I doubt greatly that Google will relent on the judgement, as @jberkel relayed earlier: I applied for an exception but it was declined, as expected. There is no appeal process, from what I've seen.
- We start working on a branch that guides users through setting up GMail backups with IMAP. This will require manually generating an "App Password" [2] (avoids 2FA issues). Looks like Google treats labels as folders over IMAP [3] so that should still be possible.
I utilize mutt for email, connected via IMAP to my account, and it works exactly as @tvh2k described.
Labels are folders, the App Password allows for connection aside from 2FA.
The largest issue I see is the actual documentation of this process, as with all things Google, if they don't want you doing it, you're probably going to have a hard time finding it.
For the sake of completeness: here's the general guide for creating an app password for IMAP which I've used successfully in the past [2]:
- Log into Gmail
- Click on your photo in the top right corner
- Click on the button “My Account“
- In the left menu bar click on “Sign into Google“
- Under “Password & sign-in method” (first block on the right side) click on “App passwords“
- You are required to login again
- From the drop down list “Select App” select the option “Mail“
- From the drop down list “Select Device” select the option “Other (Custom name)“
- Enter a name for the service, for example “SMSBackup+“
- Click the button “Generate“
- The application specific password is generated, write it down in a safe place as it will only be displayed once
Of course, this doesn't solve the calendar issue, but presumably something similar can be done for CalDav.
[1] https://www.digitaltrends.com/mobile/how-to-send-a-text-from-your-email-account/ [2] http://nidkil.me/2018/01/18/setting-up-mutt-to-send-mail-using-gmail-with-2fa-set/
Hi all,
I followed the instructions above switched to IMAP. It appears that both SMS and Call logs are being backed up without any issues. And the calls are finding their way to the calendar too.
I raise venture capital for startups and early stage businesses. I've made my donation through the google store, but it appears that this could use some funding (1) to get over this hurdle, (2) prevent it from happening again, and finally (3) spread the word about this application. If you're on this forum, you know how bloody useful this app is.
I use it for sales teams as a visual representation of their in-out bound activities. Its better than any CRM activity report and it's fully automated.
@jberkel, in many respects I'm happy to try to pull something together, but I'm unclear who has control/direction with respect to the application.
Wayne
Any chance backup could be an export to mbox or csv or mht or some other file on local storage?
Then we could a) move to another (safe) location, b) email to gmail where at least the content of emails is searchable, or c) investigate an occasional manual import to gmail perhaps through tbird if that were possible ...
I wonder if an option might be to (immediately) email any SMS (sent or received) to self, specifying an identifying Subject field that could be used to filter to a label and remove from inbox. The date/time of the email will then be close to the date/time of the SMS.
The user will of course have to setup their own gmail account and follow instructions to create the filter themselves.
The body could contain the labeled date, time, sender, recipient, and text message, and maybe they can be added individually to the email as fields named X-SMSBackupPlus-TimeStamp, X-SMSBackupPlus-Recipient, etc.
This way we are using smtp instead of the forbidden API. Not sure how this limits calendar integration (I never used it) maybe gmail will process an ICS attachment?
Maybe someone could pull strings and get the media onto this issue.? I think media awareness may open doors. There are so many people unhappy with this situation I think media exposure may add weight to reversing the decision. Plus someone may come up with a solution if this issue is more widely known? Wish I had the resources to do so. Just my $0.02's worth.
On Thu, 27 Jun. 2019, 18:01 trattman, [email protected] wrote:
Hi all,
I followed the instructions above switched to IMAP. It appears that both SMS and Call logs are being backed up without any issues. And the calls are finding their way to the calendar too.
I raise venture capital for startups and early stage businesses. I've made my donation through the google store, but it appears that this could use some funding (1) to get over this hurdle, (2) prevent it from happening again, and finally (3) spread the word about this application. If you're on this forum, you know how bloody useful this app is.
I use it for sales teams as a visual representation of their in-out bound activities. Its better than any CRM activity report and it's fully automated.
@jberkel https://github.com/jberkel, in many respects I'm happy to try to pull something together, but I'm unclear who has control/direction with respect to the application.
Wayne
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jberkel/sms-backup-plus/issues/959?email_source=notifications&email_token=AD6OXVXVA7TQUGTKDVJHXWLP4RXWJA5CNFSM4HYI7LT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYWJLKA#issuecomment-506238376, or mute the thread https://github.com/notifications/unsubscribe-auth/AD6OXVRWTTXG2UAQOM73RKDP4RXWJANCNFSM4HYI7LTQ .
I wonder if an option might be to (immediately) email any SMS (sent or received) to self.
I'm afraid that to send automatic emails from your Google account the GMail API is required too. There are no rely SMTP servers out there anymore, you must use the sender's one.
Another app sadly can't link names to calls (or events noting calls) after the last Android restriction. I was happy sms still did. They have a huge bug report upvote. I wonder if it were a paid app that Google lost money by not supporting would matter (too late now), but yea, add mail functions to get it to qualify, or add as a plug in / buddy app to another mail app that can access Google?
If not, I will be switching to imap. I have a non Google imap account so even if they restrict imap, I'm good. (But Imap is open protocol, so if the restrict it, it's to all imap apps? Someone mentioned kmail losing access)
It seems Google has find a way determining whether a connection is suspicious or not.
Although I never encountered it, there are many reports that K-9 mail is temporary restricted on IMAP access even with app specified password assigned.
It also occurred when I trying to access IMAP from other programs under development.
Ars Technica sharing the news: https://arstechnica.com/gadgets/2019/06/gmails-api-lockdown-will-kill-some-third-party-app-access-starting-july-15/
I have just posted an issue in the Google issue tracker, under the GMail API category, exposing why restricting too much the access to the Google APIs for security reasons can paradoxically lead to the Google accounts being less and less secure. I also sent the same message to "[email protected]".
https://issuetracker.google.com/issues/136079176
Of course I use the SMS Backup+ app as an example to defend the argument, so maybe it could lead to someone reconsidering the ban of this app from the GMail API. I do not expect great results from that "political" via, but it is worth trying.
Amazing issue @malversan. Starred and commented confirming your main security concern, and offering a way to address it (considering to implement a slightly more open scope of exempted "email applications").
This situation is another example of Google over-reacting and trying to improve security/privacy but actually causing more harm than good to many Android users. But I don't expect they will change their decision regarding this app despite well argued reasons. So I think we have to look at alternatives. I would expect that changing to IMAP access will work for now. But is there any way to determine if Google will block some IMAP access on the 15th July as well? If they do then perhaps the way forward is to utilise Google Drive instead of Gmail? Before anyone mentions it I know that the Gmail search function is excellent and this is not a direct solution but at least this would allow the storage of the SMS and call log data (perhaps in a spreadsheet) which would be easier to examine. Just a thought.
perhaps the way forward is to utilise Google Drive instead of Gmail.
In my opinion it has no sense to go that way for two reasons:
-
There are already lots of apps that backup SMS messages and call logs in many destinations, even Google Drive. The gold feature here is to make it in searchable emails and an organizable calendar in the cloud, that's the key feature that nobody else has and makes this app unique.
-
On top of that, the Google Drive API will be also made a restricted scope by Google in 2020, so any apps creating documents there for non clear purposes will suffer the same shutdown we're facing with the GMail API.
Malversan - As I said in my comment this is not a perfect solution. Whilst the Gmail API may be restricted I can't see how the Gdrive API can be restricted otherwise how will any app be able to read or write anything to the cloud? If it is restricted in the same way then we may as well give up with Google storage all together. Apart from your attempt to get Google to change their stance, which is not going to happen, what solution are you proposing?
@jberkel ...is there anything mentioned here (by many techie savvy people) that can assist you please? If not, what can we do for you please? Clearly we DO NOT want SMS Backup+ to end on 15 July 2019. I wish I had the power and resources to reverse this decision. But, alas, I don't.
I can't see how the Gdrive API can be restricted.
Easy. Any app that Google considers that has not file storing as its main purpose will be banned from it.
What you say can also be applied to the GMail API, and you can see the results. I wouldn't rely in making Google Drive a casual storage for app data, as it will follow the same path next year.
what solution are you proposing?
As best solution, I propose making Google Calendar the only Google backup storage for this app (yes, also for SMS messages). We could loose some search functionality, but backup/restore features and reviewing items in the cloud will still be available. And Google Calendar is not going to be restricted, or at least it's not in Google's current plans.
The problem is that this is not currently implemented in the app for SMS messages, so it would require some development work.
Any thoughts about the issue, @jberkel?
what solution are you proposing?
As best solution, I propose making Google Calendar the only Google backup storage for this app (yes, also for SMS messages). We could loose some search functionality, but backup/restore features and reviewing items in the cloud will still be available. And Google Calendar is not going to be restricted, or at least it's not in Google's current plans.
The problem is that this is not currently implemented in the app for SMS messages, so it would require some development work.
I strongly disagree with this direction. The whole purpose of this app (in my opinion) is to have searchable text archives of the messages and to provide restore capability.
Calls placed on a calendar make sense because they are a time-based event; The call was X minutes long and was to/from X contact(s). There's no duration associated with a text message; it is an instantaneous event.
Messages on a calendar event would need the content of the message, who it was from, Group SMS/MMS will need to associate multiple people. As mentioned, there's no duration associated with it; so what does a default conversation of 10 texts in 30 minutes look like on a calendar? 10 one minute events stacked on top of each other?
If all messages were moved to Calendar and presumably archived there, searching and archiving of messages becomes significantly harder, as one would need to parse .ical/etc format, which is significant overhead beyond plain text emails, where headers are easy (in comparison) to parse out.
Again, I disagree with moving everything to calendar-only format.
Unless the issues with sorting access to GMail can be resolved (which IMAP+App Passwords may quite possibly do), then I strongly recommend storing things as an archive in GDrive. (Akin to how SMS Backup and Restore currently functions)
I've had a quick look at the internal working and possible alternatives. I don't know what Google's restrictions are, but would changing the scope from https://mail.google.com/ to https://www.googleapis.com/auth/gmail.insert and https://www.googleapis.com/auth/gmail.readonly as shown on https://developers.google.com/gmail/api/auth/scopes be enough to pass verification? Possibly even as a 2 stage one - allow users to approve insert access for backup and approve readonly access for restore?
(There may be other scopes required, but the principle would apply)
Ah, even insert, without the ability to read, is considered restricted. Eh? https://support.google.com/cloud/answer/9110914#restricted-scopes
gmail.send and gmail.labels aren't restricted, which might be enough for backup?
@tomswartz07, I'm perfectly aware that some search capability would be lost with my Calendar solution, but I think you lost the point. We are not here talking about what we need or what we want, but about what can be done. This is not a thread to post feature requests, it's a desperate discussion about the few possibilities of surviving this app has if its functionality does not change.
Apart from that, your solution is perfectly compatible with mine. Both messages and calls can be saved to Calendars and Drive documents, the same way it currently saves call logs to Calendar and GMail.
Let me point you anyway that I neither see any out-of-the-box search capabilities in Drive documents. It's even less user-friendly than Calendar, altough you code an specific app to read the specific SMS-sheet format. Calendar already has that, your solution does not.
On top of that, there are already a ton of apps that can save your SMS messages in a Google Drive sheet. You even mentioned one of them. So excuse me if I can't understand why you're asking for something that you already have.
As a definite reason, I'm completely reluctant to spend efforts in making a Google Drive solution because it's also going to be restricted next year, so in a very small time we will be complaining again for the same reason we are here today. Google wants to boost their fast-growing GCP Firebase cloud platform, so any app that uses Google Drive documents as a database is presumably going to be banned from its API. It's a matter of business, not about what you desire (or me, or the entire universe of users).
@craignicol Thanks for doing some deep dives in the code. I look forward to hearing what the project maintainer, @jberkel, has to say. Perhaps this method has already been tested when going through the review process.
As per my previous message, I hope that the app can be modified to work in a way that it has in the past, without the need for convoluted and more-obvious-misuses of Google's services, such as storing hundreds of text messages in calendar events.
@malversan I appreciate your willingness to help work towards a viable solution, but I please ask that you tone down the aggressive language. Disagreement with your suggestions is not a personal attack, and should not be treated or responded to as such. There are technical hurdles to be undertaken for any change necessary to make the app work in the future, and should be discussed as presented. As I mentioned before, @jberkel or one of the other maintainers may choose to lock the thread if the hostile communications continue.
@tomswartz07 the obvious disadvantage of my suggestion is that it doesn't allow restore. For many users here who just want backup, it would be fine, but for the users who want to restore messages, they may need an alternative solution. I don't know how large these respective camps are. I personally have not used the restore function (GMail search is perfect for me use cases).
@tomswartz07, maybe you feel my talk unusual because I'm not from your country, but I'm tired of defending technical arguments in front of all-over-the-world companies and no one has ever pointed me as doing it in unpolite ways.
So I'm afraid it's you who may be taking a well reasoned disagreement as a personal attack. If you want to see aggressive language where there isn't any... well, that's your problem, not mine. But I would just ask you to please don't deviate the thread topic with non-technical appreciations, if you really don't want it to be closed.
@malversan: This will be my final word on this matter. If GitHub had a private message function, I'd express these concerns on the side, privately. Unfortunately, no such feature exists. If you had a git repository with a single commit in it, I'd be able to get your email address from a commit message and address it to you privately, but again; none such commits have been made.
As it stands, however, this is the second time that I've had to ask you to tone down the aggressive language, in addition to several other users on the thread commenting about your behavior.
I will stand aside here to assist the contributors as work is done towards a solution, but at the end of the day, no solution can be made without changes to the code or explicit approval from Google.
@tomswartz07, please stop what you are doing. You are not helping anyone by reacting as if you were attacked personally by any reasoned disagreement with your technical proposal. Enough.
- On top of that, the Google Drive API will be also made a restricted scope by Google in 2020, so any apps creating documents there for non clear purposes will suffer the same shutdown we're facing with the GMail API.
This is not true from what I see. You can use use drive.file limiting access to files the app creates or you specifically give access to. Which is all SMS Backup+ would need. Drive searches the contents of the files so I don't see a problem with it. If what's below works you would not have to give the user access to the folder and could just use drive.appfolder
Anyone know why if any reason this would not work? SMS Backup+ => Drive + Apps Script => Gmail. This removes the read access to gmail since SMS can be restored from a sheet, json or XML file(s). or SMS Backup+ => Drive + Gmail (gmail.insert) Again this does the same. So now all that would be needed is gmail.labels and gmail.insert and only insert needs to be approved.
Basing it on @jberkel 's comment.
mainly because it's not an email reading app.
@malversan Thanks for your uninformed assumptions on countless subjects. First, I can assure you that from your OWN "rantings" and use of profanity in a professional forum that you don't want to get into an "intelligence" contest with me, and I have neither the time nor desire to prove it, as it's irrelevant. Most everyone knows that people who make sweeping assumptions about an individual whom they do not know, and sweeping assumptions about what anyone, in this case Google, may or may not respond to, as if they were a Google official themselves, and further, that attack people on a personal level with no basis to do so, are the ones widely known to lack both the intelligence and foresight to understand there are many forms of leverage. You have zero evidence of my intelligence, my knowledge of how political systems work or my knowledge or use of diplomacy, all of which are vast, thank you very much. I've been in business 30 years and have negotiated billion dollar projects with the Chairmen of billion dollar companies, so please don't lecture me on how to present that to which I'm entitled to present in any manner I wish, just as you are, even in your MOST mature and uninformed way.
First, I make ALL of my opinions, beliefs, objections, complaints and accusations if they are warranted, "frontally" as you call it, since I don't play any games, nor do I "attack" anyone from the back like a coward. Most "intelligent," as you call it, business people of strong character know that straightforward, direct, even blunt communication is the only way to effectively deal with any subject. This approach, whether the recipient likes WHAT'S being said or not, builds trust, because of the WAY in which it's said- even between adversaries (which Google is not)- because you haven't personally attacked them, proven your lack of appropriate vocabulary by using profanity, and they don't have to wonder if your're up to something or working some sort of "political" agenda.
Experienced business people directly lay out their position and their requests right out on the table without exaggeration, made-up facts, or unnecessary emotion. If the other party operates the same way, as most professionals do, then you remove the need to focus on anything but the subject at hand, instead of having to watch your back. Everything is in black and white, all guesswork is removed and your chances of an amicable solution are far greater.
Not that I owe you any explanation, I'll offer one as a humanitarian gesture that it may educate you in an area where you are clearly weak. My mention of ClipperSync and Picasa was building a case that now includes SMSBackup+, suggesting that Google's focus was on trying to compete in every market where another company is reaping huge profits, even if the company had so much market share (such as Facebook) there is no hope Google would ever catch up. If you're interested in FACTUAL information, you can verify what a strong example Picasa is to use as an example of several points I was making in my post by Googling it. There are MILLIONS of people that have complained, and are still complaining about Google's removal of such a fantastic program and switching to a platform like Google+ that was doomed from the start to try and compete with Facebook, and contrary to their claims when it was introduced, it wasn't even CLOSE to having the same functionality as Picasa. Even Google Photos pales to most every other photo management program out there, since it can ONLY be sorted by date, making finding one photo out of, in my case, 10's of thousands of other photos, impossible. These were examples trying to remind Google that ALL businesses are in business to serve their customers FIRST, and those that do that best reap the highest rewards. I was hoping to get their attention that if they don't serve and listen to their customers first, they'll ALWAYS be playing catch-up with other startups that come along that DO understand that concept.
Since you also don't understand sarcastic, INTENTIONALLY exaggerated analogies, that also support one of my primary points, which was that no business can be GREAT at everything, so they should focus on being the best in the areas where they ARE great, and Google IS great at many things. So my sarcastic exaggerated (maybe?) example, suggesting that they likely have someone in a cubical somewhere working on how to build "spaceships," you know, like the ones like Elon Musk makes, whose name I clearly stated (eliminating your implication that I threw in some random, out-of-context example) who's making billions of dollars in MANY industries, which if Google's corporate ego is in fact out of control, like so many of the mega corporations out there right now (Amazon, etc.), they very well may be thinking they need to get in that business too.
As for me knowing to whom I was writing and who would be reading what I wrote, I was PERFECTLY aware of both the purpose of this forum and the audience, since I WANT them to read it.
Next, a little friendly enlightenment for you. Google, along with every other global corporation out there, HAS no "sympathy" for any individual or group. The ONLY way to appeal to any large corporation is from the standpoint of them losing business over the decisions they are making, since losing business means losing money, and making money is their ONLY concern. So let's not be naive in that area. If you still believe that, maybe you should send them a cake, or tickets to a ball game (this is called "sarcasm," again to make a point about your ridiculous comments).
As for my "threat" as you call it, it wasn't INTENDED to be subtle and it wasn't a threat. It was sending Google the message that there are LOTS of options, with thousands more coming, of ways for their customers to get things done, and if they don't re-focus themselves on their existing customer base, they very well may lose part of that base. You see my friend, "customers" are what keep companies in business and keep them making money (again, their only goal). So my "threat" as you call it was alerting Google to the fact that they do not own the computing universe, and might want to pay more attention to those that are, or were, happy with their service. In another context, this would be called "voting with your wallet." (look it up).
Your statement "Now your rants and not-so-subtile threats against Google have assured that NOBODY will take that issue seriously," implies that you have some inside track on how Google operates, thinks or makes decisions, so let's put that statement in the absurd, unfounded category.
Also add to the absurd, unfounded category your statement, "you exposed all that unrelated and inappropiate comments talking as if you were the developer of the apped category your statement," (another tip for you, Google has a spell-checker built-in that you might consider using, but that's up to you) since it's completely unfounded, and based on my explanation above WAS related to the point I was trying to make to Google. Where you got that I was talking as if I were the developer of the App I don't know. Only a therapist could untangle that.
Yet another entry in the aforementioned category is your statement, "you have assured 100% that Google will never listen to him either." 100%? Really? Are you 100% sure you or I either one will still be alive in 10 minutes? The only thing on earth for which we can be 100% sure is death itself (look that up too). If you want to talk percentages, I'm 99% sure that the ONLY person Google is likely to listen to IS @JBERKEL, since he or she is the ONLY person (I assume) in this group that has DIRECT access to Google, and can debate and defend the safety of their code when connecting to Gmail.
In closing, thank you for congratulating me on my well-intended, blunt and to-the-point, appropriately worded post directly to Google, with excellent examples of why Google should reconsider ALL of the actions they are taking that are grossly disrupting the workflows of their giant customer base. I hope it will get their attention, and if it does, there's no need to thank me again; it was my pleasure, as was writing this post to help someone that's clearly in need of education in general, but most especially in the areas of communication and negotiation.
By the way, there's no need to waste your time (that you obviously have plenty of) with another profanity-filled "rant" against me to try and prove your superiority to everyone. How about if I just let you BE superior, in your own mind, and call it even, since this is going to be my LAST and ONLY response to someone so far out of the loop that an intelligent debate is impossible. So write away if you like, but rest assured it will be into the abyss.
Enjoy your day...
This is not true from what I see. You can use use drive.file limiting access to files the app creates or you specifically give access to. Which is all SMS Backup+ would need. Drive searches the contents of the files so I don't see a problem with it.
I´m glad to say that I've checked you´re partially right on that.
First I only read the scopes being restricted in @craignicol link: https://support.google.com/cloud/answer/9110914#restricted-scopes But now I've checked that there are separated API scopes for app own files, and those are not planned to be restricted: https://developers.google.com/drive/api/v3/about-auth
I've also checked the search capability to find SMS messages and calls. It is possible, but there are some serious caveats.
First: As I said previously, forget about spreadsheets. You can find where is a spreadsheet that contains a certain text, but that only gets you to the file, not to the line where the text appears. The GDrive search is unuseful to find a specific item inside a spreadsheet full of them.
So to be searched the SMS messages and calls should be stored INDIVIDUALLY inside plain text or XML files. No problem for backup or restore via API, but when it comes to listing or searching items... there´s a limit in the number of files you can list inside a directory in the Drive UI. The limit is reasonably high enough for an usual file listing, but insufficient when it comes to the thousands of files we´re talking about. So a hashing organization is required, something like one directory for each year, then one subdirectory for each month, and then one sub-subdirectory for each day.
Second: In the Drive UI, if you want to find text just inside a specific directory (the app-created directory) you must do it by using the search dropdown control on the right and then specifying the ubication to search in. Somewhat tricky.
But now comes the worst part. This inside-directory searches can only be done in the desktop web version of GDrive. I´ve searched in the Drive app and I can´t found such option. Using the mobile or tablet, if you search for a text it finds the occurrences IN ALL YOUR DRIVE. That´s fatal if you have other files or app directories, as it´s the usual case.
Finally, I don´t get what you say about linking that documents to GMail. Can it be done automatically with a Google Drive App Script? The API "drive.scripts" is going to be restricted anyway. And the "gmail.insert" and "gmail.readonly" scopes are already restricted. Asking Google to manipulate data in a generic container is a no go.
@tomswartz07 and @Jasonfhaught...thank you for providing step-by-step details for how to create an app password for IMAP. I'm sure other non-techie people like me appreciate this. From reading the forum, I'm clearly out of my techie depths here, so your detail is appreciated. :) Thank you also @JKS258 and @malversan for providing knowledge. I'm attempting to wrap my brain around what you say and am trying to learn. I just hope, at the end of the day, that the magnificent @jberkel and SMS Backup+ wins this Google war. It never occurred to me that I could grieve the loss of an app, but in the case of SMS Backup+ it appears this will be so :( .
@JKS258, it is clear you are a spammer wherever you post. I must admit it is really admirable the amount of time you spend in posting endless rants and whines that nobody is going to read (neither me, you can be sure). Let´s see if this truth makes its path into your brain: nobody here cares about you, your life, your job, or how you believe you are, so it is a nonsense that you persist with all that tantrums just because you need a public to talk about yourself.
Any skills are demonstrated by exposing the right knowledge in the right manner and in the right direction. And I am sorry to note it, but it is enough to read the first lines of any of your perorations to clearly see that you do not master any of that three qualities, so you are completely unuseful and irrelevant in this issue. Please, hold your tongue and let the technical people discuss serenely, instead of trying to undermine any serious argumentation.
The only funny thing about this is that you really think you are facing a giant corporation with bravenery and intelligence. No, boy, you were just ranting to a helpdesk assistant individual who will just delete your monumental, excessive and unrelated complaint without even reading it (like all us). And here you are simply bothering, not contributing in any way. So please...
P.S.: Before @tomswartz07 comes for me again, yes, that really was an aggresive response. I am here just trying to help teaming with the skilled people, not trying to be nice for the general audience. And I am pretty intolerant with the lack of intelligence, specially when coming from some peasant spammer, so if you want to deal with that vermin it is all yours.
Thank you @tomswartz07 for attempting to reel in the aggressive attacks of a single member of this group we all know by now. I've made exactly ONE post (I "think") in this group regarding the potential loss of one of the two most used Apps in my arsenal, yet this lunatic refers to me as a "spammer" among other things, and chooses me to attack me one day, and someone else the next, with his aggressive demeanor, profanity and personal attacks against anyone that doesn't meet his self-proclaimed standards of how they should express themselves. He makes endless, baseless remarks, again all personal, against virtually anyone, when his name is never even mentioned in the post. He's like a digital schoolyard bully with nothing better to do but stare at his screen all day waiting on someone to make a comment that he doesn't agree with, or in a manner that he doesn't agree with, where he then pounces on them with ignorant, and again baseless statements for no discernible reason except to pick a fight with not just someone, like myself, but anyone. I wish your many polite, calm, professional requests could be even understood by this individual for whom I frankly feel sorry, but I'm afraid people like that see everything as a personal attack, even being asked to behave in a professional manner. He is demonstrating the perfect profile of a classic narcissist, a condition for which there is no cure, and who's only objective in dealing with anyone, anywhere in life is to "win," no matter how trivial the victory. Since he's clearly not going to stop this behavior due to his psychosis, as evidenced by his attempt at a reply to my one and only reply to his aggressive attacks, where he couldn't help but take a cheap shot at you at the end, where like everyone else, you weren't even involved. Can @jberkel not block or ban him from the group for his relentless behavior in a public forum? I certainly hope so. Like most everyone else has expressed, I feel enormous gratitude to @jberkel for the work he has done for the last nine years in creating one of the most useful Apps on the Android platform, and would like to see a solution to this problem, but it's hard to discuss solutions with a predator in the midst. I for one would like to request @jberkel ban him from the group so we can move on to the business at hand vs. this mamby-pamby mindless banter this person is clearly unwilling to cease. Thanks again though, for your attempt to restore some professionalism to the group Tom. Best regards...
I'm glad this is actively being discussed. Besides the IMAP approach, are there any other options in keeping this functionality? It's crazy Google is doing this...
Will the function of entering calls as appointments in the calendar after 15 July still work?
@jberkel:
Regarding switching to a more specific scope (or scopes): I think you'd be able to use https://www.googleapis.com/auth/gmail.insert https://www.googleapis.com/auth/gmail.readonly https://www.googleapis.com/auth/gmail.labels instead of https://mail.google.com/, but only if you switch to using Gmail API, and not IMAP+XOAUTH2 like you do now. I'm still not sure if that would get you approved, but it would definitely be better to use more limited scopes.
Another (IMHO better) option would be to move to Sheets API. If you put all SMSs in a sheet, and use the https://www.googleapis.com/auth/drive.file scope (Per-file access to files created or opened by the app) you wouldn't need Gmail access at all (except for restoring old backups in Gmail, and maybe you'd be able to negotiate that with Google, or migrate all users' old backups to a sheet before the deadline). Users who want SMSs in their Gmail can then enable notifications for their SMS sheet, or use Apps Script for more complex stuff.
G Suite (formerly known as Google Apps) admins can simply whitelist the app for their users, so they wouldn't be affected, but I assume most of your users are @gmail.com users.
As for the other workaround suggested here: I wouldn't suggest telling users to use a username+password for IMAP login, as it's (obviously) less secure, and a hassle to set up. I'm personally in favour of Google's app verification program, because before that, users just had to blindly trust apps, and sadly not all of them are as trustworthy as this one. It isn't perfect, but it would make an attack harder. I only wish the move would have been easier for long-standing OAuth apps.
Thanks for creating this great app - sorry to see this is creating a headache for you!
@eesheesh, please read the messages above. The ”gmail.insert” and ”gmail.readonly” API calls are also going to be restricted. And storing in GDrive is already being discussed.
It will be hard to advance if technical proposals are done ignoring everything that has already been discussed.
Thanks @malversan, I missed a part of the discussion because of GitHub's discussion folding. :) Just to add my 2c about the things discussed:
- Regarding searchability in Sheets - I would personally prefer a single sheet with all SMSs in it (one per row). If that's the case, I think the common use case would be to open the SMS sheet and search there, not search across all of Drive, but maybe that doesn't apply to everyone. Also, searching in Gmail gives you sheets that match the search terms, but then you'd have to search again after clicking it (like after searching in Drive, as you've noted in your comment).
- Regarding availability of other apps - I haven't tried any other apps, but the one I saw linked here isn't open source, and I'd prefer an open source app (and I assume this is important for many others).
I think the common use case would be to open the SMS sheet and search there.
I personally doubt it. A Google sheet does not give you a report of occurrences to select the right one. It simply lets you jump from the first occurrence to the next, and then to the next, and then to the next... Not very useful when searching for common words in thousands of messages.
And worse than that, sheets do not allow to make compound searches at all, they only allow to search one exact string contained in one only cell. So for example, if you want to search in which message the contact ”Bob” talked about an ”invoice”, you cannot do that in a sheet, you will not get any results searching for 'Bob invoice'. But Drive search can handle that trivially.
In that point is where Google searches excel. They let you mix in the search the content, the sender, the receiver and the date. You can search for example '(”Bob” or ”Mark”) and ”2017” and (”invoice” or ”bill”) and (”overdue” or ”unpayed”)'. It is impossible not to find what you search, you just need to barely remember two or three words.
One of the key greatnesses of storing SMS messages in GMail is the ability to perform that kind of searches to find virtually anything in a sea of messages. I would suggest not to loose that unvaluable feature. In my opinion it's a point that makes this app stand out far over others.
Sorry I'm about to leave for vacation so I don't have time to mess with it but is it possible to configure SMS Backup+ to backup to a different non-Gmail IMAP server then configure Gmail to import them automatically from there? It sounds a little hokey but it seems unlikely to me that Gmail will stop allowing users to import messages from another email account.
Yes, you can. But you won't be able to restore until you leave those mails on the configured server. You also won't be able to delete threats from Gmail since it's usually a one-way sync.
ALTERNATIVE SOLUTION TO GMAIL
I haven't read this entire thread so perhaps this is redundant.
I was using a specific gmail account for only SMS Backup+ but recently punted due to gmail blocking SMS Backup+ on 7/15/19.
I switched over to using a "[yourusername]@outlook.com" email address successfully.
Here's the necessary info for android SMS Backup+:
- Turn off the gmail access using the switch.
- Go to Advanced Settings -> Custom IMAP Server.
- For the imap server enter (without quotes): "smtp-mail.outlook.com"
- Email address enter (without quotes or brackets): "[yourusername]@outlook.com"
- Enter your password associated with "[yourusername]@outlook.com"
- For Security, select STARTTLS.
- Return to the appropriate backup settings for SMS, MMS, and Call Log and make sure they are all setup and enabled to your liking.
- Press the Backup button to commence a backup to "[yourusername]@outlook.com".
- If you have a lot of messages, it may stop in the middle of the backup. Just press the Backup button again and the backup process will resume. I've encountered the same when using gmail.
- When backing up Call logs, it may give an error message the first attempt. Just ignore it and press the Backup button again and it will successfully backup.
I've been using the above for almost a week without a glitch.
I should mention although Backup works great, I have not tried a Restore.
I'm not an App expert, but my experience so far with Google OAuth is that, for those who seriously want to keep using the App, they can - they just have to hit the "Advanced..." link when Google complains about the access and tell it to go ahead. As I said, not an expert, this process only works for me when connecting to my own personal Google-related stuff with personal Apps I've been developing, and there doesn't seem to be a downside (yet).
ALTERNATIVE SOLUTION TO GMAIL
I haven't read this entire thread so perhaps this is redundant.
I was using gmail but recently punted due to gmail blocking SMS Backup+ on 7/15/19.
I switched over to using a "[yourusername]@outlook.com" email address successfully.
Here's the necessary info for android SMS Backup+:
- Turn off the gmail access using the switch.
- Go to Advanced Settings -> Custom IMAP Server.
- For the imap server enter (without quotes): "smtp-mail.outlook.com"
- Email address enter (without quotes or brackets): "[yourusername]@outlook.com"
- Enter your password associated with "[yourusername]@outlook.com"
- For Security, select STARTTLS.
Thank you so very much @kokishin1 Your solution worked but with modifications (for my setup) I had to enable POP in Outlook because I want Gmail to pick up my SMS messages.
Could SMSBackup+ email any SMS (sent or received) to self using SMTP. It will act as a mail client (via any authenticated smtp server e.g. yahoo, user has to enter the details, "[email protected]" is irrelevant) or send directly to the gmail smtp server itself. The user will need to configure filters in Gmail to label the messages and bypass the inbox.
There is no need mailing to self and go through all spam/filter rules again. IMAP can put into your inbox DIRECTLY and it's what SMSbackup+ already had (unless Google want to put additional limitations).
I think that, if feasible and without a ton of work, the dev should try to use Google APIs for backing up. I personally hardly use the calendar functionality, mostly just search for SMS, but I'm aware that alot of people do use the Calendar functionality. Maybe the dev could even build unapproaved APKs via a third-party channel until it gets to a stage that Google is okay with.
In any case, I'm prepared to use IMAP regardless, even if I have to use another e-mail provider other than Gmail.
@ner00 this issue was opened because the developer actually can't use the Google APIs. Access has been turned off.
Maybe the dev could even build unapproved APKs
This isn't an issue with Google Play approving the application, this is about being unable to authorize with Gmail through the normal OAuth flow for these specific scopes. Building and self-hosting APKs would not fix the problem.
I'm prepared to use IMAP regardless, even if I have to use another e-mail provider other than Gmail
You don't need to use another email provider, you just need to configure Gmail correctly (see previous instructions in this thread.)
@weaversam8 My bad, I misunderstood the scope of the enforcement. I don't have to use another e-mail provider (yet), but I also don't have to downgrade my account's security either. I much rather have a secondary disposable account and pull the backups through POP3.
@malversan Yeah, I got it. At this point it will only affect GMail, next year probably Drive, and Calendar probably on Google's todo list anyway.
Has there been any detailed explanation about what was submitted to Google and their exact response? I'm really curious about that exchange. Upon reading the new policy I don't see any way for SMS Backup+ to fit in there, arguably it could fit into example 3:
- Applications that enhance the email experience for productivity purposes (such as applications for customer relationship management, delayed sending of email, or mail merge)
It doesn't enhance e-mail productivity, but it enhances productivity using e-mail (for that it would have to be allowed to upload the e-mails in the first place). There are all kinds of contradictions in the several interconnected pages of the policy update. It seems that IMAP is the way forward for SMS and call log backup.