That's surprising, it's an open standard that plenty of open source apps do implement, isn't it? Is it just that the apps you're using happen to not have support for it?
Which apps are you using that you wouldn't be able to use?
One example, FairEmail on Android. It supports Google Oauth but ONLY if you use the Google Play version -- not F-Droid -- due to other "security" features from Google.
Oauth may be an open standard, but it gives Google control over the clients you can use. If Google decides to one day ban your client of choice, you're SOL. Given their recent decision to ban specific browsers from accessing Google services, I'm not hopeful.
I wonder though how many open source apps will go through the mandatory security audit process (15-75K annually) since IMAP via OAuth is a restricted API scope [1].
That said - from "What app types are not applicable for verification?" there are the following exceptions:
> Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in.
> Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications.
> Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains.
Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway.
So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions.
If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file.
So then there's just the question of actually making OAuth support exist in whatever apps employees want to use.
EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch):
> Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).
Does mutt support oauth yet? If not, this will be the last straw for G Suite from me. I can sort-of understand turning off "less secure" apps in consumer Gmail, but forcing "security" requirements for private, paid enterprise accounts is ludicrous. Time to find a provider which treats me as a grown-up capable of independent security risk judgement.
For email you can import your gmail account via IMAP to fastmail. I have a custom domain so it's been awesome to finally serve mail from it and a relatively painless transition.
The problem I've been having with this is that most of these alternative providers don't offer much space, even on their most expensive plan. My GMail storage use is around 300GB right now. Sure I could probably clean that up if I wanted to, but I don't. I'd rather just pay for 400GB of space, with options to go much higher as time goes on.
Fastmail's most expensive plan offers 100GB, and most alternative providers seem to max out in this range (or lower). Mailbox.org is the only thing that I've found that is (or at least claims to be) privacy-respecting that offers lots of space.
On a side note, given some of the anti-privacy and anti-encryption legislation passed in Australia in the last couple years, I'm not sure Fastmail would be my first choice to replace Google.
You can buy more storage at Fastmail: it's the same cost as an extra user to add the same amount of storage. e.g. for a Professional account, you can add an extra 100 GB storage for an extra $9/month.
Gmail reports a combined storage with Drive etc., so you may find not all of your quota use is actually email.
You can try Migadu, which is priced by number of outgoing emails per day and not by storage or domains or mailboxes. The company is in Switzerland, but it uses a data center in France. I personally have very limited experience with the service, and cannot give either a strong yes or no for it.
eh? using your g suite password for email is a huge mistake. the problem isn't the password auth per se, it's that the permissions you grant if the password is exposed are vast, not limited to just sending/receiving email.
that said, why they insist on turning it off, rather than just use ASPs, is a bit unfriendly. but it's definitely not because they are treating you as a child.
Not if the sole purpose of that account is email and nothing more. I should be able to make decisions about what an account is used for and how to authenticate, even if that's the "wrong" or "less-secure" decision.
That's a complex (more than necessary) product roadmap, to support the negligible percentage of users that can actually use it "securely". When it comes to security, the typical user leans towards making the wrong choices given the freedom to do so.
You also aren't being denied the capability. There are seemingly innumerable mail hosting services that will let you do IMAP with normal password. You can also host it yourself, using gmail as relay service if you desire.
This seems like a transparently disingenuous way to further platform lock-in using security as a pretext. I question the level of "security" this provides, especially given that there's little difference on the client side from using an app-specific password and using an OAuth2 bearer token, except the latter is more annoying to acquire and use. Either way, it's a small blob of text managed via Gsuite that the user has to have on their device and that an attacker could steal.
from the client side, yes. but from their side, ASPs are a codebase they apparently would like to free themselves from. it's understandable, given that most client apps by far (by %use) support oauth.
oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.
The blogpost mentions that an attacker could use a normal username and password to access your account via some app that they control, and this is a channel they're trying to get rid of. Even if all that OAuth does is meaningfully enforce the "app-specific" part (including providing the user with a workflow to authorize app access or reject it) this is a meaningful improvement in security.
Except app-specific passwords are not app-specific at all. You maybe have a calendar app, but then someone steals that and uses it to read email, and delete account recovery emails sent, owning you to hell and back.
ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much.
I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.
Perhaps they could support app specific passwords that behave similar to bearer tokens, with a scope that limits API access, etc. Not saying this is a good thing. OAuth is simple enough to set up.
If you want to add an email alias to GMAIL the merge step requires less secure access. I was unable to merge two gmail accounts last week because google kept blocking me thinking my account was getting hacked.
Any company based in Russia, China (or any other regime perceived as authoritarian and lacking in the rule of law department) is going to struggle to get on the short-list of "organizations to trust with the master keys to your whole online life".
It’s better not to use such restrictive service which push you to the corner. Let the customer decide whether they want oauth or password authentication, but we are google why should we care for customer, you use us so you need to comply with our demands.
My feeling is all this are ways to increase the revenue of google and they are just doing the same Microsoft and oracle was known for. This is called circle of life, it’s just instead of licenses they are locking users with API’s and proprietary development. Now in hindsight old Microsoft, oracle looked better compared to today’s google. In old days anyone can develop for win32 api and did not need Microsoft’s audit and charge for approval. Obviously today’s Microsoft is doing same as google so none is better.
This whole thing is nothing to do with security but mostly a way to lock in users into gsuite, once you design your apps without login and password with oauth specific workflow and approval by google, it will be hard for anyone to justify a change.
This is going to be a bit cumbersome for those using Thunderbird or Mail.app (on Mac) or Outlook (Mac) over (plain) IMAP — the document instructs users to remove and re-add these accounts. That would mean (in my understanding, at least of Thunderbird) re-downloading all mails and folders once again into the newly setup account in the client. Those who use only a single device are probably going to have to schedule this appropriately to avoid having no visibility into mails for sometime.
36 comments
[ 2.6 ms ] story [ 71.8 ms ] threadMy org will be eyeing alternatives when this rolls out.
Which apps are you using that you wouldn't be able to use?
Oauth may be an open standard, but it gives Google control over the clients you can use. If Google decides to one day ban your client of choice, you're SOL. Given their recent decision to ban specific browsers from accessing Google services, I'm not hopeful.
[1] https://support.google.com/cloud/answer/9110914?hl=en
That said - from "What app types are not applicable for verification?" there are the following exceptions:
> Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in.
> Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications.
> Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains.
Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway.
So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions.
If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file.
So then there's just the question of actually making OAuth support exist in whatever apps employees want to use.
EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch):
> Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).
https://support.google.com/accounts/answer/185833?hl=en
https://luxing.im/mutt-integration-with-gmail-using-oauth/
fastmail.fm seems well regarded. (it's not on the first page of results above)
Fastmail's most expensive plan offers 100GB, and most alternative providers seem to max out in this range (or lower). Mailbox.org is the only thing that I've found that is (or at least claims to be) privacy-respecting that offers lots of space.
On a side note, given some of the anti-privacy and anti-encryption legislation passed in Australia in the last couple years, I'm not sure Fastmail would be my first choice to replace Google.
Gmail reports a combined storage with Drive etc., so you may find not all of your quota use is actually email.
that said, why they insist on turning it off, rather than just use ASPs, is a bit unfriendly. but it's definitely not because they are treating you as a child.
You also aren't being denied the capability. There are seemingly innumerable mail hosting services that will let you do IMAP with normal password. You can also host it yourself, using gmail as relay service if you desire.
I'm not saying it's perfect, but it's what I've used to read and write email every day for the last year or two, so it's past that point.
Patches welcome. :-)
oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.
ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much.
I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.
https://developer.microsoft.com/en-us/office/blogs/end-of-su...
https://connect.yandex.com/pdd/
My feeling is all this are ways to increase the revenue of google and they are just doing the same Microsoft and oracle was known for. This is called circle of life, it’s just instead of licenses they are locking users with API’s and proprietary development. Now in hindsight old Microsoft, oracle looked better compared to today’s google. In old days anyone can develop for win32 api and did not need Microsoft’s audit and charge for approval. Obviously today’s Microsoft is doing same as google so none is better.
This whole thing is nothing to do with security but mostly a way to lock in users into gsuite, once you design your apps without login and password with oauth specific workflow and approval by google, it will be hard for anyone to justify a change.
Money can buy position like it can on google search.