This post is in response to the 4/4/2022 email announcement titled “Changes to Airtable attachments” which announced that static URL’s will be going away.
This has a HUGE and sadly dramatic affect on my application. I’m using Airtable to crowd-source content for a weekly email - each member submits a form with their content, and I use formulas to roll together all the content into an automated weekly email, including images. It seems with this change that using static urls (as obtained via a formula and embedded into HTML tags) will no longer be possible.
I’m not sure how else I can embed photos into the emails I send out. I’m hoping someone can help think this through. A HUGE part of what I’m doing is about automating the compilation of multiple contributors into one email… it’s been working brilliantly for years… I’m so sad about this. I don’t know what to do…
Indeed, they mismanaged the apparent ability to use the product in unexpected ways. They should have anticipated this and counselled “developers” to be more aware of the risks. But who are the “developers” who typically extend the use of CDN URLs beyond the scope of Airtable? I think it’s those who actively use the API or the various SDKs because these attachment URLs are not easily discoverable unless you are writing code, right?
Well, perhaps. We don’t know how calm or chaotic it is over at Stacker concerning this change. My hunch is third-party developers were - for the most part - aware there could be risks and they took adequate steps to ensure their services were insulated from such changes concerning attachments. If they were not aware and blindly led their users into this abyss they are now in a position to lead them out.
These attachment URLS are very easily discoverable without code.
If you do a CSV export of a view, attachments are exported as their URLs.
If you create a formula field that includes an attachment, the result of the formula is the URL.
If you copy/paste an attachment to somewhere other than another attachment field, the result includes the URL.
People could have been depending on CSV backups, trusting that the actual attachment could be retrieved from the url in the CSV backup.
People could have been sharing CSV exports with people, trusting that the person who received the CSV export could click the url in the file to get the actual attachment.
People could have used formula fields to extract the url, and then used the URL of attachment elsewhere.
No, we don’t know what is going on at Stacker or any of the other portal services right now. We don’t know if they cache attachment urls or actual attachment files.
But we do know that portal services have been displaying Airtable attachments for as long as there have been portal services. And in order to display these attachments, they must at some point use the URLs provided by Airtable.
And above all; these people knew - or should have known - the risks because the warnings in the API are clear and obvious. Even without the warnings, any business based on another vendor’s technology is built with the assumption that (a) they are experts in crafting portals, and (b) are tightly connected with the vendor with at least a modicum of confidence that their architecture is sustainable.
Without question. And it’s likely these URLs work and will continue to work, but not indefinitely. In my view, a CSV is external to the UI and Airtable has no obligation to ensure the CSV will be accurate at some point in the distant future. They are certainly obligated to sustain the accuracy of a CSV for a reasonable time and that seems to coincide with the new announcement.
Yeah, this is tricky territory. CSV exports are data snapshots in time. At that time, all the data in the system matched the export. Should field values be treated any different than fields that contain URLs? They each have the capacity to change at the source while we’re holding the CSV snapshot. Should one class of field be guaranteed to be persistent? I don’t think so. That’s a big ask for a company whose prime directive is to manage your lists of data.
CSVs are code and they are external to the app. Formulas are code and they produce a URL of an underlying feature. My sense is that these formulas will still work when the signed URLs are changed so this is probably fine for these use cases. If they fail, I would interpret that as a failure.
Once again, you are suggesting this is an issue Airtable should be concerned about. If you take ANY data and copy it and paste somewhere and then the original data changes, this problem will bite you. So why should attachment URLs be sustained and preserved any more than any other data values? Isn’t it possible that someone deletes and re-uploads an attachment thus altering the image address?
Due to the ease in getting the urls without using the API, it isn’t reasonable for people to have to look at the API documentation for warnings. Plus, those warnings were not in the API documentation three years ago.
How are CSVs code? They are data. CVSs have no instructions. They take no input. They produce no output.
Yes, formulas are code. But many users don’t think of formulas as code, and it isn’t fair to expect formula writers to have the same level of diligence as people who write code for the REST API.
However, in the past, formulas have always produced the same output when given the same input. It sounds like that might change. It isn’t clear what is going to happen with formula fields. I’m looking forward to hearing more from Airtable about the impact of the changes on formula fields and scripting.
Overall, I think that this change is an important security enhancement. I also am glad that Airtable is announcing this well in advance to allow people time to make any necessary adjustments. However, I feel that we need a lot more information on how things will work in the future.
Slicing hairs now; this is codified data, not easily read or utilized by humans. It is external to Airtable and subject to the erosion of time. Are you suggesting Airtable should somehow warrantee the data in a CSV beyond a reasonable point in time? And if so, what is your expectation of a reasonable time?
Which “people” are you referring? Those who simply use the Airtable product to manage data? Those who attempt to integrate Airtable with other websites? Describe the personas who are impervious to the responsibilities associated with extending their Airtable solutions.
And they don’t have to, right? Aren’t formulas likely to keep working because they update in near-real-time against the latest signed URLs?
Can you be more specific about your trepidation concerning formulas and scripting. Internally, I assume (and Airtable has all but stated it) that formulas and scripts that access attachment URLs will continue to function, right? They’re just reading the latest instance of the URL and that will work for a few hours (apparently). If you then ship that URL off to another machine or human who needs to consume that content at a much later date, you have a problem. Aside from that use case, it should all be fine.
Integration Conflation
I get the sense there is a bit of conflation ongoing in this latest panic session. An email automation is a good example - you can create an email that exposes an attachment URL but that URL may expire before the recipient has a chance to read the message. This is unfortunate if you built a business process that depends on this functionality. But let’s be clear - this could fail even if Airtable never institutes this change. The record containing the attachment may be changed or deleted entirely. As such, when designing systems like this, even the no-coders must consider these likely scenarios.
@Bill.French - thank you for sharing this, very interesting that you had predicted this years ago! I do agree with @Portfolio_Pet that most people don’t care. But I’ve now lost hope that this WON’T happen if we complain enough… I head back from the support team who said they would share my concerns with the product team… I do believe in miracles… :crossed_fingers: :crossed_fingers: :crossed_fingers:
Never lose hope. There may be some clever approaches that will emerge as a result of your comments. And who knows, this could be the ideal tipping point for new aftermarket solutions to come forth mitigating the impact of these coming changes. I am very thankful Airtable has published a deprecation roadmap - it gives everyone time including the new aftermarket products to come to fruition. Just a wild guess - @openside is probably hard at work at this very moment.
When you say “this WON’T happen”, I suspect you have in your mind the perfect remedy. Please share if so. I’d like to know to what lengths you would like to see Airtable go to sacrifice security in the interest of flexibility.
Indeed, no one wants to be concerned with such details. That’s why we’re all huddled around the magnificent Airtable interface, right? However, when a portion of the user base decide to use Airtable as a back-office hosting server, should you be expected to subsidize the rise in prices when a small percentage of users force Airtable to serve up millions of requests per hour for product catalogs?
I’m sure we can all agree no one wants to pay more and especially not for Jimbo’s Jumbo Shrimp aprons that sell like - well - jumbo shrimp on special at 89 cents a pound.
Airtable has a duty to walk a very tight line between being a database management app and an accidental back-office web server. They have chosen – as I predicted they would – to be guarded against possible use cases that would risk everyone’s performance, security, and prices.
Considering all the constraints and customer interests, please tell me exactly what you would do?
It may not be easily read by humans, but it is a file format used by many humans who do not write code.
No.
I was referring to people who see and use attachment urls. If someone sees an attachment url because it is in their CSV backup, or because it is in a formula field, don’t expect them to look for documentation about how long that url will be valid.
I hope that urls from formula fields and from scripting will work as seamlessly as you suggest. It is quite possible that they will. But I don’t feel confident in that yet given the information that has been released so far. I don’t know yet how often the formula fields will update or if a url changing will be considered a “change” that can be watched for with an automation. I don’t know if they will be signed URLs or not. I don’t know if they will be converted to “viewer” urls or not. One piece of documentation stated that some urls would “viewer” urls.
Actually, previously the file would still be there even if the record was deleted or the attachment was deleted from the record. That was part of the security problem.
Yes, we should plan for this. I just want a bit more clarity on the changes so I can make better plans.
It’s not me saying this. I think this means they will continue to work as they work now. But to meet the definition of “work” they must update as urls expire and are replaced with new ones.
Airtable formulas - Formulas that reference attachment fields will not experience any changes in output.
Yep - and this is now likely irrelevant because the entire purpose of this change is security-related.
I never had such an expectation. What’s your remedy? Sacrifice security because no one wants to read the documentation?
