There is some massive confusion around the types and costs of audits required for full Drive permissions scope (and I definitely blame Google for the lack of communication/direction on this). I had to get this audit for an app and it was nowhere near 75k - I believe it was well under 10k. Another commenter said they had it done for $4k: https://news.ycombinator.com/item?id=41781325
That still sucks and is prohibitive for indie developers. As the post mentions, in reality this program adds very little value for any of the involved parties.
> But it also intimidates folks into not sharing some really good stuff.
Do people really care what some other Internet rando thinks about their book preferences? FWIW (though of course could be missing some), I haven't seen any recommendations that have been dumped on. Heck, your comment recommending "junky fantasy books" is currently #2 for me, in a very long thread.
I know everyone loves to dunk on Google, and I definitely agree their communication and customer service to app developers is shite, but this change to permissions scope is a good thing. If you have full, unfettered access to large number of people's Google Drive data, you're a huge target for malevolent actors. If you can't afford the new audit requirements (which I've done and are quite easy - if anything I'm sympathetic to the argument that they're more "box ticking" than valuable security audits), then I'd really question your ability to appropriately safeguard so much critically private data. For reference, these audits are about 1/20th as complicated as a full SOC 2 audit, for example.
FWIW I'm not previously familiar with this Transmit app, but based on their use cases (e.g. backup) it sounds like the limited "drive.file" scope wouldn't work for them. Still, if you want complete, unfettered access to my entire Drive account, I don't think it's a bad thing that Google is enforcing some minimal security standards.
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.
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.
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.
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.
> 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.
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.
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.
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.
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 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.
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.
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.
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?
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.
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.
> 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.
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.
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 ?
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.
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.
> 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.
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.
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.
I recommend the book "How to break up with your phone". I liked it because I thought it gave good practical advice on reducing the most detrimental effects of a smartphone. One of the reviews on the back flap is something like "<This Author> is the Marie Kondo for the mind", and I thought that was a great description.
> I'm of the opposite mind, I think forcing kids to struggle through books they don't care for creates generations of adults who think they hate reading.
I think it really depends on how it is taught. Also in my 40s, I recently read The Sun Also Rises while on vacation - I just had the feeling I wanted to read a "classic" book, and somehow I didn't have to read that book in high school. I hated the book. I kept waiting for a smidge of effort in wanting to make me care at all about any of the characters, and I just never found it. It was like being forced to go through someone's vacation photos for 10 hours straight, where most of the photos were of alcoholics drinking.
But still, I'm glad I read it. I wanted to understand why Hemingway is considered a literary giant, and his writing style (especially his dialogue) was new and innovative at the time, and influenced lots of other writers. If teachers could help explain books in context (e.g. why is Moby Dick considered a classics novel to begin with) I think a lot of students would better appreciate what they're learning.
Hemingway is hard because people demand explicit. The story behind the obvious is what makes The Sun Also Rises so powerful. It defined the lost generation. It was the 1920s version of Clerks.
I’m sure people read Hills Like White Elephants expecting to find an elephant in the story. Of course there is — a big one right there in the room.
You should be a teacher :) I love that quote, and it's exactly what I'm talking about. Without the context of what the lost generation is/was, and without understanding how the generational trauma of WWI had such a strong influence on the interwar period, you lose a ton of understanding about how the book was so influential.
> Passing references to Moby Dick, Crime and Punishment, and even my unit about The Odyssey, confine literary merit to a very small, very old, very white, and very male box.
Ahh yes, you shouldn't have to read Dostoevsky because he was just an old white guy. FWIW when I was a kid I had to read the Odyssey and books like Beloved and I Know Why The Caged Bird Sings in high school, so I think this article author is being a little selective with her examples.
The quote is about literature being "confined" to it. Meaning the overall impression from the reading list you get is that literature is something of the past and concerns only certain race and gender.
The comment refers to what Horowitch’s article counts as literature, not what your teacher/school system counted as a literature.
It's ironic that in a comment section on an article bemoaning the death of reading comprehension, so many comments skim and miss points the author was making.
Well, it is a collection of individuals with the primary unifying skill set of being able to rapidly skim documentation (and produce correct results... most of the time).
While I have definitely seen many instances of reporters coming with a preconceived narrative, and then just wanting quotes that further that narrative, I could barely get through reading this article. The author seems to want to dump on competing narratives for why kids seem to have trouble with long form reading, but then brings all her own biases and essentially lays them out as fact with 0 evidence. Take early on in the article:
> She, in turn, ascribes these instructional choices to the oppressive presence of standardized testing and the Common Core. And cell phones, always cell phones.
The evidence that cell phones are hugely detrimental to the development of young people is pretty overwhelming these days, and no amount of old, out-of-context quotes taken from earlier "technological panics" will change that. I think the works and research of Jonathan Haidt do an excellent job digging into the effects of cell phones on kids.
And don't even get me started on the "Kids don't want to read the old classics because they're dense and hard to read, they're just challenging the white male patriarchy!" Spare me...
Please don't cross into snark or personal attack. The GP could have been more polite but your response is a noticeable step flameward. We're trying to go the opposite direction here.
No, it seems like the comment you are responding to is specifically arguing that a "bench" may be needed (with workers getting paid) so that they are available during spikes in shipping volume.
You seem to confuse what life insurance is for - it's not for the person being insured, it's for their dependents (at least with respect to term life). And it already happens all the time that life insurance gets too expensive, so people forego it. It's one reason that financial planners recommend getting life insurance when you're young, when you're healthier and it's cheaper. Also, as you age it becomes less likely that you'll have dependents that need you to have life insurance.
As others have pointed out, the debate over health insurance shouldn't confuse the debate over other types of insurance. Many societies have accepted the viewpoint that everyone should have health insurance as a fundamental right, even if they have a horrible risk profile and it's uneconomic. I don't think anyone can make that argument about someone's "right" to drive a car that is inherently dangerous to other road users and horribly expensive to repair.
reply