Less secure apps and your Google Account | Hacker News Reader

Less secure apps and your Google Account

support.google.com

184 pointsjerryzh258 comments

The sign-in method they're removing really is less secure: you're sending your full username and password to a third-party. Application-specific passwords (https://support.google.com/accounts/answer/185833) and OAuth are much better.

Disclosure: I work for Google, speaking only for myself

I agree, I have always hated having to give my google credentials to random apps instead of just using something like oauth where I can be more confident in the security of my credentials.

An email client running on my own machine is not a third party. But regardless, this is why the feature is called "enable access for less secure apps". It's disabled by default, and it re-disables itself automatically unless you're actively using it to sign in.

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.)

I do think you're right about 2FA, and there should be an option to use an application specific password without 2FA.

FWIW, 2FA is very low friction. You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application. If it wasn't you, then someone else besides you knows your credentials and you need to change them ASAP. If it was you, you have another 2FA point.

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.

> You'll get a "Is this you?" popup in your phone or tablet whenever someone uses your username and password in a new device/browser/application.

I have two different concerns.

The first is that I frequently end up having to clear my browser cookies, for a variety of reasons. Every time I do, I have to redo the 2FA dance, on every single website that requires 2FA. I suppose I could find a different cookie management strategy, but I think it's good for both privacy and security to treat cookies as semi-ephemeral.

Secondly, I’m concerned that I'll either loose or replace my 2FA device and forget about the account until it's too late—again, I’m much more concerned about losing access to my account than someone else getting in. I would almost certainly loose any physical backup codes.

I also have a fantasy that I'll give up my smartphone one of these days, or at least not bring it everywhere I go. I’ll probably never do it, but the idea is such that I don't want to depend on an app for access to my account. I do think I’ve successfully made myself less dependent on my smartphone than a lot of people, and I’m proud of that accomplishment.

Then try TOTP, and back up your seeds.

Have you thought about multiple 2FA devices?

To my knowledge, you can use as 2FA w/Google:

1. A prompt on your phone

2. A hardware security key

3. TOTP token from authenticator

4. one of 10 backup codes

And you can also have multiple security keys as well, which is useful if you lose one.

A prompt on my phone and an app on my phone come down to the same thing, and I'm not interested in getting a physical hardware security key. The backup codes are one-time use, and there is no way I would keep track of a slip of paper for years without loosing it.

I could use my password manager (Bitwarden) as my TOTP generator, and I may eventually do that just to make all of these services shut up. But, wouldn't that leave my account no more secure than it already is today? It would effectively be single-factor authentication, since the password and the generator would be in the same place, protected by the same master password.

I’m not sure about Bitwarden, but 1Password requires quite a few pieces of information to log in on a new computer, because it derives the encryption key from both the hash of your password and the “Secret Key”. Effectively, it still IS 2FA, with the “something you have” factor being a device activated with the secret key and your 1Password OTP. If you don’t sign into your password manager on your computer directly this should be fine. But you do, of course, lose the ability to paste passwords.

But regardless of how the vault is protected, your password and your otp generator are both stored there, right? If you have access to one, you have access to the other. So, I don’t understand how requiring both to log in to Google improves security in any meaningful way.

It's often much easier for someone to manage to get a copy of your password for a specific application than to get a copy of your unencrypted vault.

That's more friction than I'm willing to tolerate. If they force me to use 2FA, I'm done with Gmail for good (it's already no longer my primary email).

And I'm not against 2FA in general, I just don't want to use it in this case.

Googles 2fa requires the user to give google his phone number before being able to add a totp authenticatior. That alone is reason for me to never use it for my google account. The popup also doesn't come up if you haven't signed up with google on your phone, obviously. There is nothing stopping them from just allowing anyone to add a normal totp 2fa generator, they just chose to not do that to get more of that sweet, sweet data.

Does Google fall back to SMS if you tell it you lost your totp authenticator? That’s problematic in its own way, but it would explain the phone number requirement.

Not if you remove the phone number afterwards. It just requires the phone number before enabling the normal otp.

Sweet, I was about to look into whether I'd need to make changes to my OAuth integration. Makes sense that it's fine since the username/password (or however they wish to authenticate) is sent to Google themselves.

There are still non-web applications, so no, that's not a third party.

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.

