Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation request: security implications of working with .exo files #6332

Closed
tfcporciuncula opened this issue Aug 22, 2019 · 3 comments
Closed

Comments

@tfcporciuncula
Copy link

@tfcporciuncula tfcporciuncula commented Aug 22, 2019

[REQUIRED] Use case description

Given our not super strict security requirements, we're trying to understand if allowing downloaded .exo files to be in the external storage system would be reasonable.

  • It's clear it's not straightforward to play them outside the app where they were downloaded, but it'd be nice to understand in details what it takes to be able to do that, so it's easy to understand whether it's secure enough or not for any specific situation.

  • AFAIK, there used to be an easy way to encrypt cache files with SimpleCache, but that doesn't work anymore with the new database cache index. It'd also be interesting to understand if we don't need that anymore (since the database stays in the app internal storage instead of alongside the media pieces -- which is how the old index worked, I think?) or if there are plans to support this in the future.

  • There are two issues that touch this subject (but just a bit): #4937 #5762

  • And also, thanks @andrewlewis for giving me more context and helping me getting the understanding I got around this so far.

Proposed solution

A simple documentation page (or maybe a new section in the Downloading media page) explaining the security implications of working with the .exo files would be great.

Alternatives considered

If it makes sense, maybe supporting encryption for the database cache index?

@tonihei
Copy link
Contributor

@tonihei tonihei commented Aug 23, 2019

It's clear it's not straightforward to play them outside the app where they were downloaded, but it'd be nice to understand in details what it takes to be able to do that, so it's easy to understand whether it's secure enough or not for any specific situation.

The files are not encrypted by default, so they just contain the plain media data. They may not be playable as they are, depending on which part of the data the file actually represents. But if someone puts some effort into piecing the right .exo files together, they should be able to play them.

Note that there is an option to encrypt files as explained here.

AFAIK, there used to be an easy way to encrypt cache files with SimpleCache, but that doesn't work anymore with the new database cache index. It'd also be interesting to understand if we don't need that anymore (since the database stays in the app internal storage instead of alongside the media pieces -- which is how the old index worked, I think?) or if there are plans to support this in the future.

My understanding is that the database is stored in internal device storage and no other app has access to this storage. That still means of course that rooted devices for example may have access to the database. Note that you should still be able to encrypt the media data files themselves even if the index is stored in a database.

A simple documentation page (or maybe a new section in the Downloading media page) explaining the security implications of working with the .exo files would be great.

Agreed. @andrewlewis already marked this as a documentation candidate. So we will probably look into adding this to our web page at some point.

@tonihei tonihei self-assigned this Aug 23, 2019
@tonihei tonihei closed this Dec 10, 2019
@tfcporciuncula
Copy link
Author

@tfcporciuncula tfcporciuncula commented Dec 11, 2019

@tonihei are you still looking into adding this to your web page at some point? I'd just like to know if this is still in your plans.

@tonihei
Copy link
Contributor

@tonihei tonihei commented Dec 11, 2019

Yes, no worries, it's just that we usually close issues if the only remaining task is the "documentation candidate" label. That's because there is no immediate pressing action for us.

@google google locked and limited conversation to collaborators Feb 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants