In our implementation of the DNSProxyProvider we are using the sourceAppSigningIdentifier obtained from the metadata of the FlowHandler to identify the origin of DNS queries being made by that FlowHandler. For most cases we are receiving useful info (i.e the originating app), but there is one specific case related to download tasks for a background NSURLSession where the info is empty.
Now I do realise that both sourceAppSigningIdentifier and sourceAppUniqueIdentifier are documented as 'may be empty in cases where the flow originates from a system process', but I am not sure if in my case if this is intentional, a bug or an oversight.
The case where no info is provided is when a background download initiates the flow when the originating app is no longer running. i.e The app might be doing a discretionary download or one with an earliestBeginDate set to the future. If the originating app initiates a task, but stays running while the flow gets created (whether frontmost app or not) then sourceAppSigningIdentifier contains the correct information.
To me this seems like its not intentional. My best guess for how such download tasks are accomplished is that they are immediately handed off to some system process to deal with, along with info about the calling app. So that information should still be available to this system process regardless of whether the app has been jetsamed in the meantime. And as such the NEFlowMetaData should be correctly populated.
As things currently stand, we are not able to determin the originating app in these cases and are unable to inform the user of why such a request might have been blocked. Also, for some apps we want to block all DNS requests, but with this behaviour there is a loophole that could be exploited by the app to bypass such a block.
