Anders
My feedback
308 results found
-
406 votes
Hi everyone,
For our thoughts on Monero, check out our Bitcoin deep dive with Seth on the latest Opt Out podcast: https://www.youtube.com/watch?v=gUGJje2jvck
Anders
supported this idea
·
-
270 votes
Hi everyone, this one is under consideration, pending anti-spam measures we might need to take.
An error occurred while saving the comment Anders
supported this idea
·
-
1,254 votesAnders
supported this idea
·
-
113 votesAnders
supported this idea
·
-
62 votesAnders
supported this idea
·
-
70 votesAnders
supported this idea
·
-
96 votesAnders
supported this idea
·
-
111 votesAnders
supported this idea
·
-
130 votesAnders
supported this idea
·
-
153 votesAnders
supported this idea
·
-
158 votesAnders
supported this idea
·
-
173 votesAnders
supported this idea
·
-
231 votesAnders
supported this idea
·
-
238 votesAnders
supported this idea
·
-
253 votesAnders
supported this idea
·
-
339 votesAnders
supported this idea
·
-
377 votesAnders
supported this idea
·
-
408 votesAnders
supported this idea
·
-
723 votesAnders
supported this idea
·
-
1,420 votesAnders
supported this idea
·
Hello,
I am happy to see that this issue is being considered, because the current integration really needs to improve. It is way too easy to mess up and not use an alias during everyday email correspondances.
Please consider, for starters, implementing some kind of user controlled setting that allows for automatically adding cc'd recipients to the adress book, while connecting these to the alias that is used for the main recipient. This should both be done for simplelogin and it should be synchronized to proton Pass.
More importantly for the final solution, safety needs to be improved drastically through massive improvements in the user interface for Proton users ability to control alias usage.
- The interface for choosing adresses used for replies in real time in the proton mail app should be implemented with a much higher degree of transparency - right now we have none, and the fact that sender field is displaying a personal mail adress, and that I have to press send and cross my fingers that settings in the pass app are correct, is not an acceptable or safe approach to handling aliases. Clear choices should be available directly in in the mail app while composing emails. This improves safety, not to mention the increased ease of mind for the user, knowing that their email adresses are not being accidentqlly exposed.
This should be implemented with extremely clearly communicated settings available to the user, and with a very direct control of when and how the user sends a mail through a spefic alias or through the users personal email adresses.
The level of control should be adjustable with both presets for default aliases or personal mail adresses used for individual contacts, but also with catch all settings for assigning aliases to group messaging correspondances, and, with the option of high granularity control available for multi recipient messages.
It should always be extremely clearly communicated to the user, when they are about to send an email that exposes a personal email adress to a recipient and how alias usage so far have connected your activity for any usage involving the same alias for multiple recipients. It should raise a clear warning, notifying the user of the acute risk of exposing the personal email adress, informing the user how excactly it is happening, and, to what degree the users information will be leaked to others. Standard settings can then be offered to the user for a specific thread/group correspondence and to specific contacts, as to avoid warnings for these clearly defined cases in the future, with the possibility of easily changing setrings later.
Further, the user should be able to choose warning levels for individual personal adresses and maybe additionally for group level choices. Specifically the option of outright banning specific personal adresses from being used should be available with a toggle on and off option, and definitely a setting should be available for some intermediate level of security, stating that an adress should never used for replies or for composing emails without explicit consent for individual contacts, groups, or for specific correspondences.
Profiles for professional, private and personal settings could also be considered for different sets of settings, in order to manage which possible adresses will be available and suggested for different types correspondences.
Better user interfaces minimizes the risk of errors in trying to maintain privacy. Hardcore privacy-dependent users might be well versed in the protocols, and they might be good at handling a strict behavioral approach to alias management for privacy, remembering to switch between apps, adding recipients to adress books, connecting these to specific aliases before going back and replying to an email, but the rest of us are to a much higher degree protected by ease of use and error-minimizing user interfaces.