Update on browser standards
https://freesoftware.org.au/blog/update-on-browser-standards/ Update on browser standards An update on Googles browser standards About a year ago we warned about the issues of the Chromium/Blink web rendering engine and how Google is essentially dictating the direction of web technology to their advantage. https://freesoftware.org.au/blog/on-microsoft-edge-and-the-chromium-engine/ It now appears via multiple sources that this is becoming that case at least for their direct web services. https://www.bleepingcomputer.com/news/google/google-now-bans-some-linux-web-... The short take on the story is that a lot of free software browsers, some of which happen to have provided the technology base of Chrome, are now being denied access under the guise of 'security'. While these browsers combined usage makes up less than 0.1% of Internet traffic, that Google has gone out of the way to deny the users access is a dangerous precident. To make matters worse, if you make these browsers report to Google that they are 'Google Chrome' - Googles own proprietary browser, then these sites work as intended making the whole idea look more preposterous. While this warning has not been seen universally by users and it appears to be in the trail stage, this is a very worrying for the free and open internet and the software that we use on it. Essentially the software maker, being Google, is able to dictate what people can use online using their software platform and online websites. Google has now made a few actions that are determined to control how the internet is used for their own gain. Chrome is designed to dictate the technology base that people have to use, by having technology that can only be rendered properly by their browser, this sets the standards by which most web developers will aim to hit. This is to the detriment of anyone using non-google technology. It may be small user base browsers today, in future it might be things like Firefox and eventually all non-Chrome browsers - even ones that use the same 'open-source' code base. This is the situation we found the internet in at the end of the last decade with Microsoft's Internet Explorer dominating how internet technology would be shaped. It took the efforts of Mozilla and the Firefox project to finally break free from this situation. Google is also directly dictating to web content providers to use their systems such as AMP technology so that run websites on their servers, making them load faster than they typically would and this is enhanced when using their browsers so that any competition looks bad by comparison. Google uses many other techniques but these main ones are used to direct you into Googles profit machine at the expense of your choice of software and thus your privacy. Over the last few years it has become apparent that more web browser technology is being dictated down from Google and less about letting technology find its own place via dis-census. That is, it is being designed rather than evolving. Technology is being used to squeeze out competition and free software based browsers are clearly being targeted. Google has misused API's to make performance run slowly on other browsers, dictated how DRM should be implemented online so that others cannot support the same standards and in general just made a technology target that favors it over other agreed standards. The best solution to a problem is to prevent the problem in the first place. That means having to avoid using these controlling technologies and to support those that have your back covered. By supporting free software and open standards that is what you are doing. Every time you use a Free-software browser and a website doesn't work properly, let the sites admin know about it. If they don't want to fix it - don't use it. You are better off not being forced into a compromised position. In the coming decade this will only get worse. With the increasing profit needs of Google, increasing operations costs, decline in return on computer hardware improvements, ever increasing demand so of users and the apathy of those same users that makes them accept these changes with little questioning, we are slowly walking down a road that is very difficult to recover from. It took almost a decade to turn it around last time with Firefox and that was through the arrogance of Microsoft not keeping their eye on the ball and assuming that they could never fall. This time it may not be possible as it is a very deliberate and targeted attack on users choices. If we don't try to fight this then we have lost already. If we wait until it is unbearable, it will be near impossible to overcome in any meaningful way. Michael Verrenkamp -- Committee Member Free Software Australia/Melbourne Advocating for freedom in computer software. www.freesoftware.org.au
"Michael Verrenkamp" <jabjabs@fastmail.com.au> writes:
While this warning has not been seen universally by users and it appears to be in the trail stage, this is a very worrying for the free and open internet and the software that we use on it. Essentially the software maker, being Google, is able to dictate what people can use online using their software platform and online websites.
While not directly related to web browsers, I am very concerned with an email I received from Google today saying that they intend to phase out support for username/password authentication for LSA ("less secure apps") using protocols such as IMAP, and require using OAuth authentication instead. Presumably this is another way of saying they plan to phase out application specific passwords too. I am not aware of any open source IMAP client software that can use OAuth. They may say they are doing this in the name of security, but to me it looks very much like a movement against open source software. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Tue, Dec 17, 2019 at 05:12:08PM +1100, Brian May wrote:
I am not aware of any open source IMAP client software that can use OAuth.
Although I haven't tried yet, I'm pretty sure Thunderbird and offlineimap support it. Thunderbird 38.0beta release notes (current version is 68.3.0): https://www.thunderbird.net/en-US/thunderbird/38.0beta/releasenotes/ Using Offlineimap with the Gmail IMAP API: https://hobo.house/2017/07/17/using-offlineimap-with-the-gmail-imap-api/ I received the e-mail too (I have to use a G Suite address at my workplace) and I think it's annoying that I'll need to reconfigure everything. I don't like GMail in general, but I don't expect I'll need to switch to a different set of applications at work when the change takes place mid 2020. Cheers, Adam
On Wed 18 Dec 2019 at 13:00:23 +1100, Adam Bolte wrote:
On Tue, Dec 17, 2019 at 05:12:08PM +1100, Brian May wrote:
I am not aware of any open source IMAP client software that can use OAuth.
Although I haven't tried yet, I'm pretty sure Thunderbird and offlineimap support it.
Thunderbird 38.0beta release notes (current version is 68.3.0): https://www.thunderbird.net/en-US/thunderbird/38.0beta/releasenotes/
Using Offlineimap with the Gmail IMAP API: https://hobo.house/2017/07/17/using-offlineimap-with-the-gmail-imap-api/
I can confirm for OfflineIMAP, using this [0] to get the initial token. This is what I have in the config [Repository GMail] type = Gmail remoteuser = address@gmail.com # See [0] # [0] https://github.com/OfflineIMAP/offlineimap/blob/master/offlineimap.conf#L761: oauth2_request_url = https://accounts.google.com/o/oauth2/token oauth2_client_id = XXX.apps.googleusercontent.com oauth2_client_secret = XXX oauth2_refresh_token = 1/XXX maxconnections = 3 # See [1] # [1] https://github.com/OfflineIMAP/offlineimap/issues/573#issuecomment-417049116 ssl_version = tls1_2 ssl = yes sslcacertfile = /etc/ssl/certs/ca-certificates.crt subscribedonly = yes folderfilter = lambda foldername: foldername in ('[Gmail]/Drafts', '[Gmail]/All Mail') or not foldername.startswith('[Gmail]') nametrans = lambda folder: re.sub(r'^\[Gmail]/', r'', fo On Android, I use a fork of K9, called PeP, which also supports autocrypt. [0] https://github.com/google/gmail-oauth2-tools -- Olivier Mehani <shtrom+fsau@ssji.net> PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.
Adam Bolte <abolte@systemsaviour.com> writes:
On Tue, Dec 17, 2019 at 05:12:08PM +1100, Brian May wrote:
I am not aware of any open source IMAP client software that can use OAuth.
Although I haven't tried yet, I'm pretty sure Thunderbird and offlineimap support it.
Thunderbird 38.0beta release notes (current version is 68.3.0): https://www.thunderbird.net/en-US/thunderbird/38.0beta/releasenotes/
Using Offlineimap with the Gmail IMAP API: https://hobo.house/2017/07/17/using-offlineimap-with-the-gmail-imap-api/
I received the e-mail too (I have to use a G Suite address at my workplace) and I think it's annoying that I'll need to reconfigure everything. I don't like GMail in general, but I don't expect I'll need to switch to a different set of applications at work when the change takes place mid 2020.
Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Thu, Dec 19, 2019 at 07:39:57AM +1100, Brian May wrote:
Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch.
If offlineimap isn't your thing, getmail looks like it'll do the job, at least at a glance. http://pyropus.ca/software/getmail/configuration.html#retriever-parameters
Adam Bolte <abolte@systemsaviour.com> writes:
On Thu, Dec 19, 2019 at 07:39:57AM +1100, Brian May wrote:
Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch.
If offlineimap isn't your thing, getmail looks like it'll do the job, at least at a glance.
Last time I looked, getmail upstream development was dead, and only supported Python 2.7. So I switched from getmail to fetchmail. It also had problems handling timeout errors from a dead SSL connection, and would hang for ever. Not sure if that is still the case or not. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Thu, Dec 19, 2019 at 05:21:43PM +1100, Brian May wrote:
Last time I looked, getmail upstream development was dead, and only supported Python 2.7. So I switched from getmail to fetchmail. It also had problems handling timeout errors from a dead SSL connection, and would hang for ever.
Not sure if that is still the case or not.
No idea about the dead SSL connection issue. I haven't used it long enough to properly evaluate it. Most of my experience is with offlineimap (with Mutt). The getmail changelog would suggest it is still supported, with the most recent release being from late August. http://pyropus.ca/software/getmail/CHANGELOG It is still available in Debian sid and buster, and there is some interest on their mailing list in migrating getmail to Python 3 to keep it in Debian (and to drop "historical cruft and backwards-compatibility code"). It might be worth a look and perhaps giving them a hand. https://marc.info/?t=157365903900002&r=1&w=2
Resurrecting old thread. Adam Bolte <abolte@systemsaviour.com> writes:
The getmail changelog would suggest it is still supported, with the most recent release being from late August.
Are there any alternatives for getmail? It looks like upstream are not willing to Support Python 3, and as such it may not get into the next release of Debian :-( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936604 -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Adam Bolte <abolte@systemsaviour.com> writes:
On Thu, Dec 19, 2019 at 07:39:57AM +1100, Brian May wrote:
Is there anything you know of similar to fetchmail? I currently am using fetchmail + notmuch.
If offlineimap isn't your thing, getmail looks like it'll do the job, at least at a glance.
Looks like instructions are here: http://www.bytereef.org/howto/oauth2/getmail.html I recently moved from getmail to fetchmail, guess I should move back again and try getmail again. I notice the instructions say "The resulting setup is not more secure than a regular getmailrc with 0600 permissions." - which is no surprise really. I can understand Google not wanting user's to authenticate to IMAP with their standard username/password, but if it is true that application specific passwords won't work either, that seems excessive to me. I have a user who is using gmail with Outlook 2007. They might be affected more so then me. I have told said user they will need to upgrade to Outlook 2019 or Office 365, or use gmail from the website, it looks like Outlook 2007 does not support OAUTH from what I can tell. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Thu, Jan 02, 2020 at 06:13:07PM +1100, Brian May wrote:
I notice the instructions say "The resulting setup is not more secure than a regular getmailrc with 0600 permissions." - which is no surprise really.
As I understand it, there is arguably a *slight* security improvement in the initial application setup. If the user has two-factor authentication enabled, it would be difficult for someone who learns the password to access e-mails - they would need to have a copy of either the 2FA device, or the security token. I suspect the real reason Google is forcing this is because they want to help make using client applications less convenient over the web interface.
I have a user who is using gmail with Outlook 2007. They might be affected more so then me. I have told said user they will need to upgrade to Outlook 2019 or Office 365, or use gmail from the website, it looks like Outlook 2007 does not support OAUTH from what I can tell.
Maybe you could put in a plug for Thunderbird or something else that's free software, since it sounds like the user will have to upgrade anyway. Better to make it a true upgrade. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 7/1/20 11:57 am, Adam Bolte wrote:
On Thu, Jan 02, 2020 at 06:13:07PM +1100, Brian May wrote:
I notice the instructions say "The resulting setup is not more secure than a regular getmailrc with 0600 permissions." - which is no surprise really.
Application passwords were, arguably, less secure than what you could actually use as a password and you lost the 2FA aspect of the login. So, lots of room for improvement.
As I understand it, there is arguably a *slight* security improvement in the initial application setup. If the user has two-factor authentication enabled, it would be difficult for someone who learns the password to access e-mails - they would need to have a copy of either the 2FA device, or the security token.
If you know the secret to generate the codes, you don't need any security token. Of course you need the username (email address generally) AND the actual password as well. TOTP, as per "Google Authenticator" and other implementations is still better than plain username and password, but it isn't bulletproof.
I suspect the real reason Google is forcing this is because they want to help make using client applications less convenient over the web interface.
Perhaps, but adding security can add all sorts of "other" risks or pain.
I have a user who is using gmail with Outlook 2007. They might be affected more so then me. I have told said user they will need to upgrade to Outlook 2019 or Office 365, or use gmail from the website, it looks like Outlook 2007 does not support OAUTH from what I can tell.
I just wish people would stop using Google mail services altogether, same with Outlook (hotmail / m$, Yahoo and other bad providers.
Maybe you could put in a plug for Thunderbird or something else that's free software, since it sounds like the user will have to upgrade anyway. Better to make it a true upgrade. :)
Sadly too many people / business are happy to keep paying M$ taxes on everything with subscription services; hence why Microsoft is taking in considerably more income in this area, so much so, that they care less about Windows license fees as anyone using Windows is more likely to be using O365 and/or other pay for services for their lifetime. All in all, lots of pain points ... enough said :( A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXhQmpgAKCRCoFmvLt+/i +2otAP4rwrk3C+8lJwm9U1yL+YX9cSpcvBBB+UlnZ5OACP5sRgD/bpQCz0RlR9Ht f/OpJzkl+JwryjjNtDQQ24WczWZuJaY= =DVK2 -----END PGP SIGNATURE-----
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
Application passwords were, arguably, less secure than what you could actually use as a password and you lost the 2FA aspect of the login. So, lots of room for improvement.
No, not really. e.g. if you look at the getmail implementation, it is still just storing a secret (token) stored on the filesystem that is completely usable without any 2FA. You do need 2FA to obtain the original token (just like you need 2FA to obtain an application specific password), but once you have that there is no need for 2FA anymore. Actually, two secrets now, because we also need to store an application secret too. On the plus side, this token does expire, and needs to be regularly renewed. Plus the secret is very much restricted in what it can do. So I believe somebody stealing my mail credentials can't tamper with my Google drive for example. On the negative side however, it means getmail's gnomekeyring (lets pretend it isn't already broken) does not work anymore, and secrets need to be in the file system in a place accessible by all applications. I suspect the need to register the application (to obtain the oauth application credentials) with Google might have implications for open source software, especially if you don't have domain admin rights (e.g. workplace domain). Although I might be wrong here. It is possible to register an OAuth application in Google that works across multiple domains, however that appears to require a manual approval process, and I am a bit suspicious (???) this might not be an option for open source applications. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 8/1/20 7:54 am, Brian May wrote:
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
Application passwords were, arguably, less secure than what you could actually use as a password and you lost the 2FA aspect of the login. So, lots of room for improvement.
No, not really. e.g. if you look at the getmail implementation, it is still just storing a secret (token) stored on the filesystem that is completely usable without any 2FA. You do need 2FA to obtain the original token (just like you need 2FA to obtain an application specific password), but once you have that there is no need for 2FA anymore.
I think you misunderstand my views on Google authentication. If you login to your Google account, then you can add in 2FA using Google Authenticator app or anything compatible with TOTP (I use a python script myself). When you set up 2FA, at least way back (not sure if it any different now), you could setup "application passwords" for things like Thunderbird or something else that has to login to your Google account. It is these passwords that use a fixed length and a small number of hexadecimal characters (so only 16 base characters, not even close to base64 or the printable character set and forget about using non-printable characters). If you want a secure password, then long is great, but using a range of characters or perhaps better still a long list of dice words so it can be easily typed. Anywhere you have plain text tokens or passwords stored in the file system, then you had better take care of those well. Use FDE (full disk encryption and/or ensure proper use of file permissions, etc). btw my use of a Google account or rather accounts is more for testing purposes or for Android devices -- I should probably be using F-driod though instead of the play store, but that's a whole different story and can of worms ;) Cheers A. -----BEGIN PGP SIGNATURE----- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXhcZpwAKCRCoFmvLt+/i +yk/AQCUJupTt81Pt3EAV0H4qBj7HcicQfjpf02noiUFuHWr4wEAsuKRpgDfyoHM i07apxT5MzESBu0CUA/v1uTMprIWeWE= =nKnF -----END PGP SIGNATURE-----
Hi Brian, Are you able to provide a quote of this email from Google or any website it links to? I don't use Gmail any more, so haven't received it, but am interested in its contents. In particular, does it state it's removing *all* password auth from IMAP, or just that you'd need to use app passwords instead of your Google password? I definitely think the latter makes sense; the former is going a bit far IMO. On Tue, Dec 17, 2019, at 17:12, Brian May wrote:
"Michael Verrenkamp" <jabjabs@fastmail.com.au> writes:
While this warning has not been seen universally by users and it appears to be in the trail stage, this is a very worrying for the free and open internet and the software that we use on it. Essentially the software maker, being Google, is able to dictate what people can use online using their software platform and online websites.
While not directly related to web browsers, I am very concerned with an email I received from Google today saying that they intend to phase out support for username/password authentication for LSA ("less secure apps") using protocols such as IMAP, and require using OAuth authentication instead. Presumably this is another way of saying they plan to phase out application specific passwords too.
I am not aware of any open source IMAP client software that can use OAuth.
They may say they are doing this in the name of security, but to me it looks very much like a movement against open source software. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ _______________________________________________ Free-software-melb mailing list Free-software-melb@lists.softwarefreedom.com.au https://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-...
Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/
-- Regards, Matt Cengia (he/him/his)
"Matt Cengia" <mattcen+softwarefreedom@mattcen.com> writes:
Hi Brian,
Are you able to provide a quote of this email from Google or any website it links to? I don't use Gmail any more, so haven't received it, but am interested in its contents.
In particular, does it state it's removing *all* password auth from IMAP, or just that you'd need to use app passwords instead of your Google password? I definitely think the latter makes sense; the former is going a bit far IMO.
I am not exactly sure how much of this I have understood. It does seem clear though OAuth only. Except maybe for SMTP, which is odd. I personally don't see how OAuth is going to be any more secure then an application specific password. === cut === Beginning June 15, 2020, non-Google apps that use only a password to access Google accounts will no longer be supported. Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported. Dear Administrator, We're constantly working to improve the security of your organization's Google accounts. As part of this effort, and in consideration of the current threat landscape, we'll be turning off access to less secure apps (LSA) — non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account. Access to LSAs will be turned off in two stages: June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts. What do I need to do? To continue using a specific app with your G Suite accounts, users in your organization must switch to a more secure type of access called OAuth. This connection method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (included below) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also included below. MDM configuration If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below: June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth. Other less secure apps For any other LSA, ask the developer of the app you are using to start supporting OAuth. If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth. Scanners and other devices No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth. User instructions If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect. Email If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. Alternatively you can use G Suite Sync for Microsoft Outlook. If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you'll need to remove and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth. Mac OS iOS mail app view Mac OS mail app view iOS Calendar If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you'll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more Contacts If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you'll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. Note: If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth, or ask your admin to contact the supplier of your app and request that they add OAuth as a way of connecting your Google account. Developer instructions To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. How can I get help? If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552. Thanks for choosing G Suite. —The G Suite Team Was this information helpful? YES NO © 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 You have received this important update about your G Suite account because you designated this email address as a primary or secondary contact for mandatory service communications in your Google Admin console profile. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Ah, thanks for that. Here's a link to the same announcement on the Google Blog: https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-u... It does seem odd that they'd be deprecating App passwords too, but it certainly sounds like they might be. On Thu, Dec 19, 2019, at 17:24, Brian May wrote:
"Matt Cengia" <mattcen+softwarefreedom@mattcen.com> writes:
Hi Brian,
Are you able to provide a quote of this email from Google or any website it links to? I don't use Gmail any more, so haven't received it, but am interested in its contents.
In particular, does it state it's removing *all* password auth from IMAP, or just that you'd need to use app passwords instead of your Google password? I definitely think the latter makes sense; the former is going a bit far IMO.
I am not exactly sure how much of this I have understood. It does seem clear though OAuth only. Except maybe for SMTP, which is odd.
I personally don't see how OAuth is going to be any more secure then an application specific password.
=== cut ===
Beginning June 15, 2020, non-Google apps that use only a password to access Google accounts will no longer be supported.
Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported.
Dear Administrator,
We're constantly working to improve the security of your organization's Google accounts. As part of this effort, and in consideration of the current threat landscape, we'll be turning off access to less secure apps (LSA) — non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account.
Access to LSAs will be turned off in two stages:
June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts.
What do I need to do?
To continue using a specific app with your G Suite accounts, users in your organization must switch to a more secure type of access called OAuth. This connection method allows apps to access accounts with a digital key instead of requiring a user to reveal their username and password. We recommend that you share the user instructions (included below) with individuals in your organization to help them make the necessary changes. Alternatively, if your organization is using custom tools, you can ask the developer of the tool to update it to use OAuth. Developer instructions are also included below.
MDM configuration
If your organization uses a mobile device management (MDM) provider to configure CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) profiles, these services will be phased out according to the timeline below:
June 15, 2020 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for new users. February 15, 2021 - MDM push of IMAP, CalDAV, CardDAV, and Exchange ActiveSync (Google Sync) will no longer work for existing users. Admins will need to push a Google Account using their MDM provider, which will re-add their Google accounts to iOS devices using OAuth.
Other less secure apps
For any other LSA, ask the developer of the app you are using to start supporting OAuth. If you use other apps on iOS or MacOS that access your G Suite account information through only a password, most access issues can be resolved by removing then re-adding your account. When you add it back, make sure to select Google as the account type to automatically use OAuth.
Scanners and other devices
No change is required for scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails. If you replace your device, look for one that sends email using OAuth.
User instructions
If you are using an app that accesses your Google account with only a username and password, take one of the following actions to switch to a more secure method and continue to access your email, calendar, or contacts. If you do not take one of the following actions, when LSA access is discontinued after February 15, 2021, you will begin receiving an error message that your username-password combination is incorrect.
If you are using stand-alone Outlook 2016 or earlier, move to Office 365 (a web-based version of Outlook) or Outlook 2019, both of which support OAuth access. Alternatively you can use G Suite Sync for Microsoft Outlook. If you are using Thunderbird or another email client, re-add your Google Account and configure it to use IMAP with OAuth. If you are using the mail app on iOS or MacOS, or Outlook for Mac, and use only a password to login, you'll need to remove and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth.
Mac OS iOS
mail app view Mac OS
mail app view iOS
Calendar
If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you'll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more
Contacts
If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you'll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth.
Note: If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth, or ask your admin to contact the supplier of your app and request that they add OAuth as a way of connecting your Google account.
Developer instructions
To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps.
How can I get help?
If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552.
Thanks for choosing G Suite.
—The G Suite Team
Was this information helpful? YES NO
© 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043
You have received this important update about your G Suite account because you designated this email address as a primary or secondary contact for mandatory service communications in your Google Admin console profile. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
-- Regards, Matt Cengia (he/him/his)
On Tue, Dec 17, 2019 at 5:12 PM Brian May <brian@linuxpenguins.xyz> wrote:
email I received from Google today saying that they intend to phase out support for username/password authentication for LSA ("less secure apps") using protocols such as IMAP, and require using OAuth authentication instead. I am not aware of any open source IMAP client software that can use OAuth.
I've been using OAuth with Thunderbird for IMAP to gmail, as my workplace has been enforcing that and disabled app password access. I vaguely remember having to upgrade Thunderbird or something to get it going. Glenn
participants (7)
-
Adam Bolte -
Andrew McGlashan -
Brian May -
Glenn McIntosh -
Matt Cengia -
Michael Verrenkamp -
Olivier Mehani