Make unlisted docs... unlisted!

Suggestion Box
1

I was surprised to find recently that other users could see all the docs that I had previously shared as public, i.e. “anyone with the link”.

While of course a doc with those permissions shouldn’t be considered strictly confidential, I had been relying on a certain amount of security through obscurity, and didn’t expect it to surface in search results / doc lists (whether inside or outside my Coda org).

This is the behaviour I’ve come to expect from other services (YouTube, Dropbox, etc…), where “unlisted” / “anyone with the link” means that knowing the link is the only way to discover the content.

I believe the following is a common use case (and i suspect is what Coda users usually intend when they set perms to “anyone with the link”):

“I don’t want people to be able to discover this doc unless I send them the link, but I don’t want to make them log in to view it.”

Edit: while we wait for a fix, here’s a Pack that lets you set proper unlisted permissions:

6 Likes
2

Strongly agree - this is a high-priority security issue

5 Likes
3

Strongly strongly agree.

3 Likes
4

Adding my vote here too

1 Like
5

I think this must be a bug, which I assume happened something like this

  • Let’s let people share the link publicly, so everyone can view
  • Cool. Because of the mathematical intersection of sets, that means that everyone in the workspace can view. So we’ll just auto-set that switch for people too and not let them unset it
  • What docs should we show people in their doc lists? I guess any docs in the workspace that are set to “anyone in this workspace can view”

I conducted a quick poll of experienced Coda makers and 5/5 expected these links to remain secret. I don’t expect the numbers are any different among novice users.

I consider this a security issue. I know that pedantically, publicly shared docs should not be considered secure. I also know that many Coda users are currently exposing confidential data and don’t know it.

3 Likes
6

Spoke with the security team, here’s the current situation:

  • Docs which are shared as “anyone in the domain” appear in your colleagues’ doc lists and when they search. I agree with this UX choice.
  • Docs which are shared only as “anyone with the link”, but not “anyone in the domain” behave as regular unlisted links (i.e. they do not appear in doc lists or searches). Yay! However, there is no way to select this sharing configuration in the UI. As soon as you flip the “link” switch, it forces the “domain” switch on too.

Workaround:
I made a Pack to let you do what you can’t do with the UI

Expand to view original pre-Pack workaround...

Workaround:
You can set this sharing configuration (link-but-not-domain, what I’d call “Unlisted”) via the API. This is the only workaround currently. Here’s how to do it:

  1. Create a new doc, which you’ll use to manage your doc permissions
  2. Install the Coda Doc List Pack
  3. Bring in a Docs table from that Pack to view all your docs
  4. Add an “Unlist” button column with this formula, that you can click for any docs that you want to keep unlisted:
[Coda Doc List]::ShareDoc(
  <your connected Coda Doc List account>,
  thisRow.Url,
  "readonly",
  "anyone"
)
  1. For each doc you want to make Unlisted, click its URL to visit the doc, and in its sharing settings, set it to “No Access” for your domain.
  2. Back in your permission management doc table, click your “Unlist” button

(Wouldn’t it be easier to have the button run two actions: set “anyone” to “readonly” and set “domain” to “none”? Yes. But there’s a bug in the Coda Doc List Pack where setting permissions to “none” returns an error, even though it’s offered as an autocomplete suggestion. :disappointed: )

@Scott_Collier-Weir or someone… do you feel like putting together an improvement to the Doc List Pack that includes:

  • a column for what the current permissions for a doc are - this would make it easier to see what docs need attention
  • a fix for the bug where “none” is not an acceptable argument (this is most likely because the permissions endpoint does not accept “none”; I think instead, you need to hit the permission delete endpoint for whatever access you want to deny)
3 Likes
7

Hey @Nick_HE !

I already have a button called “SetLinkAccess” on the doc explorer pack

I also have a DocAccess sync table and a DocPermissions formula.

Let me know specifically what formula and output you want and I’ll add it!

8

Ah perfect, ok. I’ll update my how-to above shortly with the proper steps.

9

Actually @Scott_Collier-Weir how would you recommend tackling this?

My first approach was to add a column to the Doc List sync table, with formula DocPermissions(thisRow.Url.Split("/_d").Last()) - this gave me lists of Coda API Permissions with type “email”, but not “domain” or “anyone”.

I think I need DocPermissions() to return permissions with at least type domain so that I can grab the permission ID to feed it to RemoveAccess()

10

I Can updated the formula so it will return this. But for now I think the DocAccess table provides all access types to a doc with permission ids

11

I’m building a Pack specific to this issue that will let you unlist a doc in one click. Just got one bug to squash and then I’ll update here with a link to it.

It sounds like this is going to continue to be the behaviour in the near term, so I think a single action will be helpful.

1 Like
12

Ok here we go:

A single action MakeUnlisted() for setting any doc to be publicly accessible via link, but NOT listed in your team’s doc lists.

4 Likes
13

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.