Deployment Blocker: Persistent Background File Scanning in Adobe Applications

[Lapster]

Dear Adobe Team,

I hope this message finds you well.

I am writing to highlight a critical issue we've encountered regarding the compatibility of certain Adobe Creative Suite applications with the macOS File Provider API, particularly but possibly not exclusively limited to when integrated with Google Drive. Following thorough investigation, we have identified a significant obstacle that we want to bring to your attention.

The issue stems from the continuous background scanning and indexing operations initiated by these applications upon access to Google Drive, resulting in the hydration of file provider stub files. Specifically, Adobe After Effects, Adobe Premiere, and Media Encoder are experiencing notable performance and functionality issues when accessing files stored on Google Drive via the new macOS File Provider API. This activity not only disrupts our deployment workflow but also poses a significant hindrance to regular Google Drive operations.

Despite our internal efforts to address the issue, including attempts to find a satisfactory solution, our current workaround involves blocking these applications' access to File Provider storage. However, this solution is suboptimal as it also hampers normal manual and voluntary file operations.

Of particular concern is the absence of a toggle option within the applications to control or disable the background scanning, leaving users without any means of mitigation or customization. Additionally, we recommend adherence to the same guidelines as Apple's QuickLook and Spotlight for File Provider indexing purposes, including refraining from fetching additional metadata if it does not exist in the stub file. Moreover, we suggest implementing a stop traversal mechanism upon encountering directories that are actually files or application bundles to align with industry best practices, as triggering the "open" event within a bundle leads to unnecessary resource consumption as bundles stored in cloud is stored as an archive (.pkgf) and has to be fully downloaded and unarchived.

This issue has caused some headaches in our deployment schedule and has impeded our ability to fully utilize Adobe products' features.

We hope your development team can investigate this issue further and provide a resolution or more practical workaround. We kindly ask you to reach out to us if further information, logs, or the like is required to address this issue effectively, so please feel free to contact us with any queries, clarifications, or problems in reproducing the issue. Thank you for your attention to this matter. We highly value our partnership with Adobe and looking forward to a resolution.

Steps to reproduce:

1. Install and login to Google Drive.

2. Install aforementioned Adobe products.

3. Put some content prefferably large in both volume size and structure on the Google My Drive, examples bundles .key files ( not flat ) with mp4 content, pkg, .app files.

4. Open for example Adobe After Effects, grant consent for google drive access. Wait some seconds and see the Google Drive menu bar queue load up with unwanted downloads.

Depending on how much content there is and what After Effects are interested in the queue can even be so full regular Google drive operations in finder is hindered.

System Info:

Architecture: Intel and Apple Silicon

macOS 14.4

Google Drive 89.0.2.0

Adobe After Effects 2024 (24.3)

Adobe Media Encoder 2024 (24.3)

Adobe Premiere Pro 2024 (24.3)

Tested on 2 know good machines DFUed and or reinstalled for lab purposes and 2 day to day for work machines

Sincerely,

Your Friends

Lars, Love, John

[Lapster]

Following some feedback and dialogue on the MacAdmins Slack channel, I wanted to provide a clarification regarding our recent communication regarding Adobe application behavior.

There has been a conversation on the MacAdmins Slack channel regarding Adobe's stance on remote storage access, which may have been misinterpreted. While our understanding of Adobe's stance regarding remote storage is that it may work but is not officially supported, our concern lies more with the unsolicited traversing and indexing of connected remote storage, and that the file provider consent box is presented at first launch instead of when willingly trying to open a file and such can lure users into accepting. Also meaning the application is already trying to traverse the cloud storage since our understanding of the Consent box is only shown in such a situation. 

Our intent is not to request full compatibility with remote storage but rather to address the intrusive behavior of background processes without explicit user consent or control. This behavior, primarily observed in Adobe's video editing software, feels somewhat concerning without a clear explanation or option to control it, akin to a rogue process.

Our preference would be to provide users with the option to utilize the open dialogue box within the applications without the concern of background processes scanning for files without explicit user interaction.

Upon further testing, it has become apparent that the issue may be more noticeable in step 3 if you for reproduction purposes uploaded the files recently to make them cloud-only before testing, the behaviour then becomes more visible without the need for logging fsusage in the background.

.

Also to reset the test and start again, please follow these steps: Lets use After Effects as an example.

1. Quit Adobe After Effects.

2. From the terminal, run the command "sudo tccutil reset All com.adobe.AfterEffects".

3. Disconnect and then reconnect your Google Drive account from its menu bar icon: Preferences > Settings.

4. Open Adobe After Effects again.

You will be prompted with the consent box for After Effects to access Google Drive. Clicking "No" to confirm that everything is functioning as expected. However, clicking "Yes" initiates the mass download process.

Furthermore, we will also be submitting a feature request to Apple for an MDM command to handle the kTCCServiceFileProviderDomain found in the TCC.db. This feature would greatly enhance administrative capabilities within enterprise environments via the MDM protocol and provide better control over file provider access permissions. However this request if implemented would only deny or grant access to both background scanning and manual opening of files not one or the other, this since it is the same application doing both. In the best of worlds consent would ideally be split into two part.

We believe that these updated reproduction steps will provide a clearer understanding of the issue and facilitate more accurate testing for resolution.

Thank you for your attention to this matter, and we appreciate your continued efforts in addressing this bug.

[Lapster]

The TLDR; for actionable feature requests to Adobe includes:

1. Cease indexing bundles, particularly keynote files, as they serve no purpose and can disrupt user workflows. This adjustment could potentially enhance application performance aswell.

2. Provide users with customizable options similar to Spotlight, such as the ability to exclude specific folders or file types from indexing. Offering users greater control through preferences aligns with the standard behavior of many Adobe applications regarding data location.

Please take into consideration, and all the best,