This has been true since the integration was released and main reason it's been disabled at most companies I've worked at.
Definitely nothing new and reported to Slack and Google multiple times, always replied with working as expected. If you don't like how it works, remove it.
Recently the UI and options changed a bit and you can now disable previews but I believe is a user setting and not a organization setting.
A preview of the first page is absolutely enough to put companies on the wrong side of government and/or industry regulations/compliance.
It may not be as astronomically bad as you immediately imagined, but I don't see how the nuance makes any material difference with the urgency in which this would need to be contained/analyzed/investigated and reported timely where required.
Could be, except it's unlikely to be put on the first page, so at the very least, this integration is leaking the title, classification and authorship - and through that, existence - of a potentially sensitive document.
This is the point of the Slack app though. It does notify you if x recipients can't see a document, but it doesn't attempt to hide it from those who don't already have access.
Companies can turn off the Google Drive app in their Slack workspace and block it in Google Workspace admin (and generally allowlist which apps can request Drive permissions: https://support.google.com/a/answer/7281227?hl=en ).
The reason it’s implemented this way is that slack doesn’t have the ability to generate a per user thumbnail based on the access rights of the document.
As the sender of the slack link, Slack should give the option to include the preview or not, like it does for other unfurl’s.
Where there would be a major problem is if someone could trick slack to generate a preview of a link they don’t have access to.
Secondarily, I have seen slack show an obsolete preview, which could result in something accidentally shared.
- The app just requests may more permissions than required. Often times you'll see an app that just requires read access that is requested read, write, personal email, and blood of your first born.
I worked on a service that integrated with a lot of services that store data that one would deep business sensitive. When I'd always minimize permissions while setting up development, I had PMs/decision makers require that we ask for maximum permissions so future changes are easier. Felt wrong to me.
- The service (OAuth2 provider) not have fine-grained enough permissions. Sometimes there would only be the option for "read" or "write". Sometimes you'd get access to "read documents", but you couldn't restrict the type of documents. The more options there are, the more confusing it can be, but the more control and security the user has and I think that's much more important than development confusion.
I will say that I really appreciated what Notion does where they'll give you the ability to approve access to individual pages and while querying for pages you'll only ever see ones you've been granted access. The other side is that now a user has to approve each next page. The is also the option to allow everything existing and going forward. I think that's a great middle ground that gives control to the user. Whether the average user takes advantage of that is another question all together.
Soon enough every thumbnail will just be [THIS PAGE HAS BEEN LEFT INTENTIONALLY BLANK] once legal realizes and has IT push new corporate templates onto everyone.
And the worst part is that before web that just worked - file managed did the thumbnails (or custom open dialog) and nothing needed to be sent to cloud...
The key feature of the integration isn't the thumbnail, but that Slack indexes your Google Drive files so they show up in search. That is absolutely worth it IMO.
Would the terms established by Google, agreed to by a developer creating an integration like this, include a need to respect permissions unless the user explicitly requests (or is explicitly informed of) additional access for parties beyond those already granted access by Google's system directly? If so, it seems like this could be reported to Google who would pull it down and force Slack to comply, if Slack doesn't want to on their own.
I suppose the installation of the integration already involves a Google-served message along the lines of "Slack will be able to see everything as you do" but that's not quite explicit enough for a user to then extrapolate "...and may share it however they like without telling you." Like of course they could, but they shouldn't, unless it's super clear, and it's not.
> Limit your use of data to providing or improving user-facing features that are prominent in the requesting application's user interface;
> Don't allow humans to read the data, unless: You first obtained the user's affirmative agreement to view specific messages, files, or other data, with the limited exception of use cases approved by Google under additional terms applicable to the Nest Device Access program...
Did Slack make it clear to the user sharing their Drive link that the preview isn't just visible to them, but to anyone in the channel or who has access to the link? Was that clear enough to be affirmative agreement? Is the little area where the preview is shown while you're composing a Slack message prominent enough to display that it will include a screenshot of the data?
Clearly, Slack thinks the answer to all these questions is yes, and Google either agrees or isn't enforcing their guidelines here.
(...As an unrelated point, the fact that the Nest Device Access guidelines are an explicit exception to even this modicum of user visibility, that the guidelines aren't linked, and can be unilaterally changed by Google without notification to users is... well, why I don't own Nest devices.)
It seems odd because I did share Google Doc private docs very often in Slack in the past, and Slack would tell me that this was not a public document so it could not show a preview. So I wonder if something changed.
Typically if you think you found a security vulnerability and/or quirk, you contact the company before writing it up and hitting publish[1]. That way the company is not left in a potentially vulnerable state.
I disclosed this personally 4 years ago via hacker one. The larger issue, imo, is that it indexes the content and allows an attacker to craft search terms which reveal the full contents of the document sort of like a blind SQLi. I was told it was working as intended and my report was black-holed on h1 and was told via email that it was "informational" and not a vulnerability.
It's lame to come on here and act like people reporting this are acting in bad faith. I asked for permission to talk about it and was granted it, so I don't see why the author of this post shouldn't be able to do the same considering he doesn't even get into the search indexing aspect. The company is in a vulnerable state due to negligence in addressing the issue, not because it was publicly disclosed.
Even more than that, the page is cached as it was at the time it was shared. I've seen this happen with documents that were later edited, with hilarious results.
Isn't that the case with "unfurling" anything, though? Whether Slack generates a thumbnail or just pulls text from meta tags? Same with other apps like Teams, FB Messenger, etc? None of this is known to poll for changes frequently enough to avoid the hilarity of caching.
If you use the drive integration, you share it with Slack. Slack then creates a thumbnail that is visible in that channel. Imagine pasting a sensitive HR document in the big company chat with everyone in it. No one in the group may have permission via Google, but they can see the thumbnail (and search its contents!) if they have access to the slack room.
Edit: I should note, this is my fuzzy recollection of how it worked 4 years ago when I reported it to Slack. YMMV
It's often used as an argument to prop up service models though: use our service because it's more secure than not. In theory it makes sense. In practice, security through obscurity I think doesn't get enough justice.
I understand importance of respecting access control but if you're sharing a Google Drive on a private or public slack workspace, you probably are doing it wrong to begin with because anyone who has access to the channel is ideally someone you trust with the content ur sharing
