A preview picture of the documents first page is shared whether the user has permissions or not.
The entire document is not shared like what the title seems to suggest.
For sensitive documents, this can certainly be a leak but its not outright sharing in a traditional sense.
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.
So that whole, “This page intentionally left blank”, is a security feature?
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 ).
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.
or sensitive company secrets
or relevant details of business deals
or is a payslip
etc etc.
It is a horrible breach, that shouldn't exist and should be fixed ASAP. Also due to GDPR concerns.
Saying that it is non issue is very short sighted.
A- give you access to all my documents so you can make a thumbnail when I attach a document or
B- not do that and not get a thumbnail, so I just look at the document outside of slack before attaching it?
That's never been a complicated decision for me.
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.)
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.
[1] https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability...
Is the concern that the recipient might share the link to the image? Again, they already have access to the shared document if they want to leak it.
I don’t think accidental discovery is possible - there’s a long shard of random data in there. It’s no more discoverable than the share link.
Edit: I should note, this is my fuzzy recollection of how it worked 4 years ago when I reported it to Slack. YMMV
- 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.
I mean, that's just straight-up reasonable. There's no free lunches on this world /s
If I search "Draft performance improvement plan for ceejayoz" and a document I don't have access to comes back, that's a fairly significant data leak.
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.
The search you experience runs against permissions so something like that doesn't happen.
I suppose by this you mean that you do work at Slack, but that's not really a disclaimer, is it? More of a "claimer".