Status Update
Comments
sk...@gmail.com <sk...@gmail.com> #2
bi...@gmail.com <bi...@gmail.com> #3
ar...@gmail.com <ar...@gmail.com> #4
jm...@gmail.com <jm...@gmail.com> #5
tk...@gmail.com <tk...@gmail.com> #6
we...@gmail.com <we...@gmail.com> #7
bu...@gmail.com <bu...@gmail.com> #8
me...@gmail.com <me...@gmail.com> #9
da...@gmail.com <da...@gmail.com> #10
br...@gmail.com <br...@gmail.com> #11
li...@gmail.com <li...@gmail.com> #12
je...@gmail.com <je...@gmail.com> #13
bm...@gmail.com <bm...@gmail.com> #14
ro...@gmail.com <ro...@gmail.com> #15
jb...@osler.org <jb...@osler.org> #16
Please reconsider this decision.
ke...@theketovers.com <ke...@theketovers.com> #17
st...@gmail.com <st...@gmail.com> #18
If someone is listening, please.... Listen 🤷♂️
ge...@gmail.com <ge...@gmail.com> #19
mo...@gmail.com <mo...@gmail.com> #20
rl...@gmail.com <rl...@gmail.com> #21
ko...@gmail.com <ko...@gmail.com> #22
ry...@gmail.com <ry...@gmail.com> #23
jk...@gmail.com <jk...@gmail.com> #24
In my opinion, the entire computer industry is out of control. Instead of everyone doing what they do best, all software companies want to have it ALL out of greed or ego. That's why Google+ failed miserably, trying to compete with Facebook. Why not let Facebook own their piece of the pie and you focus on yours? And Picasa! Picasa was, and is STILL, the absolute best photo management software out there. I found a workaround and still use it, but I can't upload it to anything anymore since you first killed Picasa Web, and then let Google+ die it's inevitable natural death. There's enough business out there for everybody, so instead of trying to take over the world, maybe you should think of your CUSTOMERS and what THEIR needs are, before you start trying to build spaceships to compete with Elon Musk (which I'm sure you're doing in a cubicle somewhere!).
For now, for the sake of your zillions of LOYAL users, STOP TAKING AWAY functionality by killing Apps that provide no threat. Again, you should be telling me this, but instead I'll tell you. If you think you're going to eliminate the risk of someone hacking your system, you're wrong. For every action software companies take to tighten their security, hackers all over the world are out there creating workarounds that are operating within hours of when you plug what you think is a security hole. I'm all for security and it's a valid concern, but don't put that losing battle ahead of your average, everyday customer, which makes up, what 95% of the market, that most hackers don't care about to start with, that just want to Google some things, email some things, send some texts and have everything backed up.
Respectfully submitted, Jay...
ti...@gmail.com <ti...@gmail.com> #25
gh...@gmail.com <gh...@gmail.com> #26
mb...@gmail.com <mb...@gmail.com> #27
Thank you,
Mark
ed...@gmail.com <ed...@gmail.com> #28
da...@gmail.com <da...@gmail.com> #29
jo...@gmail.com <jo...@gmail.com> #30
wa...@gmail.com <wa...@gmail.com> #31
Wayne
sa...@gmail.com <sa...@gmail.com> #32
cv...@gmail.com <cv...@gmail.com> #33
dj...@gmail.com <dj...@gmail.com> #34
ym...@gmail.com <ym...@gmail.com> #35
ec...@invisiblerobot.com <ec...@invisiblerobot.com> #36
de...@gmail.com <de...@gmail.com> #37
al...@gmail.com <al...@gmail.com> #38
en...@gmail.com <en...@gmail.com> #39
ig...@gmail.com <ig...@gmail.com> #40
Don't let this useful yet feather light app to stop running in the way it has been thought.
Or at least COVER IN GOLD the developer and include his great work in Gmail.
im...@gmail.com <im...@gmail.com> #41
or...@gmail.com <or...@gmail.com> #42
Using a less secure alternative isn't very appealing.
st...@allthatwemight.be <st...@allthatwemight.be> #43
This functionality remains an excellent example of how Android and the Google Apps ecosystem interoperate to solve problems. No fancy "phone migration" utilities are required and we are also able to search our SMS messages and calls from Gmail which makes checking on desktops or tablets very easy.
Volumes of data are tiny, but the usability benefits are huge. Please whitelist this application, as it facilitates the Android experience and has done so since Android 2.x was around.
ak...@gmail.com <ak...@gmail.com> #44
jk...@gmail.com <jk...@gmail.com> #45
jp...@gmail.com <jp...@gmail.com> #46
an...@gmail.com <an...@gmail.com> #47
Thank you!
cw...@gmail.com <cw...@gmail.com> #48
gi...@gmail.com <gi...@gmail.com> #49
I would suggest considering amending the policy, and in particular addressing the scope of email applications that are granted exemption. It looks a bit too narrow.
Kind regards
an...@gmail.com <an...@gmail.com> #50
rs...@gmail.com <rs...@gmail.com> #51
I'm using it for 5yrs+ - it's priceless resource to see calls/smss via gmail.
I'd appreciate your thoutfullness google here, and as a support I will buy and recommend google one service.
Thank you.
ds...@gmail.com <ds...@gmail.com> #52
ja...@gmail.com <ja...@gmail.com> #53
ca...@gmail.com <ca...@gmail.com> #54
ja...@gmail.com <ja...@gmail.com> #55
Call Recorder I need to install from 3rd party website because Google blocks call logs access on Play Store.
GOOGLE is this 'security' action making any sense?
ka...@gmail.com <ka...@gmail.com> #56
dm...@gmail.com <dm...@gmail.com> #57
we...@gmail.com <we...@gmail.com> #58
sc...@gmail.com <sc...@gmail.com> #59
pa...@gmail.com <pa...@gmail.com> #60
jo...@gmail.com <jo...@gmail.com> #61
pa...@gmail.com <pa...@gmail.com> #62
gi...@gmail.com <gi...@gmail.com> #63
je...@gmail.com <je...@gmail.com> #64
mi...@gmail.com <mi...@gmail.com> #65
in...@gmail.com <in...@gmail.com> #66
But again another absurd decision by Google. Security is important but closing your eye for the so-called sake of improving security is simply "IDIOTIC". Every new decision passed by Google it seems I'm moving more and more towards moving out of your platform and services.
Whole open model of Android environment seems gone now. Keep yourself different from Apple, else you and them are same.
ha...@googlemail.com <ha...@googlemail.com> #67
Either the access method is secure, in which case any app must be allowed to continue with using that method to keep accessing the API.
Or the method is not secure in which case another method of API access should be implemented and apps should be given some time to adapt to these changes.
Is your access method insecure, Google?
fr...@gmail.com <fr...@gmail.com> #68
ej...@gmail.com <ej...@gmail.com> #69
ch...@gmail.com <ch...@gmail.com> #70
op...@gmail.com <op...@gmail.com> #71
al...@gmail.com <al...@gmail.com> #72
ev...@gmail.com <ev...@gmail.com> #73
st...@gmail.com <st...@gmail.com> #74
ns...@gmail.com <ns...@gmail.com> #75
Please rethink your API policies.
wh...@gmail.com <wh...@gmail.com> #76
db...@gmail.com <db...@gmail.com> #77
dd...@gmail.com <dd...@gmail.com> #78
sh...@gmail.com <sh...@gmail.com> #79
Please give an exception to this app. it's doing one thing very very well -- and safely too.
Jan has helped literally more than five million people back up their data this way and stripping all those people (and him) of that ability for apparently no good reason is really just terrible.
dt...@gmail.com <dt...@gmail.com> #80
sh...@gmail.com <sh...@gmail.com> #81
ee...@gmail.com <ee...@gmail.com> #82
ch...@gmail.com <ch...@gmail.com> #83
No dark sarcasm in the webspace
Google leave them coders alone
Hey! Google! Leave us coders alone!
ch...@gmail.com <ch...@gmail.com> #84
uc...@gmail.com <uc...@gmail.com> #85
gr...@witek.net <gr...@witek.net> #86
ma...@gmail.com <ma...@gmail.com> #87
co...@gmail.com <co...@gmail.com> #88
dh...@gmail.com <dh...@gmail.com> #89
in...@gmail.com <in...@gmail.com> #90
al...@gmail.com <al...@gmail.com> #91
ju...@gmail.com <ju...@gmail.com> #92
ha...@gmail.com <ha...@gmail.com> #93
hi...@gmail.com <hi...@gmail.com> #94
jo...@gmail.com <jo...@gmail.com> #95
br...@gmail.com <br...@gmail.com> #96
If not give permission I will eventually move out of paid Google ecosystem I currently use.
ny...@gmail.com <ny...@gmail.com> #97
el...@gmail.com <el...@gmail.com> #98
pc...@gmail.com <pc...@gmail.com> #99
It's kind of ridiculous that the app developer tried to do things the right way by using OAuth (for a long time now) and even applying for an exception after the new policy was announced & Google still shuns said developer, and by extension the customers who support the app and use Google's products (i.e., the people who enable Google to make money).
I'm getting pretty annoyed with Android restrictions lately...I have used the OS since the early days, and I specifically chose Android over iOS because I didn't want to be stuck in a "walled garden". Seems like Google was just behind schedule on building the walls, but construction is now underway! :-/
ca...@gmail.com <ca...@gmail.com> #100
as...@gmail.com <as...@gmail.com> #101
tj...@gmail.com <tj...@gmail.com> #102
sh...@gmail.com <sh...@gmail.com> #103
er...@gmail.com <er...@gmail.com> #104
ee...@gmail.com <ee...@gmail.com> #105
an...@gmail.com <an...@gmail.com> #106
ma...@gmail.com <ma...@gmail.com> #107
pa...@gmail.com <pa...@gmail.com> #108
in...@gmail.com <in...@gmail.com> #109
It is crazy that I've had to downgrade the security of my account as a workaround to a policy that was intended to _increase_ security.
I believe the fundamental flaw was in formulating a policy that assumes the only "valid" use for email access is the _read_ mail, ignoring that in order for there to be something to read, there has to be something able to _write_ email as well.
Perhaps a reasonable compromise would be to apply scope restrictions to individually API calls, rather than to email as a whole.
Or create an entirely new API for email producers, and reserve the existing API for email consumers.
-Martin (Xoogler pgeek@)
st...@gmail.com <st...@gmail.com> #110
The unique(?) feature set of SMS Backup+ is such that the only way to retain functionality of having SMS + phone calls backed up to Gmail and Google Calendar is to turn on IMAP in Gmail and create an application password and hope that this is sufficient protection for your Gmail account.
Overall the policy change may have increased the security posture of the Google platform, but there's now a set of accounts that have had their overall security posture downgraded in an attempt to maintain functionality.
se...@gmail.com <se...@gmail.com> #111
ju...@gmail.com <ju...@gmail.com> #112
aa...@gmail.com <aa...@gmail.com> #113
ma...@gmail.com <ma...@gmail.com> #114
se...@gmail.com <se...@gmail.com> #115
ww...@gmail.com <ww...@gmail.com> #116
al...@jessup.edu <al...@jessup.edu> #117
dm...@gmail.com <dm...@gmail.com> #118
kw...@gmail.com <kw...@gmail.com> #119
dn...@gmail.com <dn...@gmail.com> #120
is...@gmail.com <is...@gmail.com> #121
Its a great way for me to upload all of my call timestamps to my google calendar and a copy of my SMS to my gmail account!
el...@gmail.com <el...@gmail.com> #122
More broadly, the arguments layed out clearly demonstrate why Google needs to refine the new criteria and review process for granting access to the Gmail API.
In this particular instance, they lead to a severely misguided decision that blocks innovation and increases security risks for users that don't want to give up what has become essential functionality to them.
That is a disappointing and very ungoogley thing to do...
mt...@gmail.com <mt...@gmail.com> #123
The ability to search and print each message that was pertinent to my case, given to a lawyer and presented to a judge was crucial factor to the positive outcome.
The abilities of SMSBackup+ present themselves for many other use cases including domestic violence, law enforcement and EMS operations.
I don't understand why this app doesn't work anymore, but Google is really providing a disservice to the community at large by not allowing it to function.
Thank you for your consideration.
Michael Campbell, Veteran
Suicide Prevention Advocate
P.A.W.S. Forward Foundation
be...@gmail.com <be...@gmail.com> #124
de...@gmail.com <de...@gmail.com> #125
sh...@gmail.com <sh...@gmail.com> #126
Here's my vote in favor of SMS+ Backup!
we...@gmail.com <we...@gmail.com> #127
Here's my vote in favor of SMS+ Backup!
bk...@gmail.com <bk...@gmail.com> #128
ke...@gmail.com <ke...@gmail.com> #129
co...@laurentbelanger.com <co...@laurentbelanger.com> #130
st...@gmail.com <st...@gmail.com> #131
th...@gmail.com <th...@gmail.com> #132
si...@gmail.com <si...@gmail.com> #133
ro...@gmail.com <ro...@gmail.com> #134
In the recent years they started to limit what third-party developers' apps can do and what they can't, and at the same time they are adding the same functionality to their own apps! Shame on them!
For example, I used to maintain an app that read incoming One Time Password SMS and copied the OTP code or displayed it on the screens. Now only the pure messaging apps are allowed to do that AND recently they a similar functionality to their Messages. I quit, I can't fight the big corporation that threats to terminate my developer's account because of their new policies.
And now Android backs up SMS, at least on Pixel phones. Which does not really replace SMS backup+ since one can't look into the data in Gmail or Gcalendar like we all are used to do :-(
du...@gmail.com <du...@gmail.com> #135
to...@gmail.com <to...@gmail.com> #136
po...@gmail.com <po...@gmail.com> #137
jo...@google.com <jo...@google.com>
jo...@google.com <jo...@google.com> #138
Hello,
Thanks for bringing this to our attention and thanks for your patience, I have forwarded this internally in order to prioritize this feature. All communication related will be done here.
is...@google.com <is...@google.com>
jp...@google.com <jp...@google.com>
jp...@google.com <jp...@google.com> #139
We actually have already analyzed all apps using restricted Gmail scopes, and already do ask the developer for justification. We explicitly document the allowed usage in the APIs and Services user data policy here:
https://developers.google.com/terms/api-services-user-data-policy#additional_requirements_for_specific_api_scopes
ma...@gmail.com <ma...@gmail.com> #140
Some observations:
a) 4,5 years for an answer. Just to make clear to developers they can count on Google, I suppose.
b) The answer just repeats something that is already stated in the first message describing the issue.
c) The answer completely misses the point. The issue is not about a specific app, that was just an example. The issue is about users actively avoiding the use of security features (OAuth, TFA, ...) just because Google services' policies make their lives harder by blindly restricting use cases without taking into account fair use and logic exceptions, even when reasoned and documented strictly following Google guidelines.
As a personal statement, throughout these years I have encouraged, oriented and leaded the migration to more open alternatives whenever a customer company stumbled with these kind of cloud service restrictions-by-design. Cloud services make money from developer companies, but most of those companies must be able to make money from their users in first place. And clearly there are places more open and friendly than others when it comes to being creative in generaring opportunities with software development.
Description
Google is imminently shutting down access to API restricted scopes for applications that use them in suspicious ways. Everything is fine to this point.
But in the same bag Google is putting applications that make an INNOVATIVE use of their APIs to provide features that Google simply did not plan. Applications that are not abusing, not being suspicious in any way or making malicious uses, just providing more useful features than expected.
An example:
Let´s take this Android app as an example:
(Clarification: I am not involved in this app development at all, it is just a perfect example of what I am going to explain)
As its name suggests, it is an SMS and call log backup/restore utility for Android phones. But do not be fooled by that simple description, because saving SMS messages as GMail labeled messages and saving call logs to a Google Calendar it provides far more useful features. Without being its primary purpose, it allows to use the powerful GMail search features to navigate through your SMS messages, and also provides a Google Calendar to check who, when and for how long you called (or called you) with your mobile. That is not only creative, that it is pure gold, and simply essential once you have tested its power.
That app has nine years of history, and its happy user base has been growing solid during all that time. As a personal statement, it is the only app that I have always installed in all the mobile phones I have had.
Despite this huge growing user base, the developer never added any single suspicious or money-making line of code, not even ads, it is just released as donation-ware from the beginning. In fact the sources are open and free, so no suspicion at all can be perceived or conceived about the use it makes of the user data.
Asides, this app completely complies with the Google OAuth 2 security requirements. Its developer already applied it for the required security verification process to continue accessing the GMail API, as recently it become an API restricted scope.
And that allowance to access the GMail API was denied by Google because... well, just because it is not an email app. Apparently that makes the app suspicious per se, without further reason. So starting July 15th 2019 the app will not be able to access the GMail API anymore and thus it could be stripped of the great Google searching capabilities it provides for the user SMS and phone calls.
The resulting paradox:
So what can the users of this app do, not having any comparable alternative? Very simple. They will continue doing their SMS backup in GMail using the IMAP protocol, a feature also present in the same app.
But to do so they need to allow complete account access to "less secure" apps, completely bypassing all the Google-propietary XOAuth2 security thing, and even worse, making their entire Google accounts more vulnerable to ANY malicious application or service.
And remember, the app is fully XOAuth2 compliant. So having to entirely bypass the OAuth security (for ANY app!) just because the Google security policy is an obviously absurd nonsense.
This is a blatant example of how restricting an API scope for security can easily lead to making the whole user accounts less secure (by far) and bypass all the Google security efforts.
More generally, if the Google APIs become more and more closed without having logic exceptions in mind, we could expect an user movement in the opposite direction to maintain useful and user-friendly features by disclaiming from those strict security thresholds.
The request:
Just take logic exceptions in mind. I can understand to a certain point why the security concerns are making the use of the Google APIs more closed. But this closure has to have some logical limits, not an automatic denegation dynamic. Otherwise the users will eventually move in the opposite direction to continue using that essential or creative features that Google did not plan or considerate.
In my opinion, nothing of this antagonic effect would happen if the Google security verification team takes a bit of an effort to:
- really analyze all the apps that formally applied for verification to access API restricted scopes,
- or ask (minimally) the developer about the API use justification,
- or at least consider the thousands and thousands of users that witness a specific app as essential and not risky at all.
Q: What is the purpose of this new feature?
A: Allowing a creative enough (while secure) use of the Google APIs.
Q: What existing APIs would this affect?
A: Google API restricted scopes.
Q: What existing data does this use?
A: Any creative use of the Google APIs, as long as it is firmly justified by the developers and properly audited by Google.
Thanks in advance for your attention.
P.S.: Sorry for duplicating the post, I unadvertently posted the entire text with a wrong and severely undescriptive title and cannot change it. If someone with enough administrative privileges in this tracker component could delete the previous issue I would be very grateful.