You aren't necessarily actually sending it to a third party per se though. Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim.

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.

> Less secure access also enables using software running on your own computer to access your email easily. For example offlineimap and imapfilter. In theory it ought to work with OAuth but damned if I can get it to work and any instructions a few years old are useless because something has changed in the interim.

You shouldn't need OAuth; have you tried application-specific passwords (https://support.google.com/accounts/answer/185833)?

If this is an effective workaround why is it useful to disable the feature in the first place. It seems like a 16 digit password this is actually much less secure than the current state of affairs.

It's probably not much worth exploring because I'm also having to migrate off of legacy google apps for your domain as well.

Oh, so you still support application specific passwords. I couldn't find them when I last looked, or maybe it was because applications just moved to the OAuth2 model and didn't offer the option. I'm pretty sure Thunderbird's calendar extension doesn't.

I didn't ever understand why Google allowed you to enter a password into a random piece of software. In fact I'm still somewhat perplexed by them letting you enter it into a browser, but I guess they could be using the browser DRM module to get some assurance they are dealing with software they can trust.

I guess it's just too hard to make move everything to hardware security tokens. Nonetheless, I don't see an choice in the long term - physical security tokens that don't allow firmware upgrades is where we must end up.

I really think Google needs to make a distinction between sending your credentials to a foreign 3rd party service/domain vs a “3rd party” client that runs on your machine. Sending your credentials somewhere else is understandably best avoided. Using a different “3rd party” user agent than the top 3 browsers to access some google services, on the other hand, really isn’t less secure at all and I even think an argument could be made that it’s more secure than a browser in many cases. Local (wouldn't even mind if it was limited to open source) apps should be given unrestricted access to the Gmail OAuth scopes. Until then, I can’t see how this is anything other than a platform control play under the guise of user safety to lock down API access to blessed google clients and services.

> Local (wouldn't even mind if it was limited to open source) apps

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)

> How could a rule like that be enforced?

Considering the review process is currently subjective, then subjectively I guess. If you say in the review that you're an open source app and that you only do native OAuth locally then you get approval. Google already requires a link to your project's homepage maybe additionally you have to provide one to your source code so the reviewers can verify. If you prove to be untrustworthy and in violation at some point in the future then your access gets pulled.

Maybe the problem is that google is trying to enforce client behavior in the first place? I thought the point of OAuth was that the user gets to approve or deny access to granularly scoped resources on their account, not google.

Re app passwords: aren't you still a "less secure app" then? Really it's the messaging https://support.google.com/accounts/answer/185833?hl=en:

> Tip: App Passwords aren’t recommended and are unnecessary in most cases. To help keep your account secure, use "Sign in with Google" to connect apps to your Google Account.

> An App Password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App Passwords can only be used with accounts that have 2-Step Verification turned on.

So e.g. I'm trying to build a "more secure" app that uses sign-in with google like it's supposed to and Google says "sorry your use case isn't approved". My recourse is just be a less secure app? Isn't that a little unfair? More-so, according to google's messaging, doesn't that make the user less secure?

Sometimes you can't use OAuth because your client doesn't support it. If you ever run into that problem you might find my project useful - OAuth Hopper serves as a simple proxy that removes OAuth from services.

github.com/bjesus/oauth-hopper/

Excerpt from the Mutt OAuth readme page:

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) ...

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.

If it's in an app you don't necessarily get full browser functionality. You just have to trust the app.

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.).

Google does not allow oauth from embedded webviews:

https://developers.googleblog.com/2021/06/upcoming-security-...

So you should never need to trust the app.

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.

Ebay supports WebAuthn, does PayPal not?

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).

On iOS, you get a system-level modal promopt that confirms what domain you're going to, and the domain should be in the title bar of the web view.

It's not totally foolproof, of course, an app could bundle its own HTML engine or fake the UI some other way.

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?

Does this mean no more app tokens, e.g. to retrieve IMAP mail?

Thankfully not so far - it says on that page you can still use an App Password.

Ah-ha, thanks. I missed that my first read through. Must need to finish my coffee …

It does mention app passwords on this page, but it's not clear that they are saying app passwords will continue to work after this change.

Those are also on the way out...

And that'll be the point I stop using gmail, which will probably be a good thing.

