|Category:||-||Estimated time:||3.00 hours|
|Target version:||-||Spent time:||-|
OPML files are the standard way to import/export collections of RSS/Atom feeds. Courier should support OPML.
#1 Updated by ocdavid about 3 years ago
- Due date set to 02/14/2015
- Assignee set to ocdavid
- Priority changed from High to Normal
- % Done changed from 0 to 10
- Estimated time set to 3.00
This is a great feature idea that meshes well with our work to improve the "add feed(s)" capability of Courier. It needs more definition, however, so I'll kick that off by asking some questions:
1. This capability seems to raise security questions since the files used for import or export would be un-encrypted. How concerned are we about having such artifacts? Do we need to consider something like "import then delete" or "export then delete exported file in 5 minutes"?
2. What is the imagined scenario here? Is this capability sought so as to allow the user to migrate from another RSS reader to Courier (or vice versa)? Or, is the scenario more like "share my feed list with a friend"?
3. Courier provides users with a "pre-subscribed" list of feeds and we allow users to add their own. Using new funding, we will significantly enhance the latter capability. If a feed list is to be imported, should the imported list REPLACE the feed list that's already in the app, or ADD TO IT?
#2 Updated by hans about 3 years ago
I hadn't thought about the privacy issues of OPML import/export, good you brought it up :). There are a number of use cases:
- import/export to migrate from one app to another
- export to back up current feed collection
- import to restore feeds on new device
- export to share with a friend
My guess about replace vs add is that OPML importing adds. But lots of apps support OPML, so it would be easy to see what people are doing.
I think for import, the threat would be if somehow someone sent an OPML file that caused either an exploit of Courier or a data leak to help deanonymize the user. As long as the import process is never transparent (i.e. the user is prompted on incoming import, or the user must initiate the import), then I think it is not a big risk. If the user wants to add those feeds, they'll do so manually anyhow.
As for export, the risks there are greater since the list of feeds could be sensitive information. Perhaps there is a way to "stream" the OPML straight from Courier's IOCipher store?
#3 Updated by ocdavid about 3 years ago
The largest privacy/security issue surrounding import/export is the ARTIFACT (file) required to do so - an unencrypted artifact is required and this is dangerous in the geographies Courier (and especially its variants) supports.
I'm going to conceptually separate "export" and "share". Courier has a secure share mechanism - requiring physical proximity - and we'll continue with that, adding "share my feed list" to the existing "share a feed" and "share an article" capabilities. That mechanism does indeed "stream" (Courier to Courier). We'll think of export as "Courier to Non-Courier", and that raises the security issues.
As for ADD vs REPLACE, this needs to be considered in light of our new strategy regarding the feed list. Currently, Courier offers a few feeds by default and it is difficult to add feeds. We're improving the "add feed" capability in the coming release in ways that will support (a) a large number of default feeds and (b) ease of adding feeds - implying each user's feed list will be long, and will contain SUBSTANTIALLY OVERLAPPING feed addresses. For example, user A's feed list might contain 100 entries, of which 2 are different from user B's. Therefore, by the time THIS feature becomes available, what we'd want is DIFF+ADD (rather than ADD only or REPLACE only).
Scenarios: Given the scenarios you mention, I think we need to consider as part of this feature "import with BURN" and "export with BURN" (meaning killing the import/export file from storage after use).
#5 Updated by hans about 3 years ago
Definitely DIFF+ADD, no use in having multiple copies of the same feed. Perhaps there will be issues with the same feed having different configs, like "include comments"? To handle that, there will need to be some clear behavior, probably one of these:
- keep current config
- replace current config with incoming config
- prompt user to choose current or incoming
Courier-only export makes sense for now. As for supporting OPML for the general user, I think that import from anything is more important that exporting to anything. I think it makes good sense to start with implementing import any OPML, and secure export only to Courier.
#6 Updated by hans almost 3 years ago
I just had a thought: using TrustedIntents and the OpenPGP Android API, Courier could have a "secure backup" feature that would be quite tight. Basically, it would only export to a trusted encryption app (our GPG or OpenKeychain, for example). That app would then encrypt it to the GPG key.
This could also be done using standard AES symmetric encryption, using either the same password or the same cacheword key as the encrypted storage.
#7 Updated by ocdavid almost 3 years ago
I like the idea of sharing to a trusted encryption app. That approach "exports" the entire question of where the file ultimately ends up and who uses it because from our app's perspective we've just created a safe file.
That said, we'll have to offer the possibility of sharing to other apps without encryption as well.
Thus, I guess a "fallback" approach is warranted: (1) try TrustedIntent to see if there are apps that will share that way, (2) fall back to normal Android Share Intent if none.
#11 Updated by hans over 2 years ago
The feed finder is definitely good news, but it won't cover all of the use cases that OPML import does. For example, there are some feeds that have subscriber info in them. I pay an annual fee to Ars Technica to get access to the full text feed, and that requires a custom, per-user feed URL.