They can share the entire nip19 link with they key then they can see it, if they only have the url to the file they won't be able to decrypt it
Discussion
Got it, so they would still need the key
Why not just 
.enc#key=base64uri-decryption-key&mime=png&hash=abcde…
Whats cool about this is that when you click it in a nostr client that doesn’t support encrypted images in dms, it could open on filehost.com and decrypt it clientside for display
I think the only additional thing needed to make this work is Accept: application/octet-stream in the header for the raw download, otherwise the link opens in a viewer client when you click it.
I wouldn't put the secret in the URL. Otherwise, the image host also has access to the secret and thus the image.
This is a little less descriptive than a nip19 link which says it has a secret, more parsing and expectation required to know that a random URL might need decryption
could just have a simple nip that defines a few # params and to pass Accept header for raw data. Would be nice for backwards compatibility.
If we go the nip19 + nip94 route this would be more work and encrypted images wouldn’t work in most clients, this would at least have a clickable fallback that gives clients an upgrade path. We still care about that right? Or do we want broken images in DMs too.
The amount of work just to get uploadable images working in DMs is starting to get crazy otherwise:
nip04
nip19 (required)
nip94 (required, not even planning on implementing this in damus)
vs
nip04
nip?? (optional)
We can do both. NIP-19 + URL.
To be fair, the proposed NIP-19 add-ons are not only for NIP-94 and not for just files. Other event kinds that use shareable-secret encryption can use the same technique.