I seem to have less and less control over where and how I am allowed to sign in (even thought I'm using a U2F key), and as a result I'm definitely getting pushed closer to the threshold to move away from gmail out of lockout anxiety.
[edit]
To all those comments that assume I'm: running an outdated browser, have a broken profile, am running untrustworthy plugins, am doing UA spoofing or have been pwned etc etc...
First you are missing the point: I dislike being held to increasingly arbitrary and opaque metrics of what Google defines as "safe"... because that is anxiety inducing, what will it be next week? even if I can log in now, will I be able to log in then?
Second: No, this is Google's fault, not mine. I have not been pwned, this occurs through multiple OS installs. I always keep my browser(s) up to date (i'm a web dev), I know the implications of runing lots of plugins (I do not). However i DO employ restrictions as do many HN readers that Google will find undesirable, uBlock Origin, Firefox enhanced tracking protection, block third part cookies, DNS level ad and tracker blocking etc... It's likely Google doesn't like one of these, but back to point no. 1: it's an opaque metric, I do not like this... hell it may even be because i'm running Linux - so maybe I should do UA spoofing after all to pretend to be a "normal" Windows or Mac user.
I have a paid account with Fastmail and a free account with protonmail just in case something goes wrong with Fastmail I can transition my free protonmail account to paid and use it with very minimal downtime
Edit: adding my fastmail referral link just in case https://ref.fm/u26310488
I avoid them like the plague for this reason. Having your e-mail provider compelled to work against your interests is no joke and you may not want to be in that situation.
What I do to avoid too big of a headache with a lockout is using my own domain name. I essentially just forward my emails to my Gmail account. And then I set it up so I can reply with my own domains address in emails. So if I want to switch to a different provider it's just a matter of switching where I forward to or switching mx records. I also use Google takeout to take frequent full backups of all my data.
That way you have a backup. And copies if your email account gets blocked.
It’s not a permanent or complete solution, but for all the people contemplating this issue, but not yet committed to switching… start with copying down your emails.
A custom domain is mostly a vanity measure. It does allow you to migrate to a new email service if your provider cancels your subscription, I suppose... But I'd rather only have one thing to worry about.
This is not a version issue, I suspect Google are just becoming more and more sensitive to users who don't fit their 99% of "uses chrome and doesn't block trackers" profile.
Turns out this sets navigator.webdriver (as in, makes that key exist), which Google's login chucks a wobbly at. It will not let you in with that set, sadly because dumb scammers seem to absolutely love (???) using headless Chromium to attempt to fulfill their dastardly plans. (Which is really sad, because it makes legitimate tinkering that much harder (eg, can't interact with my primary session using nodejs/whatever :<).)
I'm wondering if Firefox is setting something off something similar. You say this only happens randomly? I wonder what correlated thing is happening at the same time as these failures, and if the "oh it's that" is on your or Google's side of the internet connection...
Unfortunately, that's the nature of computing in the era of the Internet; being connected online exposes one's accounts to every bad actor on the planet. Google has to keep adapting to the attacks that are successful against their most vulnerable users, and since attackers keep getting more savvy, countermeasures increase in complexity. I won't be surprised when Google mandates 2FA for everyone.
But you're right that it puts a burden on the end user, and increases the odds of false-positive attack prevention kicking in. There really isn't a way off that anxiety-train I'm aware of that isn't "migrate to a different, far less popular service provider that won't be as large an attack target for bad actors," with all the negative consequences such a migration entails.
Developer Edition, on Windows fwiw.
NoScript (or, not enabling javascript globally) is known to cause issues for me.
Things that hide or obfuscate user agents will break google too.
Anything that replaces common CDNs with privacy friendly ones also causes issues.
I presume something is wrong with your Firefox profile.
It occurs randomly and across multiple fresh OS installs... it's Google, doesn't mean everyone will experience it, but it's annoying.
It has nothing at all to do with how secure the browser on the end user's computer actually is.
The terse form of the advisory states:
> To help keep your account secure, starting May 30, 2022, Google will no longer support the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password.
It's the innuendo that's interesting. The message in the subtext of this statement is, Look at these apps! They want you to use them for e.g. checking your email, but look at what they do! Isn't it awful? In order to let you check your email, they make you give them the password for your _whole_ Google account!
Of course, the only one who's responsible for the current arrangement is Google. Google, not third-party developers, are to blame (and _solely_ to blame) for why access to the various Google services is consolidated into a single account. Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password, which is the same as your YouTube password, which is the same as the password you use to mark your phone as needing to be locked out of your account after it's stolen.
* This is why I'm skeptical of the whole "writing forces you to be honest because it means you have to actually think things through well enough to put them into words that can be put into coherent sentences" meme. Nobody seems to talk about how writing and the revision process that's inherent to it also provides the opportunity to finesse words. Some idea can be made to appear as if it's sound and backed by solid reasoning even when the truth is actually much less straightforward—or even contradictory.
You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement?
App Passwords are not really passwords in the conventional sense. The format makes it difficult to actually use them like a password. They're 16-digit sequences that Google generates for you (you have more control over your child's SSN than you do over these non-passwords)—hard to remember, and that's because you're pretty much not expected to. You're expected to key it in approximately once and configure the relevant app to save it in perpetuity, rather than typing it in. What these things actually are should be familiar to the people here. They're API tokens (and pretty weak ones at that, relatively speaking)—just billed under a different, more familiar name, for a non-technical audience who wouldn't understand that term.
If you are currently using a strong but nonetheless memorable password for Gmail and have your mail client set up to always prompt you for it rather than storing its own copy, then switching to one of these app-specific tokens will actually make your email less secure.
Furthermore, in comparison, a 16-digit sequence has less entropy than a passphrase comprising 6 words chosen from even a very small 1000-word dictionary.
In summary:
- worse experience than an actual password
- less secure
A less cumbersome approach to address the threat Google is pretends to be concerned about here? Allow people to deconsolidate their accounts. This would actually have other happy knock-on effects, such as mitigating the impact of the now-familiar phenomenon where people get locked out of significant parts of their online and offline lives when something goes wrong with their account. Also wouldn't hurt their image in the current conversations about legally imposed breakup.
It's not actually documented anywhere, but app-specific passwords cannot be used with non-commercial Google accounts that do not have two-factor authentication enabled.
Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.
> An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords.
Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.
--
Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change
different password: check
ringfenced access: check
If you're making an earnest effort to think truthful thoughts, then trying to put your thoughts into writing is genuinely helpful.
Writing doesn't stop you from deceiving others, but it helps to stop you from deceiving yourself.
* Better privacy (on many/most alternatives); Google will no longer read your email, store it for use by themselves and their partners, and perhaps pass a copy along to the NSA as Edward Snowden has revealed happens.
* Less exposure to manipulative ads, and lower finesse of manipulation due to less data about you.
* Easier for you to turn on ad-blockers without worrying about that also blocking Google junk.
* Less chance of Google applying censorship to content you publish or transmit.
* While you can Takeout your data, enjoy the process of reshuffling gigabytes of Drive contents, calendar entries, YouTube videos, etc. Into other application systems.
* Disconnection from the Cloud makes everything strictly less convenient. "Oh, I'll just throw you a Drive link... Oh wait, I guess I'm going to have to upload it to something else that you may or may not have access to, or email it to you and hope that your email server and my email server agree on what the maximum transfer size is, or I'll upload it to a web server and toss you a password in hope nobody else cracks it while you're getting it because I misconfigured my server." Then, of course, if they need to make changes they'll have to email their copy back to you... Remember the days of report-final-final2-june-version.doc? Enjoy going back to that.
* Replacing one set of integrated Google services with a slew of third-party solutions means none of those solutions are expected to work with each other, and while you leave behind the disadvantage that Google could decide your account is terminated and you lose access to everything, you'll be replacing it with a disadvantage that any individual third party provider could pivot or collapse and you lose access to the service they provide. To say nothing of the need to have to track dozens of authentication credentials now, unless you delegate to a third party identification provider (whoops, that's also Google...). And, of course, since they're not funded by the largest advertising network on the planet, at least half those services will charge you money to be less convenient.
If you've uploaded it, there's no sense in taking it down. Google already has it. Just don't log-in to Google accounts and don't take their cookies.
> I guess I'm going to have to upload it to something else that you may or may not have access to,
If you looked into alternatives, you would find many don't require any account or login by the receiving party. Example: box.com links . Actually, I'm pretty sure that's the norm.
> I'll upload it to a web server and toss you a password
Look, you've been stuck in the Google bubble for too long. The weather is just fine outside.
I'm no longer convinced that Google actually uses information about you to target ads. I base this on recently watching a lot of YouTube on streaming devices such as my Amazon Fire TV and my Xfinity Flex.
On my desktop I have an ad blocker and so usually do not see ads on YouTube but there are no ad blockers on those streaming boxes. I'm logged into my Google account in the YouTube apps on those boxes so Google knows it is me watching and could therefore make use of the full power of their allegedly mighty data-driven personalized ad targeting.
I've now seen hundreds of ads and they have yet to show me one that matches my interests or matches products I use and make purchasing decisions for any better than random billboards on the side of the freeway match. For the advertisers paying for those ads it was a complete waste of their money for Google to show me those ads.
Google is using law of algorithm, not a rule of law. Trying to get to a person is nearly impossible.
Is lock-out on Google a thing? I mean, does it happen often other than, when, your account has been maliciously hacked? I didn't know that.
I think the features I value most are U2F support and a usable but simple web interface (Gmail's web interface has actually gotten consistency worse over the last decade so I guess that sets a low bar).
1. ProtonMail can not search the contents of messages in the web client, unless you enable local indexing. This downloads all of your messages to the client, and performs the search locally. This, of course, must be done from every web client. It makes sense, given that PM can't see the contents of your messages. The Android app can not search the contents of messages.
2. The Android app does not clear notifications if the message is read elsewhere. This can be annoying when you look at your phone and see notifications for 7 unread messages after they've all been read.
Proton supports TOTP only, and not U2F/WebAuthn.
sure i have to "sometimes" ask people to check spam and set it as not spam but that is becoming more and more remote.
i do understand the appeal of protonmail and other privacy centric emails but you can do that yourself if you put in the elbow grease. plus you get to learn about a lot of stuff and its a fun exercise.
you also do not have to pay through your nose if you want more features/more storage and stuff (well the storage/server depends on your vps in toto but still)
https://restoreprivacy.com/google-alternatives/
Personally, I use:
* DDG for search.
* gmx.com as my main email server (not sure it's that great for privacy, ProtonMail is probably better).
* OpenStreetMap for maps (caveat: Some info is on Google Maps and not on there)
* HereWeGo for car navigation
* Thunderbird as my mail client + calendar
* I don't publish videos, but otherwise probably PeerTube
* IRC and Matrix for group chatting
* F-Droid for FOSS mobile apps, Aurora for anonymous access to Google Play Store
Not yet de-googlified:
* I use an Android phone (albeit Chinese)
* Still need a good alternative for Google Translate.
Disclosure: I work for Google, speaking only for myself
My Google account does not contain nuclear launch codes, and my threat model is not the same as Google's. I am far more worried about getting locked out of my own account due to some mishap than I am someone else getting in, and I think I should be able to assess my own risk. Google can set defaults, but I know my own life.
(I will say that I wouldn't mind switching to app-specific passwords, but Google won't let me because I have 2FA turned off. I don't want 2FA because I don't want to get locked out of my account, I don't need 2FA because I use a password manager, and I don't understand how 2FA and app-specific passwords are related.)
Also, I enabled 2FA a couple of years ago, and have been happily using app-specific passwords ("app passwords" now) since they were implemented. Tying them to 2FA activation doesn't look like an engineering limitation.
It's actually less hassle to migrate off Gmail. Quite frankly there are few Google things that at this point aren't a hassle to work with. Google is poised to ruin adblocking in chrome with manifest v3, search is increasingly polluted by junk, gmail is now a pain to work with outside of a web browser and awful to use in a web browser, the play store is so bad as far as finding non junk non malware that its necessary to use an outside web page like say bing/duck duck go to find apps to install with play store which serves at best as an updater interface, workspace is a pain. Various actually useful services like reader picasa google+ are dead.
The only remaining useful end user services are youtube, maps, and android.
As someone who used to be excited about Google stuff its kind of disappointing.
Gmail user from June 2004-2022 but soon no longer. Thanks for 18 years of good service for the absolutely ridiculously low price of I think $80 to date.
You shouldn't need OAuth; have you tried application-specific passwords (https://support.google.com/accounts/answer/185833)?
How could a rule like that be enforced?
> lock down API access to blessed google clients and services.
What's wrong with application specific passwords?
(Still speaking only for myself)
If I save my credentials in Mutt/Pine it's more secure than entering them in the browser - much less attack surface, and not more third party than a browser. There are some benefits to having a token like in oauth, for example simple way to revoke some sessions access, but it's a tradeoff, not black and white.
github.com/bjesus/oauth-hopper/
On the other hand, if I decided to use them, I would like rules to make my account safer.
It is not going to make it more difficult to get into your account -- companies that implemented insecure login method will basically have to adjust and that's it.
Oldest e-mail I've found in my Gmail is from 2007 from Rapidshare, but created it already way before, but there is no way to find account creation time (POP/IMAP trick doesn't work, shows 2008).
Any idea how to find how old is Gmail account and why they ask for age verification for 15+ yo accounts?
1) Chrome for gmail and the odd other service (eg domains)
2) FF for general browsing (avoiding google at all costs)
3) Chrome based browser (Iridium) for the odd web site that needs Chrome or has too many scripts to open (and I really want to use the site)
It's not totally foolproof, of course, an app could bundle its own HTML engine or fake the UI some other way.
If the flow asks me for my password again, something has gone wrong.
So I have a dedicated email and explicitly toggle a switch and they’ll still toggle it back forcibly over time, and now are getting rid of it?
If they're for actual humans, even in the best case you're vulnerable to phishing, also you are a perpetual risk because you know these passwords (or a password equivalent) so an adversary might steal your passwords (e.g. from a backup, logs, test systems, ...) and now they can impersonate all users.
It's almost certainly safer than letting users pick their own passwords, but it's less protected than, say, a Google user who set up 2-step, and much less than if they went with Advanced Protection and thus can't get phished or impersonated.
I'm in the same boat and have been putting off moving to a Google blessed solution because of the effort required to navigate the bewildering array of documentation, client libraries and authentication mechanisms Google offers.
Much of the documentation and examples Google makes available are targeted at accessing Gmail on behalf of a human user (who has access to a browser) rather than accessing it on behalf of a machine (which does not). Cutting through the noise is half the battle!
I reluctantly spent some time this morning trawling through it and whilst I now have a working solution I couldn't begin to say whether it is the right approach. In the end I decided to ditch SMTP and use the GMail API [1] with a service account [2] setup with domain-wide delegation [3] which is nearly as scary as it sounds.
One caveat of this approach is that I choose to use a service account `key` (not to be confused with an `API Key`!) rather than the Google recommended "Workload Identity Federation" [4] so no-doubt this will be depreciated at some point.
If you must stick with SMTP then [5] is a good resource for showing how to use SASL XOAUTH with an access token to authenticate with Gmail SMTP. Of course, you need to obtain the access token from Google IAM to use this anyway so there is little benefit of doing this vs using the GMail API directly.
[1] https://developers.google.com/gmail/api/guides/sending
[2] https://developers.google.com/identity/protocols/oauth2#serv...
[3] https://developers.google.com/identity/protocols/oauth2/serv...
[4] https://cloud.google.com/iam/docs/workload-identity-federati...
[5] https://developers.google.com/gmail/imap/xoauth2-protocol#sm...
Maybe related, I have seen for years that whenever I try to download gmail into Thunderbird and I am not at my normal office location, Google requires me to first log in to my account via a browser, then it allows the Thunderbird login.
I don't use Thunderbird, but yes, if you have anything vaguely close to a modern Thunderbird then you should choose OAuth2 instead of "Normal Password" for both sending and receiving. You may need to exit Thunderbird and go back in, then it should prompt you via what is in effect a web frame, to log in by whatever means you ordinarily use for Google, then Google asks if you really want to let Thunderbird read and send mail (you do) and this grants it a token that it will use to access your mail.
The alternative would be to set up an "App password" in your Google account and then paste the password (which Google chooses) into Thunderbird. That password is then independent of your actual Google password and can't be used to sign in as you on Google, just by mail clients for checking mail and so on, sounds like you did this with Yahoo/AT&T already once. Prefer OAuth2.
Mutt can present a token inside IMAP/POP/SMTP, but by design mutt itself does not know how to have a separate conversation (outside of IMAP/POP/SMTP) with the server to authorize the user and obtain refresh and access tokens. Mutt just needs an access token, and has a hook for an external script to somehow obtain one.
mutt_oauth2.py is an example of such an external script. It likely can be adapted to work with OAuth2 on many different cloud mail providers, and has been tested against:
- Google consumer account (@gmail.com) ...
(Yes, 2FA increases security, but if someone doesn't or can't have it enabled, for whatever reason, that's no reason to prevent them from using app-specific passwords)
I sleep soundly well knowing I will never lose access to my email.
I suppose this means that no part of this strategy viz-a-viz gmail, Thunderbird and POP3 is going to work for me anymore..? The good news, I guess, is I won't lose any mail. The bad news is, gmail users have recently started to get email from my private server to their spam, occasionally, even though my IP's nowhere near a blacklist and hasn't been for years; thus, being able to send gmail-to-gmail has been helpful sometimes.
Google "engineering" excuse everytime is it is for your safety
Create a paid, highly reliable, highly secure, client side encrypted, email based service on a proper jurisdiction. Open source your clients and open yourself to independent audits. Be open with your customers, friendly and transparent. Earn the money...
Fastmail, Rackspace and Protonmail are good offers, but as mentioned in this thread for one reason or the other can still be improved.
Any takers?
