I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally.
By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience).
The wording seems to imply that if, on a yearly whim, someone at Google decides to "empanel" a security assessment team, you have no choice, you will not necessarily be asked permission and you will be paying that invoice whether or not you needed that assessment.
Do you have evidence - in writing - to the contrary from a Google official?
Abridged wording and my non-lawyer interpretation below in case I'm not clear:
> Every app that [accesses Gmail and also accesses other servers] is required to go through a security assessment from Google empanelled security assessors. [...]
> In order to maintain access to restricted scopes, the app will need to undergo this security assessment on an annual basis, [... costs usually] between $10,000 - $75,000 (or more) [...]
> This fee may be required whether or not your app passes the assessment and will be payable by the developer."
> you will be paying that invoice whether or not you needed that assessment
They don't just send you a bill for $10k. You can opt-out of the yearly audit by removing your use of restricted scopes.
But yes, it is a yearly required audit, and they're serious about it. This limits the kind of apps that can be built on Gmail (basically – no free apps), but it is undoubtedly better for end users.
Having gone through the process, which checks among other things that data can't be resold, tokens are encrypted, user data is really deleted when you say it is, and that Gmail API access is auditable in the event of a breach; these are all good things for users.
(My auditor was so thorough they actually found a high-impact XSS bug in Firefox – the bounty covered part of their fees.)
The context here is Free and Open Source Software that accesses email.
Software that, for now, under Google's current interpretation of the rules, is allowed to use their OAuth without paying these fees.
The question I'm asking is, what happens next year when Google decides to silently change their interpretation of the rules? Do you, as a FOSS email client writer working on JohnnyMail, risk a massive yearly bill of 1/6th or more of your salary that you are contractually obliged to pay - or just say "Sorry Google, you've outpriced me" while their interpretations are still favourable?
It's not "undoubtedly better for end users" that free email apps be excluded from Gmail. It's not better for end users that open source software developers are given a sword of Damocles hovering above their heads. Sure, it's undoubtedly better if these free apps can be guaranteed to be secure, it would be even better if Google could do that in a way that didn't cost a massive amount or a surprise bill.
I'm glad you had the resources to be able to go through the process, and that you found it a useful process to go through. But it doesn't justify the uncertainty.
It's not necessarily better for the users. I'm one of the founders of a free and open source service which simplifies the process of sending CCPA/GDPR data deletion requests. A common request from our users is to give them good recommendation on who to opt out from.
A new compatitor has implemented a feature where they use the Gmail API to analyse a user's email exchange (from their servers) in order to recommend who to opt out from. It's very effective, and even though I would never give a 3rd party access to my email account most people do.
Now we thought of implementing a similar feature, but from the client side (which is a bit less effective but much more privacy respecting). Now I'm not sure from what I read if we need a security audit or not, but the risk and the extra work isn't worth it for us. We're a nonprofit.
Our compatitors on the other hand are a VC backed commercial organization. They make money buy providing a service to the companies they help people opt out of. The whole opt out side is just a way of manufacturing demand, so you can guess where their loyalty lies. But because they are well funded and because sending opt out emails is basically marketing for them, it makes sense for them to pay for an audit.
Yeah, it’s what I was told by a member of the verification team last year (as long as everything is clientside, you can bypass the audit). Before you build anything you should request the restricted scopes in Google’s Cloud Console as if the feature is already built, to kick off the verification process. Then you can ask a human for clarification (IIRC the exemption isn’t mentioned in the FAQ). Assuming it’s okay, you can then build the feature and resubmit your request. Best of luck!
the user already suffers by "Google" cross-financing all these free things (from search itself to mail, chrome, android, and ... go, k8s, project zero, and who knows what)
and I've added the quotes because of course everyone else does that, and it trains users (and now since everyone is a user it basically conditions society) to have unrealistic expectations, skews what people value, completely fuck up the market (hard to compete with free)
...
that said, in the end the user gets what it wants "opt out", and it's free for them.
Google SHOULD NOT promise anything else. This is critical for users security.
Yes, developers and business claim they make user data, privacy and security a top priority. As we have seen from plenty of developers on the facebook platform, if not checked, they far to often lie, betray users trust or are just totally incompetent.
At least on the business side, giving restricted scopes access (ie, enabling a third party server to read all emails in a domain) is a major permission. It needs to be treated like this. In many cases a problem here unlocks a LOT more because email is used the default password for everything (via password reset options and more).
I hope google holds a firm line here and doesn't bow to hacker news type social media pressures - we have too much evidence of bad and poor behavior by developers to just trust them.
Yeah, imagine if users didn't have benevolent Google protecting them, some unscrupulous company full of unethical developers might scan all their personal email, or monitor what websites they visit, or even collect biometric data and then track their every waking movement in the real world.
Let me repeat this very clearly here. HN folks seem to think that developers in the internet at large are "good" and google is evil. Or that things like google asking random developers from china to go through a security assessment is appalling.
I can tell you that for businesses and others spending money (ie, where the business is the customer and not the product) the perspective is opposite this.
A business wants google to track users so logins from unusual locations / devices go through more rigorous authentication. That is considered a benefit, not a harm.
A business wants google to scan everyone's email - for everything from phising to spam to malware. This is considered a benefit not a harm.
I think folks here underestimate just how trusted and core to many individuals and businesses google is. Many folks trust google MORE than they do their own goverment, including on issues of spying on emails and more.
The goverment leaks everything - from photos of dead celebrities to tax returns. Many goverment are active in spying on their users as much as they are able. Around the world, brands like Apple and Google considered evil here on HN, have just insane brand value.
Again, Google are idiots if they were to go the facebook route and not keep the private info they hold pretty secured. The downsides are SO much larger for them (see Cambridge Analytics) than the upsides of allowing random third party internet developers to access someone's email on an ongoing and programmatic way without these types of controls.
Yes, obviously business are happy to fob off liability to Google (right up until Big G closes their account and kills their business). What's your point? That businesses don't have users' interests at heart? Next you'll tell us the tooth fairy isn't real.
The point isn't that Google is evil and random devs are good. The point is that Google is amoral and harmful - and also enormous and powerful. Random small developers may be good, bad, whatever, but they are diverse and individually powerless. Should you be more afraid of the Stasi or of a neighborhood burglar?
Not sure where this is from but there's a critical part of the quote missing here:
> Every app that requests access to restricted scope Google user’s data and has the ability to access data from or through a third party server is required to go through a security assessment
An email client that only transmits data to/from Google's own IMAP/SMTP servers does not have the ability to access data through any third party server, and thus does not require the audit.
What about e-mail clients which allow you to configure multiple accounts at different e-mail providers? Those will be able to access your Gmail data, and also "data from or through third-party servers" in form of receiving or sending e-mail via different mail servers.
Is it not "proxy" like servers they are talking about? You login and the details are stored on a server which does push notifications and the like... instead of your phone polling or pulling email all the time, the proxy server sends a push to the app to update when new mail arrives... is this what they mean?
It certainly includes that, yes. In fact, mobile push notifications is one case that I hadn't even thought of. If you use a third party to perform push notifications, you are "accessing" data through a third party application.
(I'm presuming the word "accessing" is used here to mean any use of a third party server, regardless of whether read or write - because the whole idea is pointless if transmitting is not included in the definition)
It also includes any email client with a built-in VPN, or potentially any client that can use a VPN (remember, it's at Google's discretion)
> [accesses Gmail and also accesses other servers]
... because that's all that convoluted line means. Break it down:
- Access to "restricted scope Google user's data" (in this case, all we care about is Gmail)
- AND ability to access data from or through a third party server.
It's that last bit that people seem to be getting confused about. For example:
- if your app accesses Gmail and Hotmail accounts, then your app is doing both
- if your app accesses Gmail and also checks today's weather, you're doing both
- if your app accesses Gmail and sends basic usage telemetry. Or checks for updates. Or has plugins that provide spam checking or virus scanning... you're probably doing both
- if your app has ANY plugin system, it could be argued that your app is doing both.
While the language may be unclear, "third party server" is probably intended to reference any non-google service.
And my overall point still stands: YOU do not get to decide what triggers their security review. All you have the right to do is pay the bill.
Well, certainly they haven't ruled it out. DNS servers are third-party servers. VPNs are third-party servers. They can be as kind or as nasty about this as they like,
For all my fear mongering, I should point out that the only reason Google are saying this is to cover their backs when they decide to levy the maximum fee on an unsuspecting competitor. If they don't consider you a direct competitor, you might be ok. They have no reason to use this policy to alienate the majority of desktop applications that connect to email.
> The third party audit is not required for email clients that run on end users computers and store credentials locally.
It might not be required for applications that run locally, but they don't tell you whether or not it will be required until after you've already done the work to create the app.
The exact wording from the FAQ is:
"Local Data Storage: Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device. Local client applications that only allow user- configured transmissions of Restricted Scope data from the device may be exempt from this requirement."
Keep in mind that any email client that allows you to reply to (or forward) an email would count as transmitting restricted scope data from the user's device.
> Ensure your app complies with the Google APIs Terms of Service, Google's API Services User Data Policy, and the Additional Requirements for Specific Scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users data from or through a third-party server.
In the case of an email client data is transmitted directly from/to Google's own IMAP/SMTP servers and not a third party, and is thus exempt from the assessment.
> Keep in mind that any email client that allows you to reply to (or forward) an email would count as transmitting restricted scope data from the user's device.
> and has the ability to access data from or through a third party server
So Pegasus Mail accesses your email from their servers? For reference, they have an entire flow designed so that the auth credentials never touch the app developer's server for desktop and mobile apps - https://developers.google.com/identity/protocols/oauth2/nati...
I don't think that's what Google are saying here. I think the sentence is referring to Google user data; as long as the Google user data or credentials to access it does not touch another server, the entire thing does not apply.
In fact, in Google's guidance on this subject, they say:
> Local client applications that only allow user-configured transmissions of Restricted Scope data from the device may be exempt from this requirement [to get a Letter of Assessment].
And in another FAQ:
> Local Data Storage: Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device. Local client applications that only allow user-configured transmissions of Restricted Scope data from the device may be exempt from this requirement.
My feeling is that the author of Pegasus Mail has checked a checkbox incorrectly somewhere, or alternatively has not implemented the desktop oauth2 flow correctly.
I’m super confused about this too, there’s tons of open source apps that use Sign in with Google. Shoot, I’ve used the SDK myself in little apps and never saw this.
"Sign in with Google" is just a button that apps are required to use when they allow the user to interact with Google in some capacity, but don't have their own account management system. Most apps with that button don't have the ability to get any data from Google other than your name and email address though; for apps where you are granting OAuth access to your Gmail, it is very obvious that you are doing so, so it's not likely that you have done it accidentally in the past. (Although you can obviously check on myaccount.google.com)
Moves like this from Big Tech deeply disturb me. I wonder how long it will be until everything you do with them will require their approval. We're already seeing this in the form of "supported browsers" (i.e. Chrome) and their efforts at painting everything else as "less secure" or "insecure". It's time we started pushing more for freedom over "security", before things become even more dystopian...
If you don't have the time or resources to go through this process you can also use this simple proxy of mine, which intercepts the non-OAuth IMAP/SMTP commands and adds OAuth in the background: https://github.com/simonrob/email-oauth2-proxy/
Oh, it's certainly not an excuse for Google requiring this process. However, if you do want to use Pegasus Mail (or any other non-OAuth app/script/email tool, etc) after the end of May, this is a way to do so. I think it's quite a safe assumption that many of the HN audience are capable of using it, too ;-)
We used it on our LAN around 1993 hooked to a local mail server (which ran on a Windows box using Netware I think - it was sitting on a filing cabinet next to my desk) that in turned fetched mail from the campus mail server. It worked really well and the local mail server let us easily share/email large attachments within the department as they never left the LAN.
Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in.
When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap, which is not imap) that's the end of gmail for me.
OAuth is hardly Google only, it's part of RFC7628. There are very good reasons why a simple password login isn't necessarily what you want for your email protocol. IMAP and 2FA are often at odds, for example, usually leading to vulnerable application passwords that bypass security requirements out of necessity.
I don't think many email clients support OAuth2 (Thunderbird does, but that could be Gmail specific?) but the concept isn't inherently bad, in my opinion.
I don't really see the problem with OAuth2 itself, the email space is just very very slow at accepting new standards. Dovecot and UTF8 email addresses still don't play well together, for example. The lack of proper on-the-fly application registration for mail servers is annoying, but supporting them should be easy enough if the mail service isn't run by complete doofuses.
To be clear, I never said OAuth2 was google only. I said the standard OAuth2 is so much not a standard that an implementation written for Google's imap+OAuth2 will not work for any other email provider's imap+OAuth2.
OAuth2 is a suite of protocols and standards you can use to build an auth system from people who have been working on auth systems for a while. it isn't strictly designed for federated auth, and arguably is targeted at internal systems because there are so many parts are "you need a system that does this, but how is up to you"
OIDC builds on OAuth2 to fill in those gaps with prescribed details and add additional systems necessary for a workable federated auth system. it _should_ be possible to use it entirely provider-agnostic fashion, but in practice it's like any complex protocol with optional parts in that implementations have incorrect bits or idiosyncrasies (why does Azure's provider sometimes serve public keys it doesn't actually use to sign tokens in some modes? god only knows) and you'll probably only provide integrations for a subset of providers, not just let anyone with a discovery link show up and use it.
I mean if you take some email client application that went out of it's way to support OAuth2+imap for google via a plugin then even if you replace all of google's info in the plugin it won't work for other OAuth2+imap implementations. Every OAuth2 implementation is a different thing, as you say. But the megacorps are pretending it's some standard protocol. It's not and the fallout will be much worse than people having issues because they picked easy passwords.
This is massively different than actual protocols like pop3 or imap where all you do is change the info but the protocol stays the same.
I have no idea what you are talking about. Every Google service (not just GMail), and every major service provider on the internet, uses OAuth 2 as the standard for authorizing API access.
I was aware of the security-audit-at-your-own-expense requirement, and I am not a gmail app developer, I just did a drive by of the documentation 1+ year ago...
As a gmail user, this actually seems like a sensible thing. Gone are the days when users are trusted to just click 'allow' to let some random third party access all your data. It turns out, users don't fully understand the ramifications of that, and complain loudly when the 'free personality quiz' they allowed goes and downloads every private email to use for marketing.
So, if I can't give access to my mail to a random untrusted third party, the next best thing seems to be to give access to someone who has at least had their systems audited and who at least has enough money to pay for an audit, meaning they probably have some business plan and can be tracked down by the courts if they mishandle the data.
Which is why I never published it (although I have been using it for almost two years), and setting it up requires a series of laborious steps of activating the Google Developer Console, creating API keys etc., which I found just to embarrassing to put in a README :)
> 'Publishing the app' in Google terms requires a quite astonishing number of steps
this is my main gripe with oauth for login -- the amount of overhead for getting it working is absurd. it's not private (goog knows which users use which sites) and there's too much preapproval (company consuming oauth has to have a dedicated google project for each login system)
better, simpler system would be 1) client site issues random token, 2) user forwards token to google, 3) google signs bundle with user's email address + client token, 4) client site verifies bundle with goog's public key
all communication should be through the client, the three way handshake is absurd and some legit sites don't implement the standard correctly
oauth for access federation maybe should require more setup but idk -- I feel like we haven't thought through access federation as a society
I haven't seen a single comment (at time of posting this) touching on the cost aspect
The cost of the assessment typically varies between $10,000 -$75,000 (or more) depending on the size and complexity of the application
As he says, even if Google classed his as a small app (unlikely)
"Regrettably, these kinds of fees are far beyond what I can afford, given that I rely on donations from my users to make ends meet: even the $4,500 fee is well beyond what I could find on an annual basis. "
I get that doing proper auditing is expensive and the costs are within industry rates but to me it reeks of slowing turning the screws by boiling the frog on the slow path to monetization. (many mixed metaphors I know)
It looks like this pay-for-play method is going to have a chilling effect on any developer creating an alternative Gmail interface. Same with removing IMAP.
The video isn't really that hard. You just make a screencast of yourself downloading email while saying "now I'm using the download email scope", and then sending email while saying "now I'm using the send email scope."
They don't care if the videos are terrible quality, it's only for them to understand what they're approving, and to have some documentation if a developer later changes an app to do something nefarious.
I'm sympathetic to the extremely legitimate security concerns here, but it's pretty rich for the "open, we're so open" company to be running a classic 90s Microsoft Embrace Extend Extinguish playbook on SMTP/IMAP which, for all its faults, is one of the more important open protocols undergirding the internet.
you can use SMTP to access GMail and auth via a web browser based flow (OAuth2/OIDC), this added extra security is needed if there's an additional server in the mix that manages the OIDC tokens for the user
App passwords are only available for 2fa enabled accounts, while OAUTH is available for everyone. So far I didn't get a clear answer if "the end of less secure authentication methods" means the end of app passwords as well, or only the end of signing into IMAP with your main google credentials.
There's a bunch of third party "indie" email apps, how are they doing it? Is this potentially just some boilerplate text and they evaluate the rate based on the size of the project in the end?
I'm currently using https://mimestream.com/ and I somehow doubt all of them had to pay that kind of upfront money.
I don't think the problem here is that users can still use app passwords instead of OAuth2 - it's that the developer went through the trouble of developing a OAuth2 implementation, went through the necessary laborious steps to submit the application and then was faced with this message:
> The cost of the assessment typically varies between $10,000 -$75,000 (or more) depending on the size and complexity of the application; smaller applications may see costs at a lower threshold of $4,500
The Google documentation regarding Oauth access to Google APIs including Gmail explicitly mentions this requirement. It should not have been a shock to the author. Also this requirement only applies if the app is intended to store the data on a server. An email client which directly accesses and locally stores the email would not require a security audit. Pegasus would not be the 1st email client to use OAuth2 with Gmail and others have not required an audit. Some of the newer email client services which implement advance features by downloading email directly from Gmail to their own servers on the backend to do processing of the email would require a security audit.
Yep. All these anti-google complaints sound so useless. What did they expect? These issues are always an entirely self-inflicted problem. Google's terms of service are public, clear, and completely unacceptable. Why people keep using their services is beyond me.
For example, my email is in Google. There are things related to e.g. evidence for litigation from many years back. I have documents shared with me in Google Docs.
Google used to be pretty good about "don't do evil." I've degooglified what I can, but I can't degooglify 100%.
I'm confused… Why do they want to support the OAUTH flow when they can just the normal app password flow without any change in their code, just documentation for their users.
Maybe because the first line on the page you linked reads:
> 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.
So, for Google, App Passwords are clearly "second class citizens", deemed insecure and not recommended. And, as an app developer, you probably don't want to be seen as recommending an insecure authentication method?
The OAuth flow is better. It is easier for users and supports many more methods of authentication.
Really the biggest downside about the OAuth flow is that it requires a relationship with Google (a client key). If this could be a fully decentralized standard it would be fantastic.
I have one question in this regard: will I still be able to access my mail through my own script I myself wrote? I understand I will probably have to make some changes and click some things in GMail settings but is this still going to be possible or will I too have to "publish app" even if I only mean it for my own private usage?
This is so hard. I bought a domain and even started paying for (non-google) email on it over a year ago. But I can't bring my self to start the painful process of migrating everything.
What it'll take is likely a cost/benefit for keeping your non-gmail-website workflow (and taking the leap to jump off gmail) vs. complying and using their (mostly usable) webmail site.
They likely figure most will choose option#2 since it's so painful/expensive to do #1.
Went through this process with Mail Designer 365. Luckily as we only need sending access, the requirement was less arduous, but the process was not great.
After submitting it took ages to get reviewed and even when it had been processed the status wasn't entirely clear.
At the time it was made clear that using app passwords was considered a risk and users were receiving emails about it being a security risk.
Why can't I just enter my own Google client ID/secret on the app and auth against that? There's no approval from Google needed in that case, since I'm not publishing it anywhere.
Does anyone has a link for that ToC? I'm curious what kind of use cases that need such payment. E.g. if I want to make my app to use Google login, I think it's completely free?
There is only one thing why this is done: to make impossible to move from gmail (also with custom domains) to another provider. We have the same problem. We spent hundreds of hours implementing their legacy auth (less secure apps), gmail oauth2 and domain-wide delegation to be later stuck in approval process. Until our app is not approved users can not use e-mail import/migration tool to our inbox.eu service. And there is lot of demand for that because people do not want to pay so much for e-mail. Shame on google... they also do not provide reas-only access to IMAP which is more than enough to export your mailboxes to other e-mail providers
This isn't true at all. The reason Google does this is that there is a huge ecosystem of random apps that request full access to people's mail accounts, which are the most sensitive accounts on the entire Internet, and many of those apps were hot garbage that generated a huge account takeover problem. It's perfectly fair to not like the policy (I don't like some things about it), but it's not reasonable to caricature it.
You seem to had never gone trough this approval process. There are many dark patterns there:
* Asking for huge amount of money in the of the process (after you wasted hundreds of hours of expensive developer time)
* forcing to use restricted scope (read,White,delete) for standard IMAP access even if you need only read-only access or use their proprietary API with read-only scope with unknown rate limits and which is difficult and time-consuming to use
* cryptic messages why app is not approved and ignoring arguments made for their questions
* often changing APIs (access token formats)
They do everything to avoid competition not making better product but by locking existing customers to their ecosystem.
And this is not only google. We had similar issues Apple and Meta.
I am, because reasons, quite familiar with the security review portion of the process. Not only is it mostly/probably not run this way for anticompetitive reasons, but Google doesn't even run the audits; they picked specific auditors (last I checked, Bishop Fox and Leviathan), both of which have gold-plated reputations.
Like I said, there are things I don't love about the program. But it's not an elaborate hazing ritual.
> many of those apps were hot garbage that generated a huge account takeover problem
Are there any publicly known examples of this? I'm not doubting that it's happened, I've just never actually heard about any cases of this with respect to the Gmail OAuth API specifically.
this implies you won't be able to use Firefox, or Safari, to access Gmail unelss they're willing to fork over their source code and pay the $$$ because all of those are
>...[an] app that requests access to restricted scope Google user´s data and has the ability to access data from or through a third party server
Users should not be subjecting all of their correspondents' communications to US warrantless surveillance anyway; Google is doing the world a service by making their service harder and harder to interoperate with.
Gmail and other huge centralized points of censorship and surveillance must be destroyed. If you are a user, move away. If you are a developer, do not support these closed systems.
Moving your data out of US jurisdiction doesn't shield it from US warrantless surveillance, but rather maximizes its exposure. The USG ostensibly requires due process (a warrant, whatever) to obtain information from US servers. It does not require any due process to obtain data from foreign servers. Coercively obtaining data from foreign servers is literally the chartered job of the NSA (of all signals intelligence agencies around the world, really).
This is a super common misapprehension people have about data locality and surveillance, and it's no surprise that marketing plays off it ("keep your mail in Switzerland, so it's subject to Switzerland's strict privacy laws!").
There are other reasons to house things in Switzerland (or the Lesser Antilles or wherever). I'm not saying you should use GMail (unless security is a concern of yours, in which case you should use GMail).
> The USG ostensibly requires due process (a warrant, whatever) to obtain information from US servers.
This is no longer true, as Ed Snowden showed us. This is literally the point of their secret interpretation of FAA702. Pretending otherwise is nonsensical. The USG, just like the CCP, gets whatever data they want, about anyone, from servers in their own country, without due process.
Anyway, my comment was not about jurisdiction, just about surveillance.
Regardless, Google obviously has the plaintext if you use Gmail. You don't want that, either. The USG will probably only use it for a subset of things; Google has no/few limitations on the use once you voluntarily give them such a huge trove of data about your life, travel, vendors, and purchases.
I don't think you're totally following the logic. Stipulate that whatever legal process there is in the US for NSA (or any other intelligence agency) to get data is performative and easily bypassed. There is no legal process whatsoever for NSA to obtain that data from foreign targets. If you're worried about the Five Eyes SIGINT agencies, "foreign" servers are strictly less safe.
Do you honestly think that using Gmail protects me from the NSA? If the NSA wants into my computer, it's in.
Secret services swap their data, so they can all read my santa letters.
There is the viewpoint that one should prefer one's own jurisdiction regarding storing data (I know you don't like Schneier but he e.g. holds that viewpoint).
I use an email provider from my country. If a judge from my country wants to persecute me, they have to complete a legal request which is tested by my provider.
If I used an email provider from Switzerland or the US, is that also the case?
Also, it's important to think of the economical aspect. If i financially support providers in my home country that lobby for better privacy laws and don't engage in surveillance capitalism like Google does, isn't that creating a good alternative that can also be properly regulated?
Plus, it's one dependency less from a (more than) half MAGA country.
So your recommendation makes sense if you are a citizen of the USA, but not everyone here is.
Addendum: what do you actually mean by "security"? For me, that is also "being able to access my email account whenever I want" and that this account doesn't get closed, even if I do shit on the internet, whoever that decides. Google shouldn't have the right to say "these actions are uncool so let's kick this guy" (never happened to me, but I don't even have a contract with Google!, they have the right to cancel my account whenever they want.).
I agree wholeheartedly in principle, but the reality is that it's nearly impossible to escape Google getting their hands on yours and your correspondents' messages at some point. So many businesses (and third party email providers!) use Google's services on the back end, and many relays out there are owned by Google/Alphabet even if it's not readily apparent, that the only way to even attempt to avoid them is using encrypted email. Unless everyone you communicate with (including companies, governments, and other organizations) is willing to only communicate via encrypted email as well, it's a lost cause.
No, the perfect is the enemy of the good here. "Email is insecure anyway and Google is big, therefore it's ok to give the adversary 100% of the plaintext" is not sound logic.
This is not some principled stance, it is a clear and practical command: stop using these services.
If your personal email address ends in @gmail.com, you are doing it wrong.
I am wondering if it is really legal for Google to even ask any money from 3rd party developers to use GMAIL (what should be) open standards like SMTP and IMAP.
It might be immoral, but if you're trying to make money using their service I can't see there being a legal reason to prevent them doing this. I meant, they (Google) need the money right? Companies like this seem to get to the point where they feel justified in charging for every little thing that wouldn't kill them to give for free.
I believe many comments here will criticize Google. But objectively, Google is at its best here:
- in terms of privacy, applications that have access to your Gmail inbox now require a security audit.
- the audit is not required for MVP (<100 users) or applications internal to a Google Workspace org.
Of course, you have to pay for the audit. But:
- it’s only required when you ask for restricted user data (i.e. reading my emails).
- Google doesn’t take 30% of your revenue to use its API - which is free by the way.
To me, Google has created the perfect world for developers here. And that says a lot when I read the developer of Pegasus Mail doesn’t want to record a 2min long YouTube screencast to get approved.
Also, just wanted to kudos the Google OAuth team that has greatly improved their process in the past years. If you follow the guidelines, you can get approved within a day now.
My issue with this is that to access my own email I get countless warnings, and always have a 'You have recommended actions' Security Checkup for 'Remove risky access to your data'.
This is after jumping through a bunch of hoops to create a GCP app. It even complains about the pseudo-app being from an 'Unverified developer' despite that developer being me.
You _have_ to create a video. That’s a requirement. You don’t event have to talk or show your face on it though. I agree many people doesn’t like to record videos, I’m one of them, but you are a developer and your app is going to be available to 1.5 billion users of Gmail. Complaining about having to record a video (which is what Pegasus dev did) is not _normal_.
> You _have_ to create a video. That’s a requirement.
How is that in any way related to your comment that he shouldn't complain about it? If it wasn't a requirement then there would be no reason to complain in the first place.
And that's not even what his main complaint, his main complaint is that he shouldn't have had to record the video in the first place because the warning about this feature costing money should have been documented somewhere together with all other requirements.
Basically Google is behaving like that website that tells you "your password should be more than 8 characters", change password submit, "your password should be less than 16 chararcters", change password submit, "should contain at least one upper character", change password submit, "should contain a special character", change password submit, "should not contain single quotes or other characters that are too special", repeat ad nauseam. If you have requirements document them up-front and all in one place.
Google will be blamed if someone's data is misused even if that person authorized giving permissions to that app. If you want evidence supporting that, take a look at how much flak Facebook received with the Cambridge Analytica scandal.
100 lifetime signups isn't anywhere near enough to know whether or not an app is commercially viable. If the cap were something like 10,000, or even 2,500, then there would be a lot less complaints.
By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience).
[1] https://kanmail.io