No More Static URLs for Attachments?

Indeed, but, ya’ should have known. I predicted this change in 2019 and even encouraged Airtable to weigh in on the risks associated with the idea that (a) it makes no sense to treat image URLs as immutable and sustained, and (b) that it makes no sense to assume that Airtable (a database for small systems) is also going to provide you with a globally sustained CDN for free.

If you’re a total geek and recognize the importance of data architectures that include binary artifacts by reference, not by value - you might enjoy this thread from about three years ago where I predicted Airtable would eventually realize their shortfalls in the attachment design.

Evan Hahn (Airtable Engineer with Deep Insight)
… can’t guarantee fully static URLs

Bill French (Mr Nobody)
Nor should you. Related to this topic are the attachment URLs themselves (which are publicly accessible). I (and many of my clients) have trepidation about this and it is a factor that often rules out Airtable as a choice. Unbeknownst to most users – all attached documents in a base are openly exposed in a CDN-like environment (i.e., dl.airtable.com 6 ). I get it - the hash-keys for any given document are unpredictable and this is the basis for claiming they are secure. “Security by obscurity” are often the last words any CEO remembers just before seeing the “On-Air” light flash from a chair at CNBC as they queue up Kate Fazzini 6 to drill you about a security breach. I have to believe you and the team are pondering how and when this design must change. Have you considered signed-URLs 6 and a new API method that would give us the ability to create signed URLs for attachment documents?

The party ended in 2019; we just didn’t know it.

@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:

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.

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.

@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:

Airtable has image limits, but Google Drive does not really have any practical image limits. The limits of Google Drive are limited only by the storage space that you pay for.

Hi @ScottWorld!

I got my field names mixed up!

I thought the change would affect the attachment field type, I believe this change will affect the URL field type.

Back to your reply, it seems that Google has made a change, recently, regarding the number of images that can be downloaded to third parties, such as Airtable.

I am planning to contact support to find out more details.

My Google Workspace has a alot storage available.

Mary

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?

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…

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…

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.

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.

Oh, I see what you’re saying — you’re saying that from Airtable’s point-of-view, my suggestion changes absolutely nothing. You are 100% correct, and I completely agree with what you said above.

You are correct that they are not really trying to change the security model so much as they’re trying to prevent an incredible load on their servers because people are using them as a CDN. (The security enhancement is just a side effect of their primary goal.)

So what I failed to add to my suggestion above is this critical piece of information:

• Airtable should also add a new pricing/fee structure to account for people who want to use Airtable in this fashion.

This could: (a) be a good revenue stream for them, and (b) give many users what they want.

That is one possible remedy. But as you know, easier said than actually built. Putting it mildly, pricing models are already not their strong suit. :winking_face:

Indeed. However, you have to assume that Airtable wants to be in the CDN business. I’m pretty sure they don’t because that’s an entirely different business from building really cool database products.

Today, Airtable is a consumer of CDN services, not a producer. Producers can only do this well at scale, and Airtable’s CDN activity would be a rounding error for any company that does this as a core product offering. Not all revenue is good revenue; dollars don’t equate to profits and especially the case when you’re a small fish in a very large pond. I suspect they assessed this possibility and rejected it for exactly the reasons I mentioned.

In my view, I do agree that this is a good revenue stream for “someone”, but it’s a feature Airtable should fear trying to earn a profit with and apparently has already decided such.

I completely understand why you and many others would come to the conclusion that this would be good. It would compress the technology stack required to give users what they want while simplifying solution complexities. These benefits are not insignificant and I suspect it’s a reason many solution builders adopted Airtable in the first place. However, a new paid service like this would largely appeal either to enterprises (who do not already have CDN options) or Airtable users (who do not have either CDN options or extra cash to pay for added CDN features).