
The Sign Up with Google Mistake You Can't Fix - mborch
https://maltheborch.com/2016/03/the-sign-up-with-google-mistake-you-can%27t-fix.html
======
Johnie
OAuth (Google Sign In / Facebook Login) is a pretty good technology in order
to manage and share your information. What's nice about OAuth is that it
allows the end user to control access to information and revoke access as
needed.

What is truly scary is that the banks and financial institutions have not
implemented OAuth. Currently, financial data is provided to third party apps
via aggregators, like Plaid and Yodlee.

Unlike OAuth, once you log into your bank with a third party app, they get an
access token that allows access to your account indefinitely. There is no
mechanism to monitor which apps have access to your account and ability to
revoke the access to individual apps.

I posted about this a while back: [https://medium.com/@johnie/let-my-
financial-data-free-74f3b7...](https://medium.com/@johnie/let-my-financial-
data-free-74f3b7476bda)

~~~
jakubp
"What's nice about OAuth is that it allows the end user to control access to
information and revoke access as needed." Really? This has NEVER been my
experience with OAuth or similar protocols. It's always all or nothing, and I
can never: \- limit the scope of any given type of permission \- find out
which data was actually accessed \- limit the number of permissions given
(it's all or nothing)

I realize this takes much more work than simple protocol, but it's the same as
on Android: either an app takes EVERYTHING they ask for, and noone tells you
how exactly they used those capabilities (no api log, no nothing), or you
can't use the app.

I would much prefer a solution which lets me: \- understand full scope of data
access (what does it mean that a web-app can "manage my contacts" in Google
account? Manage as in... delete? Change their details arbitrarily? What?!) \-
see full list, by app, what was actually accessed, and when \- be able to pick
which things I want the app to do, and which I don't \- define (with groups,
individual item selection or similar) which specific items I want the app to
access

If the app breaks because it doesn't support partial access, so be it. But not
designing this ability into the UI is basically forcing users to forever
become oblivious of how technology works.

~~~
CaptSpify
Marshmallow is much better about this. You can actually control what apps can
read, what they can write, etc. I wish it prompted you during the installation
of the app, but it's getting better.

~~~
magicalist
Yeah, for those that don't know, you can go into Settings -> Apps -> pick an
app -> Permissions and disable them at will. I believe only apps compiled
against a Marshmallow SDK version will prompt you at runtime, and there's
little (or even negative) incentive for app developers to do that yet.

~~~
dudus
There's a great incentive on automatic updates. If you updated an app pre
marshmallow with an extra permission it required the user to approve the
update and that ultimately creates a problem with a large user base stuck on
older versions.

Maybe for new apps there's less incentive to reduce access, I can't think
about any other than compliance and user scrutinity. It's easy to spot bad
reviews complaining about excessive permissions for some apps.

------
fixermark
"Fleep would like to:"

\- View and manage your mail

(click the "info" icon)

More info

\---------

View, manage, and permanently delete your mail in Gmail

Create, update, and delete labels

Compose and send new email

View your settings (e.g., filters and labels)

\- - -

Okay. So the author is saying that the user cannot be trusted to read dialog
boxes or click "more info" on a process they don't understand. Which, if
that's the case, I guess the user can't be trusted to connect Gmail to
anything. That's an unfortunately wide swath of usability that would have to
be categorically disallowed if the problem is that Google allows this "At
all."

~~~
pc86
FTA:

> _It 's just too easy to give away your personal information on the internet
> and this needs to be fixed._

More faux-outrage nonsense. Nothing _needs_ to be fixed, the author just needs
to read and actually understand what they're doing before blindly clicking
"OK" to any dialog box that pops up with Google's logo.

~~~
wstrange
I think the point is legit: Even for a technically sophisticated audience, it
was not 100% clear that "manage my email" would give away their entire address
book..

It's pretty poor behavior on the apps part - but this is an area where OAuth
consent dialogs could be more meaningful.

~~~
spacehome
"manage my email" is a thoroughly scary permission to my eyes.

