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.
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.
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…
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.
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.
I don’t deserve a lot of credit for this. It was obvious - their model was not secure by modern standards, it created a gaping opportunity for abuse (that we would all pay for), and the architecture represented a really easy way for people to build solutions that extend far beyond the threshold of the Airtable system and it’s prime objective.
As evidenced by that post, before I said a peep about this, Airtable was already hard at work on the remedy and it took them a while, but thankfully they didn’t spring it on us with a week’s notice.
Google has always had quota limitations for “hosted” files; both numbers (400,000) and aggregate sizes. By “hosted”, they mean anything exposed for openly accessible web requests. They also have real-time metrics that defend their servers from abuse. So even if you are within the quotas, you could find uploads cease to function depending on request demands for your collection of publicly shared documents.
Airtable’s CDN access was not so advanced and likely one reason they had to stop the bleeding. Think it through - if any vendor offered free hosting for content, they would be faced with massive abuse.
I’d love Airtable to create a attachment field type that provides the static URL for the attachments. That way those who need the security can have it, and those who need the public access also can have it. I worry this is more about storage and file hosting costs than security…
@VillageCo I totally agree that this would have been the best way for Airtable to handle this. It’s a shame that they took the “scorched earth” approach to this situation. I would highly recommend sending your thoughts to firstname.lastname@example.org.
That’s what they provide now. If they were to leave the current functionality and allow users to opt into that behaviour, there would be very few takers; they would continue to assert an insecure behaviour and Wall Street and every enterprise customer would frown on the lack of security.
Signed URLs (which have a shelf life) are the only way to assert any degree of secure access to publically addressable content.
Worry or not this architectural change is about all of these requirements; hosting costs, performance, security, formulas, SDKs - a broad reach and depth into all aspects of their service.
Describe for me how “this way” is any different from what they offer today? Not following.
Currently, attachment links never expire. Giving users the choice to delete links or leave them alone would be ideal. Just like how you can share a view with someone and then delete the link when you don’t want it shared anymore.
Your analogy is irrelevant. In the case of attachments, you are describing a very big collection of shared “things”. View’s a generally finite and few in number. Furthermore, they are individually shared through manual process. Can you imagine a UI for attachments that required you to individually assign each image?
And that’s what you want? This is no different, so you are basically advocating no change. Did I mistakenly assume you really cared about security?
What I’m saying is give the user the choice between the lower security option and the higher security option on a record-by-record basis. This is obviously not going to happen (as far as I can predict), so it’s not even worth discussing.
Okay - I understood that, but wouldn’t the entire user base who wants to continue to use Airtable as an accidental back-end CDN continue to do that, thus creating a load on Airtable that is abusive and likely to raise everyone’s costs?
Security is not the only element in the equation. In fact, it’s probably not the primary element that needed to be solved. Obfuscated URLs presently do a fair job at concealing content from the public. But Airtable has become the web host for millions of documents and this is what they’re trying to end.
Making it optional is like making ice cream [optionally] free; everyone will take as much as they can.