Sure, why not. It's not as if Google has a monopoly on email.

Why do you say that?

Ah, sorry: what was phased out was app passwords without two-factor authentication; I thought it applied to all app passwords.

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.

What about clients which don't support that, like Google's "send mail as" feature? I suppose that won't be supported anymore?

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)

They are exactly what are so-called not safe, take kmail as example

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.

In other words, Gmail is no longer compliant with Internet email standards like POP3/IMAP.

Actually, IMAP supports various authentication protocols - "plaintext login MUST be supported" was never a part of the spec.

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.

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.

If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.

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.

IMAP with OAuth is standard. What am I missing?

It is not, in fact, a standard. It's a proprietary complicating thing that megacorps do and everyone else assumes is standard.

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.

> It is not, in fact, a standard. It's a proprietary complicating thing

Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.

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?

In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.

You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).

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.

e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :)

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

App passwords are not limited in scope, AFAIK.

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!

If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.

Google provides the App passwords feature:

> 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?

https://support.google.com/accounts/answer/185833?hl=en

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.

Or using a free authenticator app for time-based codes?

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.

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 some alternatives?

The only thing I used my google account for was email. There are many good alternatives – I myself have been happy with mailbox.org for years.

Office 365.

their web email client continues to be ocular cancer for anyone who isn't already a daily Outlook user.

I can't stand it nor GMail so I always use a good old local client (Mac Mail or Evolution).

Here's one survey of alternatives:

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.

GMX exposes your IP address in email headers.

Well, I wasn't expecting it to hide my IP address. By default, the Received headers should show the chain of transmission back to my IP.

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.

Proton supports TOTP only, and not U2F/WebAuthn.

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).

Cons:

* 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.

> enjoy the process of reshuffling

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.

> when Google locks you out of your account

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.

There is a large number of threads here on HN about it.

> 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.

They are not saying App Passwords are going away.

As a note: Google requires two-factor authentication to be enabled to use this feature.

What about GSuite with custom 2FA? There are no App Password options there...

Isn't this going to break their own "send mail as" feature in Gmail to send as another Gmail address you own? Which I basically use constantly.

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.)

The heck I'm ditching Claws Mail for that slower than molasses web interface. Any recommendation for a secure and very cheap mail service that doesn't hate SMTP+POP? I'm already aware of Fastmail which would probably be my choice if I don't find a better+cheaper alternative.

Annoyingly, Google doesn't actually support app-specific passwords for accounts that don't have two-factor authentication enabled. So for use cases that require a password (eg SMTP), there's literally no other option available.

(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)

Does this mean email aliasing is gmail is going to break? I think you need less secure sign in for that to work.

I would also really like to know this. Can anyone help?

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.

Google keeps making it more and more difficult for me to use their services. It's going to be painful when Google finally forces me off Gmail.

Make the leap before you're pushed!

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 looking to do that now, since Google will starts charging for (old grandfathered) custom domains. What service are you using for emails?

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.

Any suggestions for good privacy-centric email providers?

https://www.fsf.org/resources/webmail-systems

Depends on your threat analysis. I'm a happy Fastmail user for several years, mainly due to privacy and quality of the product. Others available.

I use Fastmail and am very happy with it. I know others who are happy with Protonmail. Both place an emphasis on privacy.

The biggest thing is to get onto your own domain so that switching again if your host changes policies becomes much easier.

https://privacyguides.org/providers/email/

I use mailbox.org with no complaints.

If you want serious protection you should probably use one NOT based in the country you live in.

Does that handle the huge torrent of ads well? Seemingly every website and brick and mortar I've shopped at ever sends me at least one email per day.

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.

Spamassassin with a 7.5 threshold and other measures like DMARC checks has worked surprisingly well for me in recent years.

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.

> The unsubscribe buttons on those emails mostly work, by law

They won't for some arbitrary percentage of emails. And even then, they will keep coming from new places.

Use a unique email address for every service you have to sign up for. Optionally combined with sieve filter to sort them accordingly.

A mail client with its local bayesian filtering works fine for me, given you take a little time to flag spam and tune the filter. I use Thunderbird.

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.

I switched to posteo a while ago. I don't need much so it is 1€/month for me.

https://posteo.de/en

