This is turning off IMAP. The Twitter/Google invented OAuth they pushed on the IETF is not part of or relevant to real IMAP. It's just mega-corp crap. Especially OAuth 2.0.
In my dim recollection, I've used mail clients that used OAuth for IMAP access, plus it appears they are not taking away App Passwords, which I use for almost all my mail clients.
No, you can still use IMAP with Thunderbird for example but you login to google account and Thunderbird get a token similar to how all OAuth works, what is blocked is using email/passowrd directly with your IMAP client.
From the client's point of view, it's like a password. Just not your password. (edit: talking about app passwords, unrelated to oauth or stuff like that)
Indeed: this is a hard compatibility break, without a simple workaround.
The thing is, this is nowhere near new: it's been announced years ago, and slowly rolled out since 2019. Actually, IIRC, the rollout has been postponed at least once in 2020, due to covid (in order to not cut people off). I recall implementing Xoauth for IMAP, specifically for this.
If you have two factor auth on and generate an "app-specific password" doesn't this allow you to do the same thing still? You just use your email and app-specific password to login and it should work still shouldn't it?
No idea how it works now, tbh - but the problem I was trying to solve, in 2019, was "there isn't always a live human at hand, available to solve two-factor challenges." I distinctly recall that we had to go for xoauth, for lack of other hands-off options.
I do not believe so. Last time this was reported it was about preventing web views from being used to sign in. The idea is to prevent apps from phishing your credentials. Instead, you have to hand off to a secure browser for sign-in. After signed in, the app should be able to do anything it was able to do before.
Great. There's nothing I hate more than an app or game asking to login with Google and redirecting me to a non Google domain. Of course I have a separate email for those cases
I've got great distrust for these pop-up "sign in with Google" or whichever SSO provider you have you find in a lot of apps (or even Apple's accounts thing on macos); how can I verify it is in fact Google and not a 3rd party lookalike?
Check the URL and check the lock icon. If you're feeling extra paranoid, you can also click the log to get more information on the security certificate to confirm it's the certificate belonging to the provider.
Good point. Although in general, if it's an app, it's gone through the vetting process to arrive on its app store and such password-thieving shenanigans would have been caught during that process.
(Ensuring the integrity of that process is one of the reasons the app stores constrain so heavily apps that allow for some flavor of self-modification, via embedding a programming language, running downloaded code, etc.).
Ironically this is more of a problem now on desktop, where eg a website (such as eBay) in Firefox pops up a PayPal login window without an address bar and there is no way to verify the domain without using developer tools
Really PayPal should get with the times and offer WebAuthn, where upon it isn't a problem (WebAuthn credentials are domain bound, so, if that window isn't PayPal then it can't have PayPal credentials)
Asking humans, who often don't even notice when they wrote an entire word twice in a sentence, to "verify the domain" is nonsense, machines are good at this problem, let the machines do it.
If it does, that's be great, as I do have a PayPal account to solve a problem I had with one payment platform, but when I last looked it only offered TOTP
I just went to the bother of logging in to my PayPal, it shows only TOTP and some sort of SMS nonsense I won't touch, so, TOTP it is until either PayPal implements WebAuthn or somebody else in this space takes my business (by offering WebAuthn).
My strategy--which is more browser-centric--is that I open another tab and proactively log in to the identity-provider (Google, Steam, etc.) and only after that do I go to the third-party site.
If the flow asks me for my password again, something has gone wrong.
I wrote a small python script that uses the smtp lib. I don’t want to screw around with Google’s python library for a small script that will surely break every 3 months because google changes something about their auth.
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?
I've noticed gmail randomly blocks Firefox these days under the pretence of "your browser may not be secure" (i.e it doesn't persist through page refreshes), similar to how they try to make you do a captcha unless you refresh the page...
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.
Seconding this. I'm running Firefox on mac, with the built-in "Enhanced Tracking Protection" enabled, and uBlock Origin with the default settings. I've never seen that error. I don't use a VPN and I'm in the United States.
I only use uBlock Origin and the built in tracking protection. However I do not use Firefox defaults: I block all third party cookies and don't save cache/history on exit.. I guess it could well be the latter that Google finds "unusual" and frankly, this is what is pushing me away... I don't care what the metric is, I want to be in control, i'm not an idiot who tries to log in from ancient browsers or not understand the risk of logging in from a computer I don't own... But Google is optimising for the 99% at the risk of locking out 1%, that seems careless to me.
It is unusual. Google uses some of those cookies to determine whether it can lower the "threat signal" on your user agent (a UA carrying tokens that only Google could have issued to it is a huge indicator that Google has a pre-existing trust relationship with that UA).
By throwing away those cookies, your browser is doing the equivalent of showing up to the Google DMV wearing a different hat / sunglasses / beard pattern every time; the agent behind the counter can't say "Oh, that's just tomxor, I know them at a glance already so I by default trust they aren't an active threat to me" and has to do the equivalent of going through the process of doing a background check on you every time.
> But Google is optimising for the 99% at the risk of locking out 1%, that seems careless to me.
It's not careless; it's extremely intentional. Google has a responsibility to protect the 99% and assumes that those who are Internet-savvy enough to do the work to wonk up their UA's thumbprinting are Internet-savvy enough to do the additional work to make that process smooth for their fancy non-defaults configuration.
At the scale they operate, you can expect Google to make the decision that benefits the 99% over the 1% most of the time (particularly when it comes to account security). They'll assuredly risk losing business by making the 1%'s auth story more inconvenient if it makes it 1% more likely that the 99% don't lose the whole farm to a hacker.
I'm using the latest Firefox available via flatpack on Debian (v97 at time of writing), and I believe this is the same as other platforms. As I said it happens randomly, there is no pattern, as if they are just trying their luck.
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.
“Your browser might not be secure” is a worthless error message. If you have a strong reason to believe this is the case, you should tell me. If you don’t tell me, I’m going to assume you don’t have a good reason, and you’re just scaremongering.
They're not telling you what's wrong, just that you're bad for arbitrary reasons that ultimately will end up boiling down to "we don't trust that you try to preserve your own privacy".
I sincerely doubt it has anything to do with a whitelist of user agents. It is probably triggered by a failure to evaluate the botguard program, which indicates that your browser may be under the control of malware.
If your browser's user agent lies outside the "supported" list, you will be presented with a page telling you that your browser is insecure. It's a whitelist. I... Am unsure why you think this is not the case.
You can test it. Or look at any of the many articles after Google made the change.
A freshly installed Firefox, with a useragent of "Bob Dobbs 42.69" yields the "Your browser may not be secure" page, for myself. Both within and without a VM.
So, yes, I think I'm speaking to what the thread is actually about.
gmail login works with tor browser (based on firefox), of all things. my guess is that you're using an outdated/weird build of firefox and/or you have extensions that mess with the javascript execution environment (eg. canvas blocker, user agent spoofer)
You absolutely should own your own domain and use it to email somewhere besides Google. I use Fastmail but ProtonMail is great, tutanota, mailfence, etc. Getting locked out of your email is no joke you don’t want to be in that situation.
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
If you have a domain, that's just another liability for email security. Look at what NameCheap did. Imagine losing your domain for some reason -- even forgetting to renew. All your contacts need a new address now, and until then it's dropped 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.
The entire point of your own domain is to provide continuity. Of course it's one more thing to worry about, but it also one more layer of protection (an important one).
This has happened to me, briefly. I once forgot to renew and lost access to email. Luckily I was able to fix the issue quickly.
I do kind of wish I had never gone down the route of using my own domain for email. I use gmail with it, and will now have to bear a recurring payment of $6 monthly (IIRC). I could move hosts but none of them are free to my knowledge, and a free service comes with its own risks anyway. Plus that's my primary Google account.
Now I feel locked in ... it's less about updating my contacts, as I don't field a lot of personal or business email from that account, but more about all of the services where my account is associated with that email address. Not to mention that I've logged into some sites via Google. It would be a royal pain to switch now.
Edit: Also, my domain is super awkward, sometimes doesn't fit in the field when I'm writing it down on a form, and tends to draw comments when I just want to get my business done and go on. ALSO the account name is different from the name I actually use day to day now -- it's James when everyone knows me as Jay.
I know it's tough (migrated off G Suite Legacy myself) but it's probably best for the long run since G Suite accounts have less consumer features (in my case, lack of play store reviews and free Google Voice) and it's unlikely to change.
There are many submissions on HN discussing alternatives. Fastmail, Protonmail, iCloud+ (I switched to this), Microsoft 365 are frequently mentioned. I think Zoho also had a free plan.
It definitely wasn't the sole reason, but a sign that G Suite wouldn't maintain feature parity with consumer Gmail accounts. There are other features like Google Play library sharing which won't be added.
Yeah, people who used Google Voice early on were exempted from paying for managed Google Voice. It might be possible to port your Google Voice to a consumer Gmail account.
So without a domain whoever owns the domain you're using can deplatform you. The result is dropped emails at that address forever.
With your own domain, the registrar can pull a namecheap and cancel your country. The result is temporarily dropped emails while you transfer to another domain registrar.
I de-googled last year but still use google domains as my registrar. It's just so darn cheap and includes DDNS. I've looked at alternatives and I haven't been able to strongly identify one I trust more than google (as strange as that sounds). How do other people pick a registrar that they trust?
Just a reminder to everybody that Fastmail is an Australian company, and is therefore subject to Australia's TOLA / Assistance And Access.
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.
Maybe it's just me but I don't have "Australia going to force my email provider to hand over my data" in my threat model.
It's probably worth thinking about that too before hastily switching email providers. Fastmail is a solid provider, with great support and I never had a real issue with them. I give them money, they provide me a good and stable email service.
You should have "my mail data should not be shared with third parties" as a general rule for mail providers. If that's not you, cool - but I'd wager most folks don't want their mail read :)
If you don't want your mail shared with third parties you just have to encrypt your email and then it doesn't matter who your provider is.
There's a difference between "don't want their mail read" and "someone will be able to read my emails if there's a court order and they are interested in the content of my specific inbox".
This could happen to any country and is also precisely the reason why you use your own domain. You'd just point it to a new mail provider and you'll be up and running in an hour.
If you use a local mail client that stores your email locally you'll also have access to all these.
> Just a reminder to everybody that Fastmail is an Australian company, and is therefore subject to Australia's TOLA / Assistance And Access. [...] Having your e-mail provider compelled to work against your interests is no joke and you may not want to be in that situation.
This is not quite true.
The TOLA bill does allow the Australian government to compel an employee to break their product's encryption — which, yes, is dumb as hell. But Fastmail does not offer end-to-end encryption. As an Australian company, they already have had to comply with a court warrant asking them to surrender data; in other words, law enforcement does not need them to install a backdoor when they already have a front door. Your comment implies that TOLA made Fastmail less secure somehow, but this has been the case long before TOLA; the existence of that bill changes nothing.
I feel like it's important to point this out, not for the sake of pedantry, but to say that if you want truly secure encrypted e-mail, you must be in control of the encryption and decryption step, rather that having a company do that for you — you can't assume you'll be safe just because your provider isn't based in Australia. It's been a while since I've looked, but I think it would be very hard to find an e-mail provider that explicitly says it won't hand over data when presented with a valid warrant.
Step 1: just hook up a desktop mail client to your Gmail (Outlook, etc) and download all your emails locally.
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.
I personally am fine sticking with Gmail as I really enjoy the interface/features. One of the things I really like is the scripting I can do with Google Sheets, Gmail, and my Google Calendar. I have some pretty nice automations setup that do things like automatically adding details to my calendar based on emails. Parsing emails to put data into a spreadsheet, automatically adding details to calendar entries for certain things, etc...
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.
I have been having lockout anxiety lately as well. I actually took the time to look up proton mail and gave been waiting for and day to add it to any accounts I need access to such as amazon, eBay, Facebook, etc. There are just too many stories of people losing their gmail and no recourse as you will never get a human on their part to fix the issue unless you are some high profile client who can rock the boar.
I've got six google accounts and never seen this message while connecting from my normal IP address or a random VPN provider (so hundreds of users sharing the same IP address).
I presume something is wrong with your Firefox profile.
FWIW, I happened to try and login to my Google account a few months ago and was promptly kicked out in exactly the same way, and after root-causing "what did I do..." I realized it was because I'd just set --remote-debugging-port=.... when restarting my Chrome session.
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...
>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?
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.
I suggest all HN readers use this opportunity to stop using Google accounts, if they haven't done so already. Potential benefits:
* 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.
What are the leading recommendations these days? is it still mainly protonmail?
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).
U2F support was one of the reasons why I picked Tutanota. It's similar to Proton, but with Proton I really missed U2F and they've promised it for ages...
I use protonmail as a second account. It works fine, but there are a few quality of life differences compared to gmail.
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.
I switched from Protonmail to Fastmail (with by own domain) and couldn't be happier. Protonmail locks you in their own clients (on Android at least) and they're shitty (e.g no thread view).
* 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.
> 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 meant in terms of making it convenient to use that data in some other environment when one moves away from Google.
My Drive contents, for example, will come down in doc formats that may or may not be immediately compatible with whatever I want to move to (be it someone else's cloud or locally-running desktop editors). And it'll all have to be re-indexed for search purposes (unless I just decide "being able to search all my documents regardless of their format" is one of those Drive features I no longer care about).
Photos as well... I can pull my photos down, but I'm going to leave behind those "Find all pictures of a cat" or "Find all pictures of my mom" features that Google Photos provide.
self host your email. mailinabox makes it less than half an hour job. plus occasional updates every few months, nothing big. the upside is, you get to control your emails, your server.
the bad thing is, if you get a bad IP (which you can have replaced for example at the start from vps provider) or you do something fishy with your email like spam gmail/yahoo/outlook users, you would be banned but other than that it really isn't all that bad.
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)
You are missing key benefit: when Google locks you out of your account, you don't lose access to significant part of your digital life (your email, all these sign with google ect).
Google is using law of algorithm, not a rule of law. Trying to get to a person is nearly impossible.
> Less exposure to manipulative ads, and lower finesse of manipulation due to less data about you.
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.
Use a client that implements this authentication protocol - or pick a different mail provider. I know GMail is convenient, but as you're obviously aware, its cost is not just surrendering your data.
I just did this for a bunch of Gmail accounts that have aliases setup to send out from custom domain email address. So yes, You can still use less secure apps and set up gmail aliases as long as you enable 2fa and obtain an app specific pw that you then use to setup the alias or to log in into your google mail via the less secure app of your choice.
Note that there is no need for a phone number to setup 2fa as you can instead use the option of one time login codes and then validate access from your phone using any google app such as the gmail.
Suggestion? Start now. I moved my primary email to a custom domain a bit over a year ago, and it takes a while to slowly migrate everything over. You don't want to be doing that while under pressure from whatever it is that forces you off.
I'm using Fastmail, and I've loved it so far. The biggest thing that landed me there was the built-in snooze feature, which works just like Gmail's. Everything else has worked perfectly, too.
You can use the unsubscribe link at the bottom of each email. I have done this probably hundreds of times over the past 5 years and it has worked as expected with no undesirable side effects.
The unsubscribe buttons on those emails mostly work, by law. My life improved a lot when I started taking the ten seconds to unsubscribe from everything, vs. just deleting.
I often find myself constantly deleting/ignoring these emails instead of just hitting "unsubscribe". It's so weird how our human laziness works because I swear not many people unsubscribe from emails even though it is typically very easy. It is satisfying when I go in and unsubscribe to a bunch of junk.
I ran my own mail for a couple decades, until it got too time consuming. Now I primarily use Fastmail and I prefer it to Gmail, but still sometimes there are issues of third parties not liking my TLD (rare but happens with certain TLD's), but the biggest issue is when people just assume Gmail even though I've given them and sent them mail from other addresses and done everything I can to have them not send to my Gmail. Some of these are business clients, also. It's not that I haven't mostly moved from Gmail or that I'm not trying, it's that it's difficult. And I may lose some business when it happens.
Yeah, I should note that choice of TLD is important for your primary email. In my experience so far, no one blocks .com/.org/.net. Other TLDs may be trickier.
Indeed, and now that I've been using it for years and many people also use it to contact me, it will be as painful to change it as it would be to drop Gmail.
Yep. Try to stick to 2/3 letter TLDs, some sites check that length is within that range. I have a "fun" tld (in the same vein as myfullna.me) but keep a .net handy that's aliased to it in case it gets rejected.
Would like to do the same myself.. sadly my domain regsitrar is Google, not too sure if I'll need to register another name (a .dev tld) or if there's an easy route of changing registrars.
If you have a .dev TLD domain, Google technically has a lot of control over it no matter what you do, because they own the TLD. If you want to be truly Google-free you'd need a new domain.
It is your choice whether you use these services or not.
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.
I moved away from Google services years ago, but nowadays you can't even browse Youtube without asking for age verification, I'm not going to send my ID card or credit card data to Google to prove that my 15+ years old account was not created at that time by someone who was 2 years old and is still not adult in Europe, do these people even use brain to require age verfication from 15+ years old account?
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?
It's interesting how words can be strung together to avert scrutiny of relevant facts pertaining to the message being communicated—and sometimes even used to mask dishonesty.*
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.
> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password…
Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.
Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.
they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.
>This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.
So now you have HTTP protocol being used for IMAP, or worse and more common, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
It it were standard the same OAuth 2.0 module could be used with every provider of services. The reality is you need a custom implementation for every single megacorp and their local twist. It's not even a defacto standard by collective use.
Why is it an issue that getting a token for use with IMAP requires an out-of-band HTTP request? How do you think SSO works for anything other than web services?
You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.
It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail.
Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood
E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought!
I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!
> 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.
> 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"
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.
Conveniently Google also controls the allowed usages for “proper” OAuth access to Gmail. If your client is performing a function they don’t like then you’re screwed. I would expect that to be fair Google would have to also allow arbitrary access to the Gmail API to these now untouchable clients, but snowballs chance in hell Google will be so rational.
I am willing to think that Google performs fingerprinting on the OAUTH login dialog window, which if prevented, similar to the comment above regarding Firefox being unsafe, it would block login through OAUTH as it pleases.
It also straight up doesn't allow you to publish an OAuth application that uses “restricted” scopes (like `gmail.*`) without a review process subject to arbitrary usage guidelines determined by the Google APIs team. That’s the catch. It doesn't even matter how you run the OAuth flow (though I agree I suspect they fingerprint that too). You get blocked earlier.
> 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.
You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement?
Application specific passwords require two-factor auth being on, which means either giving google your phone number or having to pay for e.g. a yubikey.
How do you enable this without first giving google your phone number? My understanding is you have to set up SMS 2 factor auth first before you can change it to TOTP.
On a Workspace account you only need U2F token emulator (https://github.com/danstiner/rust-u2f woks fine) and thenn you can setup u2f first and add normal TOTP in second step. But u2f must stay there. I don't have a personal account to try if it works the same.
I am familiar with that page. (Although I'm not sure how to interpret your "You mean like[...]" phrasing. It doesn't make sense in response to what I wrote.) There's good reason not to go along with the security theater it describes.
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.
> You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement?
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.
It's .875rem, which works out to 14px with standard settings. That isn't huge but it's far from "damn tiny" in my opinion. You might have your browser set to a smaller default font size?
Do you have the page zoomed out or something? The font-size on that page is 16px tall on desktop. Hacker News titles are 16px and comments are 14px. (Note: I measured in px manually due to the use of rems in the CSS; easier to compare this way)
One thing you can generally be sure about, no matter what changes they go through: They won't ruin their own services and income-streams. Removing cookies? They have replacement for that in their browser that no extensions will be able to help with. Removing sign-in methods? Within their ecosystem they pass whatever token they want, wherever they want.
Not really. You just need to use the apps specific pw that you can obtain from your account security page. I just did this for a bunch of Gmail accounts that have aliases setup to send out from custom domain email address.
The only change is that you have to enable 2fa to obtain an app specific pw that you then use to setup the alias or to log in into your google mail via the less secure app of your choice.
Note that there is no need for a phone number to setup 2fa as you can instead use the option of one time login codes and then validate access from your phone using any google app such as the gmail.
I'm sure from a business standpoint they don't want to make it harder for users. But My 88 year-old-mother is always getting security warnings from Google when she tries to log in to email (despite me telling her NOT TO DO THIS) from a Kindle Fire device (which is basically an android tablet). And then she panics and tries to change her password, and then she forgets her password even though I tell her to WRITE IT DOWN and put the date next to it. (Don't tell me to get an 88 year old to use a password manager. They would be way too confusing for her.)
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:
Just wanting to point out that as an alternative to ProtonMail, FastMail, etc. you can simply buy your own domain, and point your DNS MX record to a traditional mail service with POP and IMAP access. All DNS registrars I know do offer that, plus RoundCube as web mail service if you want to access it from browsers.
271 comments
[ 3.1 ms ] story [ 273 ms ] threadThe thing is, this is nowhere near new: it's been announced years ago, and slowly rolled out since 2019. Actually, IIRC, the rollout has been postponed at least once in 2020, due to covid (in order to not cut people off). I recall implementing Xoauth for IMAP, specifically for this.
(Ensuring the integrity of that process is one of the reasons the app stores constrain so heavily apps that allow for some flavor of self-modification, via embedding a programming language, running downloaded code, etc.).
https://developers.googleblog.com/2021/06/upcoming-security-...
So you should never need to trust the app.
Asking humans, who often don't even notice when they wrote an entire word twice in a sentence, to "verify the domain" is nonsense, machines are good at this problem, let the machines do it.
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?
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.
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.
Heh.
By throwing away those cookies, your browser is doing the equivalent of showing up to the Google DMV wearing a different hat / sunglasses / beard pattern every time; the agent behind the counter can't say "Oh, that's just tomxor, I know them at a glance already so I by default trust they aren't an active threat to me" and has to do the equivalent of going through the process of doing a background check on you every time.
> But Google is optimising for the 99% at the risk of locking out 1%, that seems careless to me.
It's not careless; it's extremely intentional. Google has a responsibility to protect the 99% and assumes that those who are Internet-savvy enough to do the work to wonk up their UA's thumbprinting are Internet-savvy enough to do the additional work to make that process smooth for their fancy non-defaults configuration.
At the scale they operate, you can expect Google to make the decision that benefits the 99% over the 1% most of the time (particularly when it comes to account security). They'll assuredly risk losing business by making the 1%'s auth story more inconvenient if it makes it 1% more likely that the 99% don't lose the whole farm to a hacker.
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.
It has nothing at all to do with how secure the browser on the end user's computer actually is.
[0] https://support.google.com/mail/answer/6557?hl=en&co=GENIE.P...
You can test it. Or look at any of the many articles after Google made the change.
So, yes, I think I'm speaking to what the thread is actually about.
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
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.
I do kind of wish I had never gone down the route of using my own domain for email. I use gmail with it, and will now have to bear a recurring payment of $6 monthly (IIRC). I could move hosts but none of them are free to my knowledge, and a free service comes with its own risks anyway. Plus that's my primary Google account.
Now I feel locked in ... it's less about updating my contacts, as I don't field a lot of personal or business email from that account, but more about all of the services where my account is associated with that email address. Not to mention that I've logged into some sites via Google. It would be a royal pain to switch now.
Edit: Also, my domain is super awkward, sometimes doesn't fit in the field when I'm writing it down on a form, and tends to draw comments when I just want to get my business done and go on. ALSO the account name is different from the name I actually use day to day now -- it's James when everyone knows me as Jay.
Is this the cost for gmail to use a custom domain? or is it a very expensive domain name spread over 12 months?
I know it's tough (migrated off G Suite Legacy myself) but it's probably best for the long run since G Suite accounts have less consumer features (in my case, lack of play store reviews and free Google Voice) and it's unlikely to change.
There are many submissions on HN discussing alternatives. Fastmail, Protonmail, iCloud+ (I switched to this), Microsoft 365 are frequently mentioned. I think Zoho also had a free plan.
Also I still have a legacy G Suite with Google Voice attached to it which works fine -- and will add additional cost when/if I switch away.
Yeah, people who used Google Voice early on were exempted from paying for managed Google Voice. It might be possible to port your Google Voice to a consumer Gmail account.
With your own domain, the registrar can pull a namecheap and cancel your country. The result is temporarily dropped emails while you transfer to another domain registrar.
You can set the registrar to autorenew.
There are DDNS scripts on github to update the DNS record. Picked gandi a very long time ago and have no complaints.
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.
It's probably worth thinking about that too before hastily switching email providers. Fastmail is a solid provider, with great support and I never had a real issue with them. I give them money, they provide me a good and stable email service.
"Australian intelligence services decline to comment on massive data breach."
There's a difference between "don't want their mail read" and "someone will be able to read my emails if there's a court order and they are interested in the content of my specific inbox".
If you use a local mail client that stores your email locally you'll also have access to all these.
This is not quite true.
The TOLA bill does allow the Australian government to compel an employee to break their product's encryption — which, yes, is dumb as hell. But Fastmail does not offer end-to-end encryption. As an Australian company, they already have had to comply with a court warrant asking them to surrender data; in other words, law enforcement does not need them to install a backdoor when they already have a front door. Your comment implies that TOLA made Fastmail less secure somehow, but this has been the case long before TOLA; the existence of that bill changes nothing.
I feel like it's important to point this out, not for the sake of pedantry, but to say that if you want truly secure encrypted e-mail, you must be in control of the encryption and decryption step, rather that having a company do that for you — you can't assume you'll be safe just because your provider isn't based in Australia. It's been a while since I've looked, but I think it would be very hard to find an e-mail provider that explicitly says it won't hand over data when presented with a valid warrant.
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.
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.
https://migadu.com
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.
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.
* 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.
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.
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.
* 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 meant in terms of making it convenient to use that data in some other environment when one moves away from Google.
My Drive contents, for example, will come down in doc formats that may or may not be immediately compatible with whatever I want to move to (be it someone else's cloud or locally-running desktop editors). And it'll all have to be re-indexed for search purposes (unless I just decide "being able to search all my documents regardless of their format" is one of those Drive features I no longer care about).
Photos as well... I can pull my photos down, but I'm going to leave behind those "Find all pictures of a cat" or "Find all pictures of my mom" features that Google Photos provide.
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)
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'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.
The biggest thing is to get onto your own domain so that switching again if your host changes policies becomes much easier.
I use mailbox.org with no complaints.
They won't for some arbitrary percentage of emails. And even then, they will keep coming from new places.
https://posteo.de/en
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)
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?
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.
Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.
https://datatracker.ietf.org/doc/html/rfc6749 "The OAuth 2.0 Authorization Framework"
>This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.
So now you have HTTP protocol being used for IMAP, or worse and more common, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.
Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.
--
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
Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood
E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought!
I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!
> 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.
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.
You mean like google's "Application Specific Passwords" that have been around for a VERY long time, and are not affected by this announcement?
https://support.google.com/accounts/answer/185833?hl=en
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.
I sleep soundly well knowing I will never lose access to my email.
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) ...