Proposa noves funcionalitats

Another problem with this is that the authorization metadata can be sensitive in nature. If this data is delivered through an email (as it is now), it can make the delivered data vulnerable for information leaks as email is not a secure data transfer method as itself.

Ivan Vergés

11/10/2019 10:55

Do you have any proposal of how to do that and deal with multi-server installations?
There's a first proposal of serving encrypted zips here
https://github.com/decidim/decidim/pull/5342
However it stills suffers the wickness of sending the password via email

Antti Hukkanen

11/10/2019 11:13

Yeah, there is not much sense to encrypt the data in case the encryption key is in the same message as the encrypted data. This is comparable to delivering the data without any encryption.

The encryption key could be shown e.g. under the user's personal data page where they could get it. Although it's much more complicated for the user (especially as they need a special software to open the file), so I would expect this to generate additional support requests.

In my opinion, the personal data should not be sent over email at all. The export should become available for a period of time under the "My data" section and the email should just state that the data can be now downloaded from that page. Before that, it should instruct the user to wait for the export to complete.

Ivan Vergés

11/10/2019 11:24

Probably the best idea, but dealing with multi-server instances we cannot rely on the server filesystem to store the data. It should have to be stored in a S3-storage like system. Then we should provision security either encrypting that file and decrypting it when downloading or other methods available in the file-storage provider. I think that's the main technical challenge to overcome to do that.

Antti Hukkanen

18/10/2019 09:22

I think the multi-server instances should not be any different of single server instances. We are already storing data that needs to persist over the multiple servers, such as proposal attachments, participatory space images, organization images, etc.

This can be already handled through Carrierwave or Active Storage.

However, I would think that it would be beneficial to define few different storage locations for the data:
- One for the public data that is stored right now
- One for the private data that should not be available through any public URLs (the files themselves, they would always have to be served through a Rails route to check the user has rights to download the files)

The private data location could be also used for other more sensitive files, such as the authorization attachment uploads (e.g. copy of passport).