Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

The issue means you cannot broadcast the link to people (for instance, plant it on some project dashboard, or paste it into a Slack channel), and then select who gets access. You cannot revoke 100% of the access from someone to whom you've given the link.

The reason you've been given sounds like something frowned upon in HN: a shallow dismissal.

Even if we accept their reasoning, there is still something wrong: users don't know about the behavior. There is no "warning: sharing a link to someone gives them a high resolution preview of a page of the document, which doesn't require permissions". It's not what you would assume in a document sharing system that has permissions.

If I am understanding what is happening is that the sender has access to the document and via the Google Drive plugin for Slack they are effectively attaching a preview image when the share the link.

So the stance that Google is taking is probably taking is that this is equivalent to the user sharing the link also sharing a screenshot as a preview. (Something that they have permission to do)

I do agree that this may be a bit surprising but the sender has "opted-in" to this behaviour when they signed into the Google Drive plugin for Slack. But I don't find Google's perspective completely unreasonable.

What team did you report this issue to? I think this is more about the Slack Google Drive plugin's behavior than Google Docs per se. If someone with permission to view the doc takes a screenshot of the first page of the doc and sends that to you, there's nothing really that Google Docs can do to stop that. That's analagous to what's happening here. The Google Docs Slack integration is what's sharing the preview image.

I agree that it's poor behavior and potentially could be part of a critical security compromise. But you'd need to get a hold of the right team. The Google Docs core engineers probably don't care and couldn't fix it anyway.

I don't know for sure (and can't check now since I no longer work there), but my impression at a former job that made heavy use of Slack and Google Docs was that in a corporate setting with Google Enterprise or whatever it's called, the Slack integration was far more cautious about showing previews. It even alerted you if you posted a document that not everyone in the channel could view, and gave you the ability to grant them access right then and there. IIRC, previews were hidden if you didn't have access. I don't know if that is a different plugin or just better behavior in a corporate setting.

Ah, this is a helpful insight. I didn't realise that this is how the integration works. It seems that, at most, Google could force Slack to update their integration's behaviour (and take down the integration till that happens). But as you mentioned, they can't really fix it themselves.

I probably wouldn't have posted this if I had received this explanation from Google. :)

This was their response: "Hi! We've decided that the issue you reported is not severe enough for us to track it as a security bug: when someone with access to a doc sends a link over slack, they express their intent to share this document, hence the preview shared independently from the sharing setup on the doc does not represent a significant risk."

I'm not sure why the plugin has (or needs to have) access to the private doc in the first place. I would expect a communications channel to communicate my link, not act as a third person with priviledged credentials.

Slack has the permissions because you have enabled Google drive integration, and authenticated your Google account to give that integration permissions to act as you. If you don't enable Google drive integration, you don't get a preview. If you do enable the Google drive integration, slack uses your permissions to generate a screenshot, and send that to the other users. It is you and your effective permissions that are sending a screenshot, bypassing other security.

It is not intuitive if you are not used to how security really works, which is that permissions are granted to masks that you wear, not to any real person. When you give slack permissions to use the drive integration, you are giving them a copy of your mask, and they are you, even unexpectedly. You have a (subconscious) reflex to automatically create and share screenshots of documents that you link, that you have trained via slack's hook. Remove that integration, and everything works as expected.

If I follow correctly yes this is an obvious vulnerability. Someone at Google made the wrong decision to not fix this years ago and keeps doubling down on that decision.

If someone does a blog post like “Looking at the first page of 1 billion private Google Docs” they’ll fix it.

basically they are unwilling to admit a mistake and fix a small issue. I have seen a few PMs become super defensive and double down on a decision.

This issue have been reported multiple times over the years:

- https://news.ycombinator.com/item?id=37854159 (October 2023)

- https://news.ycombinator.com/item?id=32770709 (September 2022)

- https://twitter.com/matbennett/status/1171015871868874757 (September 2019)

So you are at least not the first one to get dismissed.

EDIT: Jogging the memory in the other threads, this happens when the person posting the link have (a) enabled the Drive integration and (b) have permission to view the document.

Wow, 3 separate mentions on HN is pretty high (and those were the ones you were able to find). This must have been reported dozens of times to Google.

