This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
This thread made me realize that we should probably have an option to PREVENT collaborators (particularly read-only collaborators) from being able to easily duplicate an entire base.
When we share read-only links to bases or views, we have that option that we can uncheck that says: “Allow viewers to copy the data in this base” or “Allow viewers to copy data out of this view”.
But it would be nice if we had that same feature for collaborators.
I consider these as a feature very important to me. If this wasn’t available I would possibly stop using AirTable (or use it way less than I do). The ability to download images by their URL without logging in is necessary if those images are downloaded by a 3rd party service or 3rd party app. I use AirTable as go-to application to manage my entire multichannel eCommerce activities. AirTable provides me the CSV which then is loaded to Amazon, eBay, Mercari, Craigslist, Poshmark, Etsy, Kijiji, Gumtree, and many many other market places. One of great features of AirTable is the ability to easily save and store images (my product images). When I create the CSV out of my base, the CSV contains hot-links to images. With that, I am able to load images to all these marketplaces directly from AirTable servers. If AirTable required a login, it would not allow the 3rd party service and apps to download the images. I don’t have expertise to program my own apps to use AirTable API and the services and apps I use do not support integration with AirTable directly or with Zapier and similar (All Zapier can do is to download a ZIP file of all images stored in the field, that wouldn’t help because it would require manual work around).
I agree downloading images is a security problem, but the problem is not that the images shouldn’t be downloadable by the publicly accessible URL. The issue is that a collaborator or perhaps shared user is able to create export of the CSV file (or any format) showing the public image links.
IMHO preventing the non-owner user from getting hands on the public version of the document/image links would sufficiently protect against misuse. However, if that’s not going to satisfy the safety police, then perhaps there should be a setting where I allow 3rd party access to stored documents and images without need of API or logging in.
Yes, that is a very handy feature — to be able to distribute the URL to people.
(Although note that most — probably all? — 3rd party services are using Airtable’s API without you being aware of it. So you don’t need to have a technical understanding of Airtable’s API in order to benefit from it.)
However, comparing Airtable to a service like Dropbox, Dropbox lets people specify between “public” files and “private” files. Airtable, by default, makes all files “public” — and there’s no option to change that. I would be totally okay if Airtable gave users the option to make their files “public” or “private”. That would be a good solution to this issue.
For example, while having all the files be public might suit your needs, that’s not okay for my clients who are lawyers or other professionals that need their documents to be secure. Several of my clients have actually MOVED AWAY FROM Airtable because of this flaw, and they moved to the highly-secure FileMaker platform instead. So I have personal experience with businesses abandoning Airtable because of this.
When professionals with confidential data sign up for a service like Airtable, they often mistakenly & erroneously THINK that their documents are secure in Airtable, when they’re actually accessible to the entire world — once the URL is revealed to someone.
Are you okay with this flaw as well? This is a huge one. If you delete an attachment from Airtable, it continues to be accessible for AT LEAST A YEAR AFTER IT HAS BEEN DELETED from the URL, and possibly longer than that. There is no circumstances whatsoever where a deleted attachment should still be allowed to be viewed.
No I am totally not OK with that. I forgot to respond to point 8. The headline says both 7&8 but I didn’t touch point 8. Completely agreed, this 8 issue is completely childish flaw that AirTable has. No excuses here.
Added:
Just to add to my comments for Point 7. I wound’t mind to make whole AirTable public, as long as the links (both to database and to documents stored within the fields) are only known to me and anybody with the link to document won’t be able to access to the entire tables.
So simply setting the tables and the documents (links) either private or public would resolve the issue with the document links. It would satisfy both needs.
A few years ago I worked in an IT company. They had an inexpensive file sharing software because the owner was concerned about not putting anything in the cloud. Because of the flaws in the file sharing software, the public links to internal documents still work today and all company database 1000’s of internal clients documents can still be downloaded today after many years. I didn’t tell them about the flaw even after I left the company, because I don’t care, because they owed me and other people money and didn’t treat people well. But if somebody was going to figure that out, it would expose the company to millions of dollars in damages from litigations.
So I can completely understand your situation with your clients. I don’t want to come across as selfish. It’s just that I found AriTable to be a sweet solution to my needs and spent 100’s of ours setting it up and works well. So if AirTable doesn’t provide an option to have publicly accessible links to documents, it would break it for me.
I wouldn’t cross my fingers for how AirTable is going to deal with this issue. They seem to resolve things but they seem to either overcook or undercook the meal… “Either have full access fully exposed to web or no access at all and can’t really download the complete image of the database easily.”That’s the situation today.
Just wanted to interject a reality check on these comments.
Suggesting that uploaded attachments are always “visible” to the general public is wildly inaccurate. Public visibility and conditional accessibility are two very different concepts and you are conflating them in a somewhat sensational way that is not fact-based.
Attachments URLs are like signed URLs with an indefinite termination point. They are not visible to the public – or ANYONE for that matter – unless the links themselves are openly published in a manner that the public is aware of them. Furthermore, they cannot be found through crawling techniques nor are they easily discovered through hacking techniques.
The Facts
Assuming the document ID distribution is uniform and unpredictable (which it appears both requirements are achieved with Airtable attachments), here’s the math:
44 characters long
Uppercase, lowercase, digits and underscore =
26 + 26 + 10 + 1 = 63 character alphabet
Therefore…
The total possible combinations: 6344 – ergo… 263 bits ⇐ 44 * log2(63)
And we know that brute-force deciphering of a 263-bit key in any reasonable amount of time (lifetime of the universe) is well beyond what the laws of physics will allow, no matter how advanced and magical and “quantum” the computers may become.
This may seem to be a cocky assertion, but it comes from the fact that the sun simply doesn’t put out enough energy in such a timeframe to count that high. See page 157 of Schneier’s Applied Cryptography for the details, or look at this answer here where some really bright people have summarized the math, or this answer where links quoted the entire section from Schneier’s book.
This is precisely why (a) Google follows exactly this security pattern for making links openly accessible without experiencing rampant attacks or enduring the wrath of public relations concerning breaches associated with this improbable threat pattern. In fact – and the math and experience over more than 1.5 decades – prove with great certainty there is no “there” there.
Please consider adopting a more nuanced level of verbiage when asserting “public visibility” and “public accessibility”. For the “public” to access any attachments in Airtable they must first be invited into the secure realm of unhackable URL awareness. This is no different than DropBox, AWS, Google, Box, Microsoft, or the thousands of SaaS services that utilize this approach for billions of secure documents.
Overall Security Model
There is plenty to complain about with regard to usability and user experience. Indeed, we all want Airtable to be as secure as possible and as flexible as needed when it comes to sharing and collaboration. That pressure and many of the weaknesses called out in this thread are well deserved. But, we need to indict patterns that are truly posing threats; #8 and #9 do not fall into this class and they shouldn’t even make the top 100.
You’re completely missing my point. Nobody is talking about someone randomly stumbling upon the URL or a hacker figuring out the URL. You keep trying to make it about that point, but that’s not the point I’ve ever tried to make. Not even once.
To clarify my point, so there is absolutely no confusion:
Any collaborator, even a read-only collaborator, has access to ALL of the URL’s in the entire base. Once a collaborator has the URLs, the URLs are known. If they maliciously distribute any of the URLs, there is no way to remove those attachments from circulation.
Even if you delete the attachment from Airtable, the attachments live on (possibly forever, but for at least a year) at their URLs.
There is no way to retract that URL, there is no way to stop that document from being viewed at that URL.
Furthermore, there is no ability to shield that URL from being viewed by only authorized users. Not even a simple authentication process.
And this is for every URL in the entire base.
A system that depends on all collaborators being 100% trustworthy at all times is not a fully-secure system.
And no, Google and DropBox absolutely DO NOT work in this way. They do not make ANY of your files publicly accessible. You have to choose who you want to share each file/folder with: nobody, certain people, or the entire world. And then, you can STOP SHARING at any time or CHANGE SHARING at any time.
Hey, there’s nobody that loves Airtable more than me, and 80% of my business comes from professional Airtable development, consulting, and training. But we need to call a spade a spade: robust security is not on Airtable’s list of strengths. So we should not give them credit where credit isn’t due. They are already complacent enough about fixing problems in the product. So no, Airtable doesn’t even come close to the security protections of what DropBox or Google offer, so I wouldn’t compare the two.
Can you share where you got this information? Have you tested this?
This support page states that data will be automatically deleted at the end of the retention period, which might be shorter than a year depending on the plan.
The page also states that data can be deleted sooner by contacting them.
I believe that access to the unpublished URL’s is a minor security risk considering that collaborators have access to the actual attachments themselves. If someone wants to do something nefarious with an attachment, they can do it with the actual document.
As for accidental leaks, Airtable has stated that they are not to be used as a CDN for attachments, so people shouldn’t be sharing those urls to begin with.
I agree that there are security issues with Airtable. But no system is 100% secure and users need to balance security with the need for people to get stuff done and with budgets.
Although it would be impractical to contact Airtable Support every time a lawyer deleted a file from one of his attachment fields. But that’s still a great find on that page! :slightly_smiling_face:
True, and this is a good point.
However, the attachments are stored as URL’s in the system, so the nefariousness would come from exporting the table as a CSV file, and then having the full list of URLs always accessible for a year — even after the collaborator is fired from the company. (Normally, any sort of nefarious employee can be STOPPED from doing a ton of harm as soon as they are fired.)
After 30 years of database development, I’ve seen all sorts of crazy things happen at businesses with untrustworthy employees: embezzling, stealing data, sharing proprietary data, etc. But typically, much of the damage can be stopped once the employee gets fired, or their access to the links is cut off, or whatever.
This isn’t really a budgetary thing — free & very inexpensive platforms have robust security built into them: Dropbox, Google Drive, FileMaker, etc.
I’m just trying to help Airtable here — I receive 5-10 new client inquiries every week for Airtable development work, and I can specifically tell them what drives businesses away from using the product, and what keeps businesses using the product. This issue has been one that has come up several times with companies that have sensitive data & can’t trust their employees.
I hate losing business as much as Airtable probably hates losing business!
I was specifically referring to the Pro Plan 1-year retention. I’ve actually tested as far back as 10 months, and my deleted attachments are still visible at their original URL’s. My guess is that this is because of the 1-year snapshot revision history. This is actually awesome that we can go back as far as we can in time! I actually love this! :slightly_smiling_face: These attachments should simply be protected.
Not a deal-breaker for most businesses, but it HAS been a deal-breaker for several of the businesses who have contacted me.
I lose business when people walk away from Airtable, and I don’t like that. Although if they migrate to FM, I gain the business, but still — I’d love to keep people in Airtable, because it’s such a fun & easy & great product! :slightly_smiling_face:
And yet, that was my relatively deeply informed impression that I got from the tone of this thread. :winking_face: I think the words with regard to #8 and #9 are not well-nuanced to provide the average reader with this clarity.
Ah, but my friend - you are so deeply invested in this that are you are failing to recognize a few aspects of these worries that @kuovonne elegantly called out.
Malicious distribution of content - whether by reference (URLs) or by value (actual documents) is not in the scope of any platform’s security model. Rather, they only have the responsibility of making it difficult for nefarious actors to do harm. They have no responsibility to prevent bad actors from doing harm beyond a reasonable degree. The architecture and the experiential evidence suggests Airtable has been both reasonable and relatively sound for sustaining secure operational outcomes and we can all agree that no platform is impervious to this type of security threat.
Could they provide better security and user experience? Certainly - no debate! Categorizing the items in my commentary as part of a MAJOR SECURITY HOLE is a leap that seems unreasonable.
Indeed, disabling URLs to deleted documents should be instant and at least as fast as the platform was able to take your FULLY PUBLIC URL FOM ANOTHER PLATFORM and make a copy of it.
I think it’s reasonable to expect the system loses the attachment’s URL in a timely fashion, but let’s be very honest about the facts - the documents that exist as attachments (contributed via URL) must ALL be public for such documents to exist in Airtable. Users are taking these steps with full awareness not unlike when they install a new app to their computer, or when they proactively share links to “anyone with the link”.
A more nuanced issue is uploading documents from the desktop - this exposes the files perhaps in a way where average users are not fully informed about the security implications. But, even in this case, uploading a document is not a security breach because the URL it creates is not predictable, findable, or indexable on the public Interwebs. As such, it is simply a security implication - it is neither a security threat, compromise, or breach.
It’s my opinion that attachment URLs which are long-sustained is an operational issue, not a security breach; another reason they have no basis for landing on your short list of major security holes.
Not entirely true. My experience shows that if you create a document in Google Drive, then expose the [secure] URL it in an email, Google will reset the permissions to “anyone with the link” in the background unless - and only unless - the indicated recipient is a Google Account-backed email address in which case, it shares it to that person, and only that person. Ideally, Airtable would work similarly, but Airtable doesn’t own any email systems, so it’s in no a position to assert such automation.
The definition of “collaborator” is a trusted person and even these trusted persons would be hard-pressed to locate the URL of an attachment in Airtable. As @kuovonne said, the easiest pathway for a trusted user to go rogue with your content is to make a copy of, download, and share, etc, etc, etc. Even if they could locate the URL easily, they are not likely to share it because they would probably assume the unauthorised recipient would get an access challenge. Nefarious actors simply don’t attempt to create data breaches by sharing deep links. :winking_face:
Here’s an attachment in Airtable - a picture of my wife. (yes, she’s a solid 9.5 and I’m like a 2.8 on a good day; I cannot explain this)
Seemingly (and based on your commentary) one might assume that you can copy the URL for this attachment, delete the record, and successfully access URL, right? For most users, this is what they will take away from your assertions. So let’s follow this example and delete the record, but first, let’s just try to see her smiling face from another browser which has no security context with my Airtable account. As hoped, the URL that Airtable gave me when viewing the attachment is secure.
Now, let’s delete the record and try it again - this time from the browser that DOES have a security context with my Airtable account. Hmm, the link logs me into the table where the image used to be but provides no deep link access to the original content. That seems reasonable.
The only way to make a case for deep links exposed beyond the deletion point is to recognize that you must deal directly with the attachments CDN and most users have little understanding of this nor are they able to even discover the underlying links unless they are logged in as trusted users. This is the actual underlying CDN URL in case anyone was wondering - it remains accessible after the record deletion. Perhaps you should document the steps required to acquire these URLs.
In my view, what Airtable has built with regard to attachment content seems reasonable, seems fairly secure and requires a lot of what-if’s to create a hypothetical breach.
