[Feature] Ability to share items stored in vault with other apps

[starry-shivam]

Right now, if I need to share a file stored inside SafeSpace, I have to first copy or export that file into my internal storage and then share it with whatever app I want. I think having a "share" option on a popup that appears when long-pressing the file, allowing users to directly share files with any other compatible app without copying or moving the file outside of the vault, would be a neat feature to have! If you want, I can probably work on adding this feature, as it would be personally helpful for me as well, lol :)

[aashishksahu]

Thanks for the idea! It sounds great, only question, is there a way to make sure that the file isn't accessible by other apps once they are closed? for example, if I have a PDF file in SafeSpace and I open it using adobe pdf reader, then, adobe reader should not retain access to the file once I press the back button or close adobe reader. If there's a way to ensure this then, you can go ahead and start working on this feature.

Also, just a side note, please create a branch from my repository instead of creating a fork, this way you'll show as a contributor in the repository, what do you think?

[starry-shivam]

We can use something like Intent.ACTION_VIEW plus the mimetype of the file, coupled with the FileProvider API, to securely share a file URI with 3rd party apps. That way, we can grant read permission for 3rd party apps, allowing them to read only that specific file being shared. About the concern that "apps should not retain access to the file once I press the back button or close them," unfortunately, there is no reliable way to achieve this.

While using the File Provider API, permissions (read or write) are granted for a certain period and are automatically revoked by the Android OS once the 3rd party app is closed. However, this doesn't prevent apps from, for example, copying the file to their own storage.

Take a messaging app like Telegram, for instance:

• I can share a file with it using File Provider.
• Android OS grants permission to Telegram to read the file while it's open.
• But when I send that file to someone via a message, it's uploaded to Telegram's servers.

Even if Android OS revokes Telegram's access to the file, it won't change anything since the file is now on Telegram's servers.

The same applies to Adobe; if Adobe imports or copies the file you're sharing to its own internal storage, even if Android OS revokes permission for the original file, the copy will stay in Adobe's storage. Android OS won't prevent Adobe from accessing the copy since it's in its own internal files directory, similar to how SafeSpace stores files in its own internal directory. So, ultimately, it's the user's responsibility to choose which apps to share files with.

I hope it makes sense, lemme know what you think.

Also, just a side note, please create a branch from my repository instead of creating a fork, this way you'll show as a contributor in the repository, what do you think?

I don't think you can create a branch from another person's repository unless you've been added as a collaborator by the owner of that repository :)

[aashishksahu]

Yeah I thought so too, there really isn't a way to securely share files with other apps, that's why I added support for a few files types like audio/video, pdfs, images and ZIPs. Can we instead add better support for file types within the app, this way we can avoid any privacy breaches and dependency on other apps that we cannot trust, we can start by making PDF support better, currently there's no way of copying text from PDFs as I am using PDF renderer to display PDFs, maybe we can try MuPDF, what do you think?

I didn't know about the branch thing 🤔

[starry-shivam]

While it's certainly a great idea to enhance built-in support for different file types, I don't think it addresses the initial issue: the need to export a file out of the vault when a user wants to share a specific file stored within it to someone or somewhere else.

Let's consider an example: the app has good support for viewing images, and I have a few images stored inside my vault that I don't want apps with full file access, like those requiring the MANAGE_EXTERNAL_STORAGE permission, to access. However, when I need to share one of those images with a friend via, let's say, Telegram or any other messaging app, I still have to export the file out of my vault first. This technically makes it visible to all apps holding the MANAGE_EXTERNAL_STORAGE permission, instead of just the one specific app where I intentionally wanted to share it.

Moreover, I don't believe this feature deviates from the original purpose of the app, which, as I understand from the readme, is to provide a safe place to store files and keep them hidden from apps with permission to view all files stored within the internal storage or basically apps having MANAGE_EXTERNAL_STORAGE permission. Instead, it serves as an additional step towards ensuring that purpose, as illustrated in the example I've mentioned above.

[starry-shivam]

I didn't know about the branch thing 🤔

Take a look at these :)

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule

https://stackoverflow.com/questions/71349941/how-do-i-allow-contributors-to-make-branches-but-not-commit-to-main-in-an-organ

[aashishksahu]

While it's certainly a great idea to enhance built-in support for different file types, I don't think it addresses the initial issue: the need to export a file out of the vault when a user wants to share a specific file stored within it to someone or somewhere else.