same here, so I use two to three browsers

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 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?

So what are the options for people who like to download all their e-mail onto a Linux box and handle it locally?

Application specific password.

With offlineimap or mbsync.

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 moved to my own domain + Zoho mail.

I sleep soundly well knowing I will never lose access to my email.

Is this turning off IMAP access to gmail mailboxes?

No, you can use IMAP without password, using app token like any other OAuth

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.

You can also still use an "application-specific password".

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.

Translation: Every account must be tied to mobile number. No more privacy

Translation: throwaway5486nv has poor reading comprehension

Its not about what's written. Its about the intention behind this.

Probably a stupid question, but, I've been using Thunderbird to d/l my gmail for ten years with POP3, leaving nothing on the server. I don't store a password on my device, I remember it and enter it. I don't use 2FA, because I consider simjacking a risk; my personal email server is my backup address if I get locked out of gmail.

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.

This is going to be a big impact for a lot of our customers. The app we use only supports user/pass auth and lots of people set up special sending only gmail accounts to just get it out and not impact security of their orgs commercial gsuite stuff. Fun times ahead.

Shameless plug: move to inbox.eu. We have migration tool to move away from gmail. We use separate auto-generated IMAP password for more secure access via standard IMAP protocol. Auto-generated passwords by our experience are secure and we haven't have problems with account hacking via them

If the passwords are being used by some automated service this is probably fine, at least modulo the quality of the service implementation.

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 agree but "advanced" users should have the ability to switch advanced protections off (for example, sending emails via SMTP or for easier migration to another provider)

Just a comment: the difference between business and personal accounts is not very clear. It looks like the business account is better, but it's cheaper. Or is that price just temporary? That slow long scrolling of the pages isn't great either. I suggest making some simple comparison table/chart.

Thanks for feedback and I agree with you. Owners of inbox.eu first wanted to market product for less technical small business people.

Now we are moving away from this business model and will give more priority for custom domain e-mail.

Soon we are launching new pricing page with feature list of free/premium personal mailboxes and custom domain mailboxes

Can some please ELIF about how this affects Thunderbird. I currently (and for years) have used POP3 to download my gmail mailbox (and SMTP to send outgoing). My Thunderbird account setting for gmail currently shows "normal password". Will I have to change it to OAuth or one of the others? Or will I need a special "password" just for use with Thunderbird (this is something my Yahoo/AT&T email started requiring last year).

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.

Since nobody else responded:

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.

Google will soon disable free access to legacy free domain mailboxes (G-Suite). When developing migration tool at inbox.eu it was major headache to implement migration from google. You either use web oauth2 login for each mailbox one by one (imagine pain moving thousands of mailboxes), or enable less secure apps option which now works unreliably or use not easy to obtain global service key to have full access to all domain (which admins do not want). Google makes really hard to move to another mailbox provider. I am actually updating migration tool to make it simpler to migrate

This kills gnus/mu through Emacs, right?

No: the announcement says you can use application specific passwords https://support.google.com/accounts/answer/185833

Honestly this seems like a good thing. Using app passwords to sign in to insecure apps instead of your actual password is much more secure, I already use that for Google and my Nextcloud instance and it makes it easier to keep track of where you're signed in. You Google account holds so much information about you nowadays that securing it is tantamount.

Oops. I have small web apps that use gmail accounts to send mail via SMTP, but this requires turning on "allow less secure apps". Will this break those apps? I suspected this would happen eventually and it's been finicky the past year or so anyway. It was a lazy solution to begin with -- so, I'm setting a reminder about this for May 20th.

Sadly I believe it will stop working.

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...

Thank you for that comment, very helpful.

I should add, as many others have pointed out, that moving to use app passwords is a _much_ easier solution in the short term (how long they will be supported I have no idea) so I suggest you try that first.

This should have been the first thing I tried but, rather unhelpfully, the Google page where you create app passwords says "You'll only need to enter it once so you don't need to remember it" and later "You won't need to remember it, so don't write it down or share it with anyone.". This suggested to me that these passwords are single use (i.e. a OTP) but testing suggests that this is not the case. Also, whilst using app passwords requires that you enable 2FA on the account, they do _not_ require you to enter the 2nd factor when logging in with the app password (obvious in hindsight, but not made clear by the documentation).