------
smarx007
Fleep is a European (Estonian) company. Just mail them
([https://fleep.io/privacy](https://fleep.io/privacy), §9) and they should be
decent enough to terminate your account altogether. I had quite a good
experience with them, their CEO responded to my Fleep messages (nice example
of dogfooding), though haven't used it for a while now.

------
calcsam
If you realize it immediately after, you can cancel the OAuth authorization
you granted, before they grab your data:

[https://myaccount.google.com/u/0/security#connectedapps](https://myaccount.google.com/u/0/security#connectedapps)

~~~
tonyarkles
Having worked on an email client app before, that would definitely be
effective. Retrieving and processing a decade worth of email is a huge pain in
the ass that takes quite a long time (just retrieving the message bodies from
GMail took at least an hour).

~~~
mborch
I did after about 18 minutes which did limit the import to just the most
recent emails. Phew!

~~~
fixermark
I suspect Fleep is actually just importing the most recent emails, as that's
what the flow said it wanted the permission for.

~~~
mborch
You're right and actually the CEO reached out and clarified this. I have
updated my post to try and better reflect the problem.

------
xenophonf
I build federated IAM infrastructure at work, and one of the hardest problems
we have is informed consent around attribute release. Users don't necessarily
understand what they're releasing, developers don't necessarily understand
what they're asking for, and there isn't a way to fake attribute release under
the user's control (for those cases where you might still want to use a web
app but not give it the carte blanche access it's asking for). It gets even
more complicated when using social networks as identity providers of last
resort. I---along with my employer---am very privacy conscious, so I really,
really don't want to ask for any information I don't absolutely have to have.

I try to mitigate this personally by creating multiple Google Accounts, but it
isn't foolproof---plus, not every social network lets you do that.

~~~
mgreg
I would tend to agree. In this whole episode I don't think either Google or
the user are "at fault." I think its an unfortunate misunderstanding. A
powerful tool accidentally misused.

It does make me think that perhaps authentication (OAuth) would be better
provided by an independent organization that didn't house so much personal
data (that is, not an email provider nor a social network). An independent
provider that didn't have much, if any, personal info would prevent this
accidental release of information and control. That way if someone _really_
wanted to give a third party access to and control of their email at Google
they would have to actually take the extra step of logging into Google and
deliberately providing the access. In this case introducing friction into the
process may save the user from shooting himself in the foot.

~~~
dragonwriter
> It does make me think that perhaps authentication (OAuth) would be better
> provided by an independent organization that didn't house so much personal
> data (that is, not an email provider nor a social network).

OAuth is an _authorization_ system, not a mere authentication system, and it
makes sense to have an authorization provider that is the locus of data or
services for which authorization is required.

Separate authentication-only systems haven't been particularly successful.

~~~
mgreg
> OAuth is an authorization system, not a mere authentication system

You're right. Sorry for my sloppy use of AuthN and AuthZ. My point is that for
day to day authentication into 3rd party sites which is what I think most
people use "Sign in with Google" and the like for might be better served by a
3rd party with less or no data. Less chance of accidents like the subject of
this HN thread.

Of course as others have suggested Google could implement a more serious
authorization system for elevated or unusual privileges in order to get users,
such as this one, to pay attention.

~~~
dragonwriter
> My point is that for day to day authentication into 3rd party sites which is
> what I think most people use "Sign in with Google" and the like for might be
> better served by a 3rd party with less or no data.

Or just an AuthN-only protocol, like OpenID.

------
Someone1234
> the bigger problem here lies with how Google makes this possible: At all

Sorry but it is MY information and I should be able to do with it as I please.
If Google removes the ability to extract it all to a third party then you're
locked into Google forever. Removing the ability because some people aren't
responsible isn't a good argument.

~~~
dredmorbius
False dichotomy.

It's possible to allow for extraction of user data (Google actually support
this quite well) and _not_ for sleezy third-party services to fool ... gifted
and talented developers, let alone the semi-literate, technically-phobic,
Alzheimers-addled, visually disabled, or others, for whom this sort of crap is
a very real and constant source of frustration.

I support a group of such users. While they can frustrate me with their lack
of understanding, the crap interfaces, requests, and systems they're presented
with frustrate me far, far, far, far more.

------
taurath
This is truly a big deal, and also effects Android. The system of "privacy
checking" doesn't work when the consumer has almost zero information about how
they will actually use the information. Its a binary "give access to
everything" or "you can't use this app" which creates an arms race. App
updates can then ask for more and more permissions. More importantly, even a
misclick can easily give access rights away to your entire email inbox, phone
contacts, call history or any other information you might consider private.

~~~
chii
The way to fix it is for Google to let you change what data appears to an app
after the fact. The app asking for permission will never get denied. They'd
get fake data if the user didn't give permission.

------
tobyjsullivan
I can't agree with this author - at least their argument that "the bigger
problem here lies with how Google makes this possible: 1) At all..."

If this wasn't possible at all, this product couldn't exist in it's current
form. And clearly, at some point, the author saw value in this product enough
to give it a shot.

Do I agree Google should make it extra clear when you are signing over
permission for unusually liberal access to your data? Absolutely.

~~~
dredmorbius
If the 1) the product couldn't exist in its (not "it's") current form, and 2)
perceptions of value were based on what was a false understanding of the
product and how it worked, then that perception of reality is false, and the
product simply shouldn't exist.

