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?
Data protection implications when syncing
+33Wow! That’s very interesting. I have never thought about this before, but this seems like both a limitation and a potential security concern.
Hey @flle and welcome to the community!
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.
Bill_French wrote:
Hey @flle and welcome to the community!
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.
@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.
1 person likes this
flle wrote:
@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.
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.
+33Bill_French wrote:
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.
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:
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.
Bill_French wrote:
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.
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.
flle wrote:
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.
Yes.
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.
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.
Bill_French wrote:
Yes.
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.
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.
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.
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.
+33flle wrote:
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.
I think that if you’re looking for an advanced database platform with very robust, enterprise-level, HIPAA-compliant database security, you may want to look at Apple’s FileMaker.
In addition to being an Airtable consultant, I’m also a Certified FileMaker Developer. So, if you need to find a consultant/developer in either of these platforms, please feel free to reach out to me through my website at scottworld.com.
+20I’m exploring Sync between two bases in the same workspace now, both of them private and for my own personal use - and I too am disappointed that I have to create a public-exposed link and then password protect it just to share data between two otherwise private bases.
Although the surrounding security conversation in this thread is interesting, to me it’s a bit of a distraction from Airtable supporting a more direct/secure method that allows same-workspace base sync’ing without exposing a public facing link.
Definitely worth raising as a feature request.
Reply
Most helpful members this week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.