Thomas Anderson
My feedback
6 results found
-
62 votes
An error occurred while saving the comment Thomas Anderson supported this idea ·
-
684 votes
An error occurred while saving the comment Thomas Anderson commented
Dear Proton,
Please implement this feature.
I work in IT for large supercomputing infrastructures, no doubt as your origins are from CERN, you are aware of how easy it should be to implement access rights management feature like this.
Perhaps it could be sufficient to just add 'Access Rights Management' and then a dropdown or checkbox for each e-mailaddress where you can choose the Permissions.
E.g. below
Username 1 or Proton E-mail alias 1 |
Allow login to Proton account?: Checkbox: Yes |
E-mail can be sent from this addres?: Checkbox: No |
Can access services other than Protonmail? Checkbox: Yes |E-mail alias 2 |
Can login to Proton account? Checkbox: No |
E--mail can be sent from this addres? Checkbox: Yes |
Can access services other than Protonmail? Checkbox: No |E-mail alias 3 |
Can login to Proton account?: Checkbox: No |
E--mail can be sent from this addres?: Checkbox: Yes |
Can access services other than Protonmail?: Checkbox: No |In the above manner the primary username is used to login only, and never exposed sending an e-mail.
Furthermore, other e-mail aliases cannot login or access a different Proton service, but just send e-mail, as is their purpose. These aliases can be selected from the already existing dropdown function Protonmail has.
What does this accomplish?
- The benefit of never exposing your username externally, annihilating the first coordinate of the attack surface. If you don't even have a username to begin with, you'd have to guess/bruteforce that too.
- A neat segregation of access rights, it's not necessary to be able to login with all e-mail aliases. Some are only used to send e-mail with.
- We already trust in Proton's sturdy security practices. You don't just get an ISO 27001.
But this approach also eliminates cybersecurity mistakes that might occur from the user end, accidentally exposing an e-mail address that can login, which helps a hacker who now only has to focus on a password and 2FA vector.What if the hacker obtained our exposed e-mail and sends phishing e-mails (we all know there are sophisticated AI spellchecked & grammatically correct phishing e-mails these days) and we accidentally click on a bad link?
If this hacker obtained our password, but not the username (because we never exposed it) he will try to login with the Proton e-mail alias we use for e-mail only, which he will never be able to login with, because of access management.
Then it all comes down to robustness of security practices in Proton's platform itself, which I trust are already top notch.
Please provide us with this feature and make the picture complete.
An error occurred while saving the comment Thomas Anderson commented
The things is: using e-mail by definition exposes your username to others. That same username is used to login.
Why would we expose this username externally at all?
A custom username (e.g. 20 or more random characters) being the only credential that can be used prevents this.
Thomas Anderson supported this idea ·
An error occurred while saving the comment Thomas Anderson commented
Dear Proton,
First of all thank you for all the great work and efforts, I think you are a fantastic company. For real!
The situation is, many of us may have used our protonmail e-mail addresses in the past to register at external websites (shops etc.) way before Simplelogin was introduced.
Having multiple e-mail addresses that are able to login to the master Proton account increases the attack surface, if a hacker breaches a webshop and obtains our Proton e-mail addresses.
Could we please gain the option to login with a custom username only and disable all login with protonmail.com, proton.me and pm.me e-mail addresses? So the option = only authenticate with 1 custom username.
This way we can create a long secret username that is never shared externally, e.g. in your password manager, and it increases the security because any e-mail addresses that might have been obtained in the various recent breaches are not able to login to the Protonmail account (e.g. if they try to bruteforce it.)
The ideal scenario would be:
Login with password, secret username and 2FA = never shared externally. Only credential with authorization rights to login.
Protonmail / proton.me / pm.me = rarely shared externally. Can only send mail, use Proton functions.
Simplelogin domains = freely shared externally for e-mail purposes, create new alias when compromised and disable old one.
This is not paranoid. Take a look at the news recently. The current cybersecurity climate demands us all to step up our game and remain ahead. Please implement this.
Thanks for reading this far.
-
318 votes
Thomas Anderson supported this idea ·
-
548 votes
Thomas Anderson supported this idea ·
-
4,062 votes
Thomas Anderson supported this idea ·
-
18 votes
Thomas Anderson shared this idea ·
I would love to see ProtonVPN introduce **custom DNS domain blocking**, similar Pi-hole functionality, as part of the **NetShield** feature.
**Why this is important:**
1. **Dynamic Domain Blocking:**
* Many unwanted services (ads, trackers, malicious content) constantly change their IPs, making it inefficient to block them at the firewall level.
* Domain-based blocking would allow users to block at the DNS layer, making enforcement simple and effective.
2. **Family Safety & Parental Controls:**
* A DNS-level blocklist would ensure children are **not exposed to harmful or inappropriate content** without requiring third-party tools or hardware filters.
* A simple ProtonVPN interface for managing blocklists would make ProtonVPN an all-in-one privacy and security solution.
3. **Advanced Privacy & Control:**
* Users could create **custom blacklists and whitelists**, e.g., `*.trackingdomain.com` or `*.ads`.
* Support for importing **community blocklists** (OISD, Energized Protection, etc.) would elevate privacy protection to the next level.
4. **Proton’s Strength in Privacy:**
* ProtonVPN already runs its own DNS infrastructure. Extending **NetShield** with customizable blocking is a natural step, keeping Proton ahead of competitors.
* This feature would remove the need for complex setups like Pi-hole, which many users cannot easily configure.
---
### **Suggested Features:**
* Add or remove custom domains to a block/allow list.
* Support for **wildcards (e.g., `*.example.com`)**.
* Optional **content categories** for parental controls (adult content, gambling, etc.).
* Universal across all ProtonVPN-enabled devices.