Data protection implications when syncing

[flle]

I want to sync one view into another base. I found this documentation stating how to do that. As far as I understood, that Link that I create can be viewed by anybody in possession of that link. In addition, I can protect it with a password, but then the sync will stop working.
Is that correct? If so, the sync feature is pretty much useless for everyone who doesn’t want views to be accessible publicly (I know, it’s a private link, but I don’t really trust that kind of private link), or am I mistaken? Am I missing something here?

[ScottWorld]

Wow! That’s very interesting. I have never thought about this before, but this seems like both a limitation and a potential security concern.

[Bill_French]

Hey @flle and welcome to the community!

flle:

the sync feature is pretty much useless for everyone who doesn’t want views to be accessible publicly (I know, it’s a private link, but I don’t really trust that kind of private link), or am I mistaken?

It’s a “private” link to a point, and that point is up to and including the moment when at least one other person knows about it. :winking_face: But this is not any different from Google documents that are fully open and accessible - if you know the link. All document attachments in Airtable are exposed in precisely this fashion by default and there’s no other setting.

Is this approach useless? Certainly, not if you share the links. The GUID that represents the link is not easily predicted by anyone or any software, so it’s relatively secure. But, it’s likely not acceptable to a lot of CSOs either.

[flle]

@Bill.French
Thanks for your reply. I know that the link to the view is probably more secure than most of our employees passwords since a computer would actually need to guess quite a lot of times to guess that secret part of the link correctly. However, I still have a bad feeling about this. Why would I expose a view publicly (I know, it’s only possible to access it with that secret - but still, a computer can access it without further authentication) ONLY to share it with another base that I own as well? That just doesn’t feel right to me since the bases actually relate to the same workspace in the same “ecosystem”. If I have a co-admin who’s leaving the company, do I need to regenerate the private links to make 100% sure that he doesn’t have any access to the data anymore? There might be a chance that he kept the link to access the data. Sure i can do that, but it’s adding another tasks to my offboarding activities. Maybe other people don’t have those problems and it’s unique to us.

[Bill_French]

flle:

If I have a co-admin who’s leaving the company, do I need to regenerate the private links to make 100% sure that he doesn’t have any access to the data anymore?

Yes, but this is not an unusual process if using openly accessible data. But, your approach falls flat when you realize this departing individual could have also written a script that exposes the “private” URLs for every document attachment in the system and exported said URLs to her desktop. And if that isn’t reason for pause, consider that any user - admin or not - can make a complete copy of your base without you knowing it.

If these security inexactitudes were a crime, we would all would be on death row.

Using private links to share data for synching purposes is the least of your worries if rigid data security is crucial to your business use case.

[ScottWorld]

It’s sad that Airtable is trying to hide these types of security holes through obscurity and/or censorship.

@Bill.French: Two days ago, Jason from Airtable just unlisted the thread that you referenced above:

MAJOR SECURITY HOLE IN AIRTABLE: Any collaborator (even read-only collaborators) can steal 100% of y... Product Suggestions

I’m typically blocked by the community for using metaphors and I can think of three Dennis-Miller-isms that would be ideal right about now. In any case… who thinks this is a good idea? [image] I believe the creator of a base copied by a read-only user has no idea that a 3rd party has full access to the content. I think this is possible today despite the recent security updates, and I think it’s really problematic.

Unlisting a thread means that the thread is no longer available in the forum search engine and is no longer visible to anyone browsing through the topics. It is only accessible via a direct link to the thread.

[flle]

But, your approach falls flat when you realize this departing individual could have also written a script that exposes the “private” URLs for every document attachment in the system and exported said URLs to her desktop

I am not yet a 100% familia with the terminology. By document attachment you mean something like a pdf, attached to a record?

I am not sure if I am making my point clear. I understand that the system probably works in a secure way since those secrets are hard to guess. Which is fine if I want my data to be accessible to people whom I share the link with. It’s obvious that people can download all the data while they have access to it. However, why is the same approach used when it comes to syncing bases internally? Since it’s internal already, why would you add another point of attack by having those more or less static links that you have to re-generate manually when a person leaves the company.

[Bill_French]

flle:

By document attachment you mean something like a pdf, attached to a record?

Yes.

flle:

It’s obvious that people can download all the data while they have access to it.

Actually, it’s not obvious because it’s not a “download” - it’s a replication of information shared with read-only access that can be used to create an entirely separate instance of the base without awareness by the base’s owner who has granted such read-only access.

flle:

I am not sure if I am making my point clear … why is the same approach used when it comes to syncing bases internally? Since it’s internal already, why would you add another point of attack by having those more or less static links that you have to re-generate manually when a person leaves the company.

It was perfectly clear - Airtable, in its desire to quickly roll out a new feature cut a very big security corner - internal synching leans on a public interface. Dumb. Really dumb.

[flle]

Yes.

Ok, thanks for pointing that out. That’s another thing I wasn’t aware about.

Actually, it’s not obvious because it’s not a “download” - it’s a replication of information shared with read-only access that can be used to create an entirely separate instance of the base without awareness by the base’s owner who has granted such read-only access.

That I men’t is, that it was clear to me that if I give someone access to my data, they can “steal” it. It’s like inviting someone to edit a google doc. You can configure your google doc to be ready only (disable copying etc) but someone might still make a screenshot and upload it to a tool that will extract the text.

It was perfectly clear - Airtable, in its desire to quickly roll out a new feature cut a very big security corner - internal synching leans on a public interface. Dumb. Really dumb.

Ok, that makes it clear. Thanks for the answer - I will have to live with it or look for another solution.

[flle]

So I guess at least for our company Airtable is not a solution we can consider in this case (which is sad, I really like it). It would be great to have a roadmap from Airtable with a plan on how they will address the issues. Not the issue I pointed out (not sure if it’s even an issue for other people). But especially the issues pointed out in the thread @ScottWorld linked.