Hacker News Reader

The problem with Google’s security certifications, especially when compared to competitors like Salesforce and Microsoft, is how disorganized the process is. While these companies all require security reviews, Google’s approach seems particularly disorganized: if something goes wrong, there’s almost no one to contact for help.

The certifications themselves are valuable, but Google’s main issue lies in its poor communication and support. Third-party developers, even those paying $60k annually for re-certification, struggle to get timely responses or any at all.

What’s ironic is that the very partners handling these certifications often avoid using Google themselves because it’s “unreliable if something unusual happens.”

And that’s the crux of the issue—when things do go wrong or something unusual happens, it’s incredibly difficult to resolve.

100% agree. Again, my position is that Google rightfully deserves all the criticism they get around communication and customer support. I just think it's a mistake to confuse that criticism with Google's change to enforce better security for highly sensitive permission scopes.

Probably not news to you, but those are completely different departments within the company with opposing goals.

I fail to see how the app vendor comes into play here. There should be no "whitelisting", but the user as the active party just uses some sort of tool (may it be online or a native app) to authenticate (e.g. via OAuth) and that's what establishes trust on the tool.

Of course security is good, but this is just hindering third party access.

> if you want complete, unfettered access to my entire Drive account,

Panic never got complete or unfettered (or any) access to my Google Drive. I got access. I used their application, which can easily be supervised with Little Snitch or other software to prove that is not sending a copy of my credentials or my files to Panic. If it were OSS it would be even more categorically provable that it's not giving access to anyone but the end user, but these draconian requirements would still apply.

