Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

End of the road for Google Drive in Transmit

blog.panic.com

Post reply on HN
Print view View original

161–170 of 196 posts

Re: End of the road for Google Drive in Transmit

#161

Post by mikewarot »

This is the end result of having compute as a utility, without having equivalent protection mechanisms in place all the way down to the endpoints.

Imagine what would happen if we didn't have fuses and circuit breakers everywhere we use electricity. Any defective toaster could bring down the entire grid it was plugged into. There would have to be entirely new teams of inspectors and certifications and laws about even plugging in a lamp.

Madness

Yet here we are, 40+ years after collectively deciding that MULTICS was too complicated, and Unix was the way to go.

I thought we'd be able to see the folly of our ways by 2025 at the latest, but it's not going to happen. 8(

Re: End of the road for Google Drive in Transmit

#162

Post by SanjayMehta »

FTA this jumped out at me:

“Eventually, by reaching out through friends of friends of friends to find someone inside Google who could help, we got in contact with a Google employee who was very helpful in getting the process started.”

Sounds exactly like dealing with an incompetent government agency.

Re: End of the road for Google Drive in Transmit

#163

Post by jrnichols »

xp84 wrote: post #114
whalesalad wrote: post #92

I don't use Google Drive and probably never will but FWIW Transmit is still one of the best all-around data transfer apps that exist. I always miss it when I am on my Linux workstation. Being able to quickly connect to an S3 bucket and dump files and edit their permissions is a huge plus. Not to mention basic SFTP access like Cyberduck or Filezilla would do. I have never regretted my purchase of Transmit, it's great!

Same. I used to pirate it back when Serial Box was a thing and I was a broke college kid, and I've been licensed since growing up. An essential tool. I would say it should be built into the OS, but that's a joke since modern-day Microsoft and Apple could never provide such a useful tool without sanding everything down to a smooth minimalist surface with no discoverability.

I agree.

Also believe that Unison was the perfect NNTP client and I miss it still.

Re: End of the road for Google Drive in Transmit

#164

Post by alanfranz »

I’m not sure about how this is happening. Transmit is a desktop app - or does it have a cloud hosted component?

If it’s a desktop app, it should be possible to generate an api key and pass it to the desktop app, that’s it. Google doesn’t know or care about who’s using it at that point.

The security flow being discussed should impact cloud-hosted applications.

What am I missing?

Re: End of the road for Google Drive in Transmit

#165

Post by wink »

hn_throwaway_99 wrote: post #100
tlogan wrote: post #93

Earlier quoted context omitted.

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 commun…

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.

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.

Re: End of the road for Google Drive in Transmit

#166

Post by dewey »

imhoguy wrote: post #51

As per mentioned Ghisler page: "The security assessment would have to be performed by a specialized company, and costs up to $75'000 per year and program (so $150'000 for 32bit+64-bit). This is not sustainable even with a subscription." [0] This is death kiss to indie developement. But paradoxically it is great. Killing interoperability is nail to coffin. This brings more and more focus to alternative solutions out o…

> The more hassle the more people are going to hate that ivory tower.

This is a bit naive, a very small percentage of people would be interested in these alternative solutions. Most people don't even install any third party software on their computer and just use the browser for everything.

Re: End of the road for Google Drive in Transmit

#167

Post by andreyvit »

joshuamorton wrote: post #99
acdha wrote: post #55

Earlier quoted context omitted.

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…

> 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 folde…

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.

Re: End of the road for Google Drive in Transmit

#168

Post by wslh »

ELI5: I’m not familiar with the Google Drive API, but does this mean that even if I try to build my own tool as an individual, I have to go through all these steps? I'm asking because, with many API services, you have to declare an app during setup, even if it’s just for personal use.

Re: End of the road for Google Drive in Transmit

#169

Post by acdha »

deely3 wrote: post #137
acdha wrote: post #38

Earlier quoted context omitted.

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.

Re: End of the road for Google Drive in Transmit

#170

Post by acdha »

andreyvit wrote: post #167
joshuamorton wrote: post #99

Earlier quoted context omitted.

> 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 folde…

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.

Post reply on HN