I just tested that these work even when "less secure apps" is disabled at the domain admin level (and by extension the individual account). Indeed, after enabling 2FA for the account the option to enable/disable "less secure apps" is removed. So it seems that you can either have no-2FA + (optional) less-secure apps OR 2FA + app passwords.

Looks like they're not disabling the "app passwords" feature. So you can still do things like IMAP via that.

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.

I had to turn this on to transfer emails from Workspace to a free Gmail account with imapsync.

I used the 16-character App Password. It requires 2FA to be enabled though.

Relatedly... I also can't sign in via embedded browser. I understand they have reasons, but like, shouldn't there be A way to do it if it's an embed that you trust? I don't get it.

Ok, it's not less secure. But i hope this won't affect my NeoMutt set-up and that 'application password' work around will work as it does now.

Every application / service that insists on using Google / FB / Whatever as sign in method exclusively is a 100% no go for me.

We use pop3 access to gmail accounts for all our automated sign up tests. Will this break that?

Does this means that the curl hack to send email won’t work anymore? If so, that’s a bummer

Is this the end for git-send-email through Google infra?

No: the announcement says you can use application specific passwords https://support.google.com/accounts/answer/185833

why is google's font so damn tiny? It's like they don't want you to read this stuff.

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)

It is not your data, it is data for google to mine.

Google "engineering" excuse everytime is it is for your safety

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.

Have never experienced that since switching back to Firefox after years on various Chromium browsers.

Developer Edition, on Windows fwiw.

As others have mentioned it's probably privacy extensions blocking google's checks.

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've never experienced this and have used FF for years.

I've been using Firefox for years, never faced this issue before... have you tried updating your browser?

> have you tried being a botnet enabler?

Heh.

How is updating Firefox enabling botnets?

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 device is probably pwned. But go ahead and blame Google. I love how people just ignore these warnings.

“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 are telling you.

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".

It's probably uBlock or some extension that blocks Google's tracking.

That message is generally when your user agent doesn't match Google's list of allowed browsers.

It has nothing at all to do with how secure the browser on the end user's computer actually is.

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.

No, Google are pretty specific that they have a whitelist of user agents for their properties. [0]

[0] https://support.google.com/mail/answer/6557?hl=en&co=GENIE.P...

There's a huge difference between "supported" and "whitelisted".

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.

I set my UA to "Bob Dobbs 42.69". It still loads, and it doesn't say "your browser may not be secure" which is what this thread is actually about.

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.

How are we supposed to trust 'your browser might not be secure' when Google benefits directly from hobbling everything that isn't Chrome?

Every device in a walled garden is pwned, is it not?

This is often the result of browser extensions. Specifically, CDN replacement extensions like Decentraleyes or LocalCDN.

I only use uBlock origin, but also do DNS level ad and tracker blocking separately..

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

Edit: adding my fastmail referral link just in case https://ref.fm/u26310488

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).

Password managers are just another liability. One more thing you could lose the password to. What if the service shuts down entirely?

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.

> and will now have to bear a recurring payment of $6 monthly

Is this the cost for gmail to use a custom domain? or is it a very expensive domain name spread over 12 months?

Google is phasing out free "apps for your domain" accounts, so starting in a few months it will be necessary to pay a monthly fee per user.

I see. At least you have the freedom to move email hosts though.

Do you really need to switch? IME most services don't really use email for anything.

> It would be a royal pain to switch now.

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.

Not being able to review things in the Play Store was a blocker for your free G Suite account?

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.

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.

You can set the registrar to autorenew.

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?

gandi.net

There are DDNS scripts on github to update the DNS record. Picked gandi a very long time ago and have no complaints.

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.

2028 headline:

"Australian intelligence services decline to comment on massive data breach."

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".

And then some version of Russia-Ukraine happens with Australia where you are locked out of your email accounts and all bets are off

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'll add a thumbs up for Migadu! Great service, great principles, I'm a happy customer. It's also pretty cheap (specially if you're a student).

https://migadu.com

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.

> 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.

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 hope YouTube Vanced keeps working since the stock Android YouTube app is complete garbage.

So many startups implementing absurd ideas, when the best opportunity is right in front of your eyes.

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?

Reply on news.ycombinator.com