------
dredmorbius
The mistake was _not_ "all yours", and Fleep (and Google) are failing to
disclose how, when, where, and most importantly, _why_ data are being used.

Quite arguably, Fleep gained access to data _you held_ which was not _yours to
provide_ \-- email content and contact information for those with whom you've
corresponded.

This is among the reasons I'm increasingly limiting my use of electronic
communications _at all_. The risks, reality, frequency, control, and
disclosure of such cases is simply too high a negative to utilise them.

Yes, this means that I not only don't carry a smartphone, but by and large
don't carry a mobile phone at all -- a regression to pre-2000 states of comms.

This is a case of race-to-the-bottom behavior, and bad (or simply grossly
incompetent) actor behavior poisoning the well for all.

It's an exceptionally strong argument to replace, as rapidly as possible, the
present set of hosted online services with privately provisioned ones.
Sandstorm.io, FreedomBox, and similar concepts can't hit prime time too soon.

If Google knows what's good for it, it should support this as well. Its
choices are having _some_ access to user time and committment, or none.

(Google's previous behaviors mean I've largely left it behind for its namesake
service. I interact with it principally through pseudonymous accounts, though
I'm aware these offer fairly thin protections against a determined actor.)

As Cory Doctorow has said, data are the radioactive waste of the current age.
My formulation is that _data are liability._

Overreaching privacy-invading tools are bad news waiting to happen.

------
Gratsby
Taking advantage of end user provided permissions seems to be the norm instead
of the exception.

A few scandals have risen because of it. I remember a popular "free"
calculator app that was sending GPS data.

Oddly, most people don't seem to care. They'd rather give up their entire
picture collection than spend $2 on a permissions restricted app.

Having more fine-grained restrictions than we already do won't solve the
problem. Most people will simply accept the default "give this application
permissions to do everything" right out of the gate. I'd be surprised if even
close to 5% of the people on facebook have reviewed the applications they've
given permission to in the last 12 months.

~~~
fixermark
Be wary of confirmation bias.

How many stories of the form "User-provided permissions used responsibly,
nothing interesting to report" do you _expect_ to see in the news?

~~~
Gratsby
I would read the shiznit out of that article.

------
rmetzler
Reading the title I thought it was about the GMail address which you can't
change afterwards. I regret not getting my real name in my early twenties.

~~~
ianamartin
Oh, don't feel so bad about that. Pretty much every real name gets hit with so
much spam now, it's not even funny. Or if it's not actual spam, it's people
using your email for stuff they don't care about, like a throwaway account.

I'm getting pretty close to just not using my gmail account any more.

------
Chefkoochooloo
Wow, information is coming at an insane cost. Why do companies have to be so
incredibly sneaky when trying to gather your digital information? There really
needs to be laws put in place. Technology is growing at too fast a pace and we
need laws in place to protect our privacy.

~~~
ccvannorman
Sounds like a great idea, but unfortunately technology moves 100x the speed of
law, so by the time any laws are passed they won't matter.

In other words, if you care, make a technological solution, not a legal one,
because the right laws will be too little too late.

------
CrystalGamma
… only applies to GMail users. And here I thought this was relevant for me. I
was almost shocked on reading the title.

------
wdr1
When he says Google shouldn't make this possible at all, I'm not sure what
he's asking for?

Isn't the alternative basically vendor lock-in?

Or that this would mean disabling things like IMAP & POP?

Fleep sounds like a shitty service from the description, but at some point
user's need to take responsibility for their actions, no?

~~~
BinaryIdiot
> When he says Google shouldn't make this possible at all, I'm not sure what
> he's asking for?

I thought maybe he was asking for something like: 1\. Request password before
allowing access (which seems reasonable if the user hadn't entered it
recently; I mean you have to do this for almost every other security setting
in your account)

2\. Allow finer control over the data. Say not allow it to download the entire
corpus or only access to meta data, etc (though that can be probably too
complicated for a regular user). Maybe this simply means different permissions
when they want full access versus recent / continual access? I could see that
being possible more descriptive.

------
Zigurd
The only way to really fix it is either...

1\. Don't allow 3rd party mail apps

2\. Encrypt mail and provide open, verifiable clients and open server
protocols.

Google make only a little money from my GMail account. I'd gladly pay them
twice that for a strongly encrypted email system that provides infrastructure
for key exchange with a web of trust.

~~~
fixermark
In this specific context, there was a third way to fix the issue:

3\. Click "Deny" when the app explicitly has Google's OAuth flow ask if you
want to give it permission to read, create, and delete all of your email.

~~~
Zigurd
Well, of course. One could ask "What did he think was going to happen when he
installed a 3rd party mail reader?"

Thing is, encrypted mail and trusted clients means you could store your email
at supersketchy.ru and it wouldn't matter. It's the way to make those kinds of
choices safe, Or, rether, just having permissions doesn't security is
adequate.

------
codeulike
Google Mistake is such a good name for a product. Not sure what it would do,
but it's a good name.

~~~
dredmorbius
It would save time.

------
ishener
It's an app to manage your emails. What did you expect for christ's sake?

------
boto3
This is insane. I have Google/FB test accounts that I use to try out new
products. I am now inclined to set up offline mail to make sure that my emails
are not readily available to anyone but me. Of course Google still archives my
removed emails but I think their policy is to remove them after a certain
period. Can someone at Google confirm?

~~~
r3bl
How about feeling inclined to actually read the permissions that the service
is requesting from you and deciding upon that?

Same thing applies on smartphones too. If an app requests a lot of permissions
that do not look like a legit part of the service, stay the hell away from it.
A couple of examples:

    
    
        * Facebook Messenger does not need access to my location and call logs.
        * The main Facebook app does not need access to my SMS.
        * Signal does not need access to my calendar.
    

Solution: I have none of these apps on my phone.

Edit: a couple more examples:

    
    
        * WhatsApp does not need to read my Google services configurations.
        * Viber does not need access to my Bluetooth.
        * Snapchat does not need access to my audio settings.
        * Instagram does not need to run at startup.
        * Microsoft Word does not need to have the ability to set an alarm.

~~~
fishanz
Android is tricky. I'm not an expert at their permissions settings but it
seems that some of them are worded alarmingly for over-reaching yet
justifiable permissions. I'm thinking for example (not one you listed, but..)
that displaying push notifications immediatly when the phone is not in use
requires a permission to "prevent the phone from sleeping"...

------
pinkunicorn
This is exactly why I change email addresses every 1/2 years. I've forwarding
setup from 3 of my old addresses to my current address and for all financial
transactions I only use my current email address.

~~~
lern_too_spel
So when you want to look up an old email, you have to remember which three
month period it was in _and_ which email address that corresponds to? When you
have conversation that spans multiple periods, you have to do this multiple
times? This cure is worse than the disease.

~~~
dredmorbius
Local mail archives are a hell of a drug.

Using mutt or offlineimap:

1\. Configure POPS/IMAPS access to the account, use Maildir format locally.

2\. Download all messages.

3\. Copy your saved messages to another location.

4\. Delete all email on server.

Local search tools can then be used to access that archive.

------
mattbgates
Scary.