The point is, Google is telling THEIR users, not Panic, that they aren't qualified to use their own judgment to select a client. It woudl be just as bad as Microsoft saying that if you want to check your email or access SharePoint you can't use anything but Edge (insert jokes about how they basically did do that 20 years ago with MSIE, but let's be serious, that sort of thing would be rightfully mocked today).

> I don't think it's a bad thing that Google is enforcing some minimal security standards.

These certification programs are 100% a moneymaking program to engage in a lot of box-checking, which I'd wager has zero correlation with a positive outcome for anyone other than the shareholders of the "labs" that do these audits.

> The point is, Google is telling THEIR users, not Panic, that they aren't qualified to use their own judgment to select a client. It woudl be just as bad as Microsoft saying that if you want to check your email or access SharePoint you can't use anything but Edge (insert jokes about how they basically did do that 20 years ago with MSIE, but let's be serious, that sort of thing would be rightfully mocked today).

Isn't Google doing the same thing today with YouTube? Isn't that what led MS to give up on EdgeHTML and adopt Blink instead?

That seems like a poor argument for an app which doesn’t mirror data or accept commands remotely (if I can control your app on your device, I can control the official Google Drive app) but there is a general point about full drive access. However, I think the answer there is for Google to improve the security model for Drive - for example, allow the user to select a non-root folder which Transmit or iA Writer can use and have some UI indicating that it’s shared. Instead, this process serves as a competitive moat and isn’t very effective – all of the large companies that we’ve seen getting breached are going to pay KPMG to spend time on performative box checking, and your data will still be exfiltrated but they’ll at least say they’re very sorry.

> However, I think the answer there is for Google to improve the security model for Drive - for example, allow the user to select a non-root folder which Transmit or iA Writer can use and have some UI indicating that it’s shared.

The oauth scope https://www.googleapis.com/auth/drive.file [0]basically allows this. If memory serves the app can use this scope, create a folder, and have access to things within that folder, it can certainly have access to all files created via the app (which should in general be true for iA and probably also Transmit). Offhand, I don't actually see what iA or Transmit are doing that needs the broader scope, though TotalCommander, trying to be a replacement file manager would still need the biggest scopes.

[0]: See https://developers.google.com/drive/api/guides/api-specific-..., the drive.file scope is non-sensitive so it needs a much more cursory approval process

Transmit is a file transfer app; it's used to get access to existing files on your own Google Drive without installing Google Drive's native app. Limiting it to a subfolder would defeat what I believe to be the most common use case.

It’d depend on what exactly you’re using it for - as an example, if you’re backing something up regularly that’d be fine.

The main thing I was thinking would be beneficial is getting user confirmation at better than the whole drive level. I think Google is trying to prevent cases where a third-party stores tokens on their servers which are breached, and in that kind of scenario it could be useful to push for scoping so e.g. if iA were breached the attacker could get your screenplay draft but not the folder where you backup your password manager or financial data.

How do you know it doesn't mirror data or accept commands remotely, or that it has no vulnerabilities/backdoors which can make it do so? Perhaps you could do an audit of it or something...

Are you under the misimpression that KPMG or PwC to fill out a checklist will catch a back door? They’re looking for things like whether your servers have an old OpenSSL library or your code doesn’t escape values in SQL, which is pretty low-hanging fruit even on hosted apps and much less valuable for local apps.

> If you can't afford the new audit requirements ... then I'd really question your ability to appropriately safeguard so much critically private data.

Because large companies that can afford it have proven to be exemplars at safeguarding private data?

If you can't afford to buy starbucks every day, I'd really question your ability to buy a private jet. However, that doesn't mean that being able to afford to buy starbucks every day is sufficient to being able to afford to buy a private jet.

Like google? Yes, I think so. Probably one of the best track records among big tech, so maybe their security practices should carry more weight?

Lets just say this: the US Federal Government, several large health care and health insurance organizations, several large financial institutions, a major university, and several others have all had to send me "We take security seriously" letters. They could all afford to undergo (and had passed) various security audits. But in the real world they failed.

They aren’t demanding you meet their practices. They are demanding you meet whatever the approved auditor thinks the practices are.

Certification schemes like that don’t have a good track record.

They're my files in Google Drive. If I've made the choice to buy a product from Panic, and I trust Panic as a company personally, it should be my right to decide to give Panic access to my files in Google Drive. It is not up to Google to shuffle money into the pockets of their security partners under the guise of doing it for my safety. My safety and the safety of my files is my responsibility, not Google's, and it's oddly convenient from a monetary perspective (both for Google itself and their partners) for Google to suddenly care a lot more about this than they used to, so it does not seem particularly altruistic in any way.

I agree with your point for, say, Linux.

For the plebs, no, they do not have the capacity. Out there is 7 billion meatbags who have had of a million years of selection for a tribal savannah environment, ten thousand years of selection for an agrarian lifestyle, two hundred years of selection for life in cities, and ten years of selection in the information era.

They're fucking children. They are savannah monkeys. They fall victim to rudimentary scams. They are unable to make an informed choice.

When you get into the billions of users, you become a parent to those users. Parents don't let toddlers get into the knife drawer.

Google's not my dad. It's not their responsibility (or their place) to audit every piece of software I use to interact with their services. I'm tired of being treated like a child who needs every sharp corner ground down for my safety.

Edit: Next logical step is auditing every IMAP client before you can connect it to Gmail. Ridiculous.

You say that, but I've been in plenty of situations where people say they're comfortable taking on the risk themselves, but then when shit blows up, they come and blame the biggest actor (with the biggest pockets) they can. I mean, just check out some sob stories that made the front pages of NYT and Washington Post when people got scammed out of a lot of crypto money - I've read a bunch of those and always the first thing I think is "lord, there is no way these people should have had a dime in crypto in the first place", but then when they lose their money they're the first to blame everyone else but themselves.

> Edit: Next logical step is auditing every IMAP client before you can connect it to Gmail. Ridiculous.

Actually .... They're not that far away from that, if they're not already implementing it. Office365, and Google, if they haven't already have disabled basic Auth for IMAP/SMTP, and only supporting oauth2. Which requires a AppId/ClientSecret handed out out by registering your app with Microsoft/Google.

It seems that you can still steal thunderbirds appid/clientsecret from their open source code, for now ( https://simondobson.org/2024/02/03/getting-email/ ) , but ......

They're the ones who will take the blame when a third-party app gets compromised and is used to siphon off people's data.

This isn't a theoretical concern. It's pretty much exactly what happened with Cambridge Analytica. Facebook didn't really do anything wrong; they provided an API for data access, people explicitly authorized an app with broad access their data, and it turned out that the app was basically a trojan horse for data collection. And politicians, the media, the general public, and even the technologically savvier people who should know better all blamed Facebook for this.

You're leaving out a very important part of the Cambridge Analytica story, which is "transitive permissions". "Normal" people think of transitive permissions very different from computer science folks.

That is, the vast majority of people whose data was sucked up by Cambridge Analytica did not explicitly authorize the app. Instead, their friends did, and at the time authorizing a third party app meant the app got to see everything you did, including all of the data about your friends. Now, you may argue that if you share your data with your friends that you're then at the mercy of whoever they give this data to, but I guarantee very few people at the time understood this - saying "I authorize Bob to see my FB data" is different, in most people's minds, to saying "I authorize Bob to see my data, and also any random app that can convince Bob into giving them access." Facebook was rightly pilloried for this permissions model.

Right, thanks for the demonstration about people on HN blaming the API rather than the user or the abuser too. Do you now see why the only realistic option is for platforms to not provide such dangerous unscoped APIs, or in cases where they do provide such an API, have rigorous security and purpose audits?

I think it's relevant that Transmit is a local native app. There's no hosted app exposed to the internet to hack here. Google made one lengthy process that doesn't fit this use case.

If they are connecting to Google Drive, is that not connected to the internet?

There’s no way for someone on the internet to reach into your Transmit app and make it do something.

How can you be so sure? Even after reading all the source code, there still can be bugs, attacks, demanding letters from different agencies, misconfigurations, vulnerabilities in code and in libraries, etc. etc. etc.

If your threat model is the NSA leaning on a developer to ship a compromised build, KPMG is not going to catch that. If it’s that you’re going to use Transmit to connect to a server which is compromised and exploits your client to exfiltrate your Drive files, guess what else they’re not going to prevent?

It’d be one thing if Project Zero was running serious audits but this policy is designed to let them check audit checkboxes so when you lose data, it’s hard to sue Google.

All of which would also impact the Google Drive client installed on the same machine. None of Google's requirements seek to address this.

exposed to the internet and connected to the internet are different. Exposed implies that traffic originating from the internet reaches the app. You still do have to worry about things like parsing malicious files, but the class of relevant attacks is much smaller and generally easier to defend against.

Everything's connected to the internet, what the OP was talking about was attack vectors and since Transmit is a local app it really isn't one unless your whole machine is compromised, which in that case you're screwed.

There are lots of ways a local app can be compromised. It can read a local config value unsafely which can be influenced by some other app that does talk to the Internet, for example.

There's a reason why airgapping is the only way to secure important systems (and of course that can also have a number of vulnerabilities).

And besides, how do you know it's a local only app if you haven't audited it?

"Just trust me bro" -- some dev

DNS.

If it makes outbound connections and you control DNS, you own it.

I imagine you could do this sitting in a café with an open hotspot.

Panic runs a cloud-hosted sync service that syncs your credentials and connection info between different instances of Transmit you may have.

No idea if that's what google is targeting here, but that is a cloud service, that presumably gets a copy of people's Google Drive OAuth keys if they use Google Drive with Transmit and the sync service.

That isn't a factor in Google's decision making. An app is an app as far as they're concerned, whether it's a local client or some sort of hosted service.

The problem is that if you want to provide a full-featured file picker, and not rely on Google's limited browser-based version, your app will require the full "drive" scope. (We do, and we do, for our InDesign-to-Google Docs connector plugin.)

If you use some of the lower-tier CASA labs, it's not that expensive (4K/year), but it is definitely a nuisance for a pure desktop plugin like ours that has absolutely no cloud component (other than connecting to GDocs).

This assumes that Google can be trusted with my data and other apps can't, and that I'm ok with Google assessing the safety of other apps. It's something that is automatic, and right now it needs to be explained.

Yes, assessing the trustability of apps is important. No, I don't trust Google to do it properly. Maybe I didn't choose Google because I find them the best, but because I have to (because Google, surprise surprise, forces itself down the throat of everyone, so the people I want to collaborate with use it).

Did my apps certify Google as a trustable provider ?

If you don't trust Google, why are you using Drive in the first place?

Quoting the message you replied to:

> the people I want to collaborate with use it

If I were an independent individual who didn't need any others, then it might be a decision I can make. That's the neo-liberal lie you are driven to believe. But we're always part of a society and can't exist without society. Some of the information I want to read has been elaborated and written for years in Google Drive. Some of the people who want to share stuff with me will only use Google Drive. Of course I do all my best to migrate them away, but it only works that much.

That makes no sense - if you don't trust Google Drive, don't use it.

Google is not "forcing itself down the throat" with Google Drive, and even my Android phone comes with 3 cloud providers.

And yes, your apps certified Google as a trustable provider when they added support for it. Such support is not automatic, it requires non-trivial effort, and presumable no one would do it for services they do not trust.

> And yes, your apps certified Google as a trustable provider when they added support for it. Such support is not automatic, it requires non-trivial effort

Are you talking about the technical support (ie implementing APIs) or the bureaucratic support (ie going through Google's process) ? Because the first one is a result of Google going its own way with its own protocol, and the second is entirely a decision of Google.

> and presumable no one would do it for services they do not trust.

No, they would not do it for a service that is vital for the sustainability of their app. When Google is so hegemonic it's sometimes impossible to avoid, app developers must consider whether Google's ways are worth implementing not just based on Google but on the users' willing to make do with an app that doesn't work with Google. Not being compatible with Google is more often than not seen as a problem with the app, not with Google.

> which I've done and are quite easy - if anything

Did you read the part where it took multiple months to continue because of slow replies and non-working tooling from Google's side?

It's also pretty expensive for a relatively niche app, it might be fine if you are Dropbox or a big VC funded Mail app but for smaller companies it's not "easy".

> I don't think it's a bad thing that Google is enforcing some minimal security standards.

How would Google find out if the version that they are "scanning" is the same one that gets uploaded to the app store on every small app update? Zero, so there's no security benefit.

We've done it too, first time it was hard but it's required and recommended.

It raises the bar for low effort hackers and improves security.

I disagree with the op. Sorry mate go through the casa audit and get the access .

How much was the external audit they are now requiring? As it's most likely not based on company revenue, it's obvious that it's less of an issue for bigger companies who can afford to pay an auditor for their stamp of approval and task a person with talking to Google over a few months every year.

If you read the article, they went through the casa audit, found that it did not improve the security of their app, and came to the conclusion it wasn't worth the time and now money to do it a second time.

> and came to the conclusion it wasn't worth the time and now money to do it a second time.

Especially because they'd now have to go through an other third-party to perform the audit process (not just the security lab, the entire thing), according to the total commander folks[1] that's 75k/year/program.

[1] https://www.ghisler.com/googledrivehelp.htm

They say it's "up to 75,000" per program, looking at the actual assessor websites, most require quotes, but tier 2 assessments start at $500 and tier 3 start at $5-6000, and you're in the land of asking for quotes from companies, so "hey we compile the same code into 32 and 64 bit versions" probably does not actually require a 2x cost increase.

> It raises the bar for low effort hackers and improves security.

There are meaningful ways you can improve the security of your app. There are ways to make sure your app passes CASA. I found very little if any overlap between those two when going through the process.