# Questions & Answers ## What data does the application collect? If you enable cloud sync, the application transmits your stock, history, and custom types. This information is linked to a unique, randomly generated identifier (UUID). The application also sends error reports to improve stability and user experience to a self-hosted Sentry. All this data is transmitted to our servers. No other person or company has access to it. No personally identifiable, location, or other sensitive data is transmitted. Data privacy is one of our priorities. ## Who develops the application? The application is developed by RanTigr, on free-time. The project is managed by the non-profit organization [DStash Foundation](https://diapstash.com/organization). Some others users contribute to the app, by completing the [catalog](/contribute/catalog) or [translate](/contribute/translate) the app. ## Can I upload pictures in history/diaper? No, it's not possible to upload pictures in the app. Cloud sync would require us to store your photos on our servers. In addition to the storage cost, we would need to secure access to your photos, whether via network requests or in the event of a server intrusion. This is too much work for us to handle at present. We pay particular attention to your data. DiapStash does not use any personal data to ensure the most anonymous experience possible. Your photos are too personal for us to consider storing them. ## Why can't I edit a shared history? Shared histories are available in read-only mode. This is a technical choice. Interacting with a shared history requires performing verifications and modifications on multiple elements. These actions are currently done directly in the application. To perform these actions in shared history, we would need to perform these actions on the server side. This cannot be done in the application because we need to ensure that people accessing a history have all the necessary permissions. This would therefore involve duplicating the code so that it is both in the application and on the server side. Code duplication creates major risks of bugs related to processing differences, and would involve doubling the work to be done with each code modification. Moreover, since the application is distributed progressively (*it generally takes 1 week for a majority of users to be on the most recent version*), we would need to ensure that the server adapts its behavior according to users. This technical choice is therefore made to guarantee maximum stability and without adding workload (*the application is developed in my free time*). Furthermore, we would need to adapt the application interface to indicate to each user which history they are manipulating. This can be complicated to propose due to the fact that we must ensure that the entire application is usable on very varied screen sizes.