That said, if (a) this is only occurring with the 2 conditions you mentioned and (b) if Google Drive integrations are only allowed with vetted partners, then I suppose this is less exploitable. Someone would have to intentionally put the link into a 3rd party application that had some people who shouldn't have access.

Though it still be a problem I think, privacy is important even internally. Sometimes access needs to be revoked, or people are unaware of all the people who have access to a channel etc.

I reported to Google that I could harvest firebase JWTs and keep them alive forever in a cloud function by refreshing the access tokens from a cloud function hosted on their own platform. The key issue in my eyes was there was no way to revoke the exfiltrated JWT.

They closed the ticket as: 1) You had to compromise the frontend 2) We bought firebase within 120 days, so we won't bug bounty it.

Completely ignoring that the authentication could not be rolled. That was the last time I tried to disclose or improve a google product. I gave some talks about detecting the use of the same JWT across IP ranges, and using that as a litmus to revoke all user access until your application could contact the user.

Anyway, that was all to say my personal experience is that Google does not care about solving security issues and will actively suppress them until they reach some level of critical mass.

Surely it is not just anyone that a link is shared with, but anyone with the link?

It's link-bearer open access to a partial document (an entire page) an author marks as not having partial access. Circumvention of Google's authentication procedure.

Is that understanding correct?

If so, Google's seemingly OK with users believing something's secure, that isn't. And that could cause information leakage by Google's design that could lead to fraud and/or other crime.

Isn't this just restating in an obscure and poorly worded fashion what the very clearly worded original post said?

Indeed.

> Is that understanding correct?

I must have phrased these 4 words poorly. I'll try harder next time.

Somebody could try to snipe those google doc links and scrape the preview results. I bet that people could find passwords and valuable information from it.

This looks like a security vulnerability to me. I pay for Google Drive, and I'm starting to distrust Google to maintain the safety of my data properly.

This sounds familiar. I'm pretty sure this problem was brought up on HN years ago, and basically Google said the same thing at the time.

And yeah, I think it's ridiculous.

The physical analogy is a cover page, intended to conceal the subsequent contents when stacked on a table.

A tooltip change (warning) to the sharing view would be sufficient to address the concerns that the first page is displayed as part of the preview for those with Google Drive integrations enabled.

You should change your tl;dr to reflect that one can view a preview of the first page of a shared Google Doc, despite not having access, when provided the sharing link and with Google Drive integrations enabled.

> A tooltip change (warning) to the sharing view would be sufficient to address the concerns that the first page is displaye

No one reasonably expects something to be viewable in any form if you haven't given permissions for it. Having to tell the user about such a thing via a tooltip is just bad UX design.

I also wonder if Google didn't create a footgun for themselves if some genius at Google in the future decides the preview looked better if they showed 2 pages instead of one in some UI's.

The product manager was not involved in the decision to mark it "won't fix". Or more likely, even if the PM did see your bug report, the PM doesn't understand the issue.

Stretch: it is the kind of thing that exposes a bug the PM/dev-team didn't catch themselves. So maybe they are trying to sweep it under the rug haha.

Ask HN:

Sorry about that, I rarely post questions on HN. Forgot to add the "Ask HN: " I don't suppose I can edit it now.

On a user level I agree, on a technical level I disagree.

Reason for disagreement is that the preview is generated once with the access rights for the user posting that link (with the permission Slacks Google Docs integration got from the posting user). For performance reason it would be quite costly to generate a preview for every viewing user since access rights could be different for every user. Also access rights can change every time, so it would be necessary to recheck permissions regularly to decide if the preview should be renewed (removed/added/changed). This also would mean users need to wait longer for the preview to generate.

So every user posting a link on Slack (or any platform which generates previews with a special integration) should be aware of that fact

Every time someone says "for performance reasons" as a justification for wontfixing a security issue a million badguys rub their hands with glee.

If you can't do previews in a way that respects access permissions you shouldn't do them at all. This isn't a feature that is essential whereas security really is.

Moreover you really can't possibly have a security scheme that relies on every user being aware of something. Someone will either not know or will know but forget or make a mistake. Systems should be robust enough to accomodate usage by actual humans.