No More Static URLs for Attachments?

[VillageCo]

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…

[Bill_French]

VillageCo:

very interesting that you had predicted this years ago!

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.

[M_k]

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

[Bill_French]

M_k:

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

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.

[VillageCo]

Bill.French:

When you say “ this WON’T happen ”, I suspect you have in your mind the perfect remedy.

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…

[ScottWorld]

@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 support@airtable.com.

[Bill_French]

VillageCo:

I’d love Airtable to create a attachment field type that provides the static URL for the attachments.

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.

VillageCo:

I worry this is more about storage and file hosting costs than security…

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.

ScottWorld:

I totally agree that this would have been the best way for Airtable to handle this.

Describe for me how “this way” is any different from what they offer today? Not following.

[ScottWorld]

Bill.French:

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.

[Bill_French]

ScottWorld:

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?

ScottWorld:

Currently, attachment links never expire.

ScottWorld:

Giving users the choice to delete links or leave them alone would be ideal.

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? :winking_face:

[ScottWorld]

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.

[Bill_French]

ScottWorld:

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.

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.