Let's consider an example: the app has good support for viewing images, and I have a few images stored inside my vault that I don't want apps with full file access, like those requiring the MANAGE_EXTERNAL_STORAGE permission, to access. However, when I need to share one of those images with a friend via, let's say, Telegram or any other messaging app, I still have to export the file out of my vault first. This technically makes it visible to all apps holding the MANAGE_EXTERNAL_STORAGE permission, instead of just the one specific app where I intentionally wanted to share it.

Moreover, I don't believe this feature deviates from the original purpose of the app, which, as I understand from the readme, is to provide a safe place to store files and keep them hidden from apps with permission to view all files stored within the internal storage or basically apps having MANAGE_EXTERNAL_STORAGE permission. Instead, it serves as an additional step towards ensuring that purpose, as illustrated in the example I've mentioned above.

This sounds good, we can add a share option, along with a dialog that describes the nature of this feature transparently.

[aashishksahu]

I didn't know about the branch thing 🤔

Take a look at these :)

https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule

https://stackoverflow.com/questions/71349941/how-do-i-allow-contributors-to-make-branches-but-not-commit-to-main-in-an-organ

I'll have to create an organization account to provide granular access, I can't do that as it may violate the terms with my current org. I don't want my hobby project to turn into moonlighting, lol.

[aashishksahu]

wait, the repository is showing contributors now 🙀does Github have a sentient AI or something...

[starry-shivam]

@aashishksahu Nah you don't need to create an organisation account to have branch protection rules and add collaborators, just go to repository settings > collaborators to add collaborators and then settings > branches > branch protection rules, to add BPR to your main branch!

[aashishksahu]

hmm.. let me see...

[starry-shivam]

This sounds good, we can add a share option, along with a dialog that describes the nature of this feature transparently.

Yeah, I also thought about showing some kind of pop-up or dialog that warns the user with something like, "You're sharing this file with a third-party app which may cause privacy-related issues. Proceed with caution."

I'll start working on this feature and create a PR soon :)

[aashishksahu]

Ok great, take your time, next release will be after 15th april.

[aashishksahu]

@starry-shivam Looks like I have done something dumb with the branches, I created a quality branch, merged my changes to it, then when I tried to merge your changes to it, it says nothing to compare. sorry about this dumb thing, but can you please help me out 😿

[starry-shivam]

I can see that you've already merged my changes into the Quality branch before merging yours. It now includes both my modifications and your additions related to brute force protection. so, it's saying correct that there's nothing to compare, however i didn't understand why you merged quality branch into brute force branch and then again merged brute force branch into Quality.

[aashishksahu]

For some reason the recycler view package was empty when I did this, so I thought I mistakenly have overwritten your changes so I merged again. I got git lost. And then I mixed up even further.

[starry-shivam]

I see, i think it has became kind of mess now.. but there is a way to solve all of this, do this step by step:

1. Delete the Quality branch
2. Checkout to brute force branch and hard reset it to this commit by doing:

   git checkout 41-brute-force-protection
   git reset --hard 472664edcf55363220d8031067e88d16df29758d
   git push -f

3. Now either create a new branch from main (next-release or something) and merge brute force branch into the newly created next-release branch, or you can also just merge brute force branch directly into the main branch.
4. after that, merge my branch (issue-47) into the newly created branch and now the new branch includes both yours and my changes in correct order, merge it into the main. If you've done the latter in step-3, (i.e. merging your brute force branch into the main branch directly), then skip all this and merge my branch directly into main as well.

Tip: Use "Squash and merge" merging technique instead of merging all of the individual commits, to have a cleaner git history.

[aashishksahu]

Thanks, I’ll get started :)

[starry-shivam]

Thanks, I’ll get started :)

I had a typo, the command is git reset not git restore sorry for the confusion, I've edited it now

[aashishksahu]

No probs, I haven’t started yet.

[aashishksahu]

@starry-shivam I followed your instructions and its still the same problem, your changes are some how being overwritten, even if I first merge mine and then yours. This is some strange behavior 🤔. I guess I have to rewrite my changes on your branch (manually 😿)

[starry-shivam]

It's very strange. Since both my PR and yours were based on the main branch, there's a chance that when merging my changes on top of yours, there could be some conflicts. However, it shouldn't overwrite the changes. I don't know what's going wrong here, to be honest..

[aashishksahu]

I don't know what's going wrong here, to be honest..

Lol... all of us programmers 😂. Anyway, looks like its copy+paste time.