breautek commented on code in PR #1609:
URL: https://github.com/apache/cordova-android/pull/1609#discussion_r1181555291


##########
templates/project/res/xml/opener_paths.xml:
##########
@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- 
https://developer.android.com/reference/android/support/v4/content/FileProvider.html#SpecifyFiles
 -->
+<paths xmlns:android="http://schemas.android.com/apk/res/android";>

Review Comment:
   On the security front, I think we are in the clear.
   
   Having the file provider and declaring which files/folders are 
shareable/visible isn't enough to share files. It is part of the process to 
setup fire sharing, but the app needs to do additional steps to actually share 
files.
   
   Most of the time this is done via setting up a specialized 
[Activity](https://developer.android.com/training/secure-file-sharing/share-file),
 where a third-party app would create an Intent, which may target your app in 
which your app will start an activity to select a file and provide a result. 
The `Context.grantUriPermission` can achieve the same result, but permisison 
will be granted permanently, or until the app explicitly revokes the 
permission, whereas the Intent way is a temporary permission grant.
   
   Cordova apps only have a single activity, generally speaking, which is the 
main activity for the application. So I believe the only way this can be an 
issue is if someone decides to implement an activity that responds to intents 
and uses this file provider being introduced in this PR, which is an unlikely 
scenario.
   
   We could write a note for future app developers/plugin authors in 
`templates/project/res/xml/opener_paths.xml` that describing that the file 
provider may only be used for the application itself and should **not** be used 
for responding to Intents because it will expose the app's private data folders.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org

Reply via email to