Skip to content

Privacy Advocate

My feedback

8 results found

  1. 188 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    15 comments  ·  Lumo » New feature  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
  2. 391 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    23 comments  ·  Lumo » New feature  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
  3. 23 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
  4. 643 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Privacy Advocate commented  · 

    +1

    This would be a huge quality-of-life improvement. Using ProtonVPN these days means running into endless CAPTCHAs, blocked logins, and sites flagging shared IP ranges as “suspicious.” It’s frustrating because the very privacy that draws us to Proton also makes everyday browsing painful. A reasonably priced dedicated IP for personal plans would solve that without compromising Proton’s values

    Privacy Advocate supported this idea  · 
  5. 352 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
  6. 55 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
  7. 58 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Privacy Advocate commented  · 

    I already wrote a similar response on the iOS thread, and I'm adding roughly the same comment here for the mac thread.

    Privacy and Security Problems with Plaintext DNS on macOS

    DNS visibility beyond the VPN tunnel
    Even though ProtonVPN encrypts traffic between the device and the VPN server, the DNS queries from the exit server to the resolver remain unencrypted. This allows the exit server’s ISP or any intermediate network to see the domains users visit.

    Exposure to interception and tampering
    Plaintext DNS can be intercepted or modified. Without encryption, a malicious or compromised network could redirect traffic or block specific domains.

    Loss of end-to-end privacy
    DNS queries reveal browsing activity. Without encryption between the exit node and the resolver, ProtonVPN users still leak metadata to third parties, which undermines the purpose of using a privacy-first VPN.

    Inconsistency with Proton’s “Privacy by Default” principle
    Proton promotes complete user privacy and minimal trust in intermediaries. However, unencrypted DNS between the exit server and resolver contradicts that mission, especially for users who rely on privacy-centric resolvers like NextDNS or self-hosted DoH services.

    Specific Feature Requests for ProtonVPN macOS

    Support DNS-over-HTTPS (DoH, RFC 8484)
    Allow users to specify custom encrypted DNS resolvers via DoH endpoints, ensuring DNS queries remain private beyond the VPN tunnel.

    Support DNS-over-QUIC (DoQ, RFC 9250)
    Add support for DoQ to provide faster, connectionless, and fully encrypted DNS resolution.

    Support IPv4 and IPv6
    Enable both IPv4 and IPv6 addresses or hostnames for custom encrypted resolvers instead of IPv4-only input.

    Maintain end-to-end encryption
    Ensure DNS queries are encrypted from the user’s device through the VPN tunnel and continue encrypted all the way to the resolver.

    Add transparency for DNS status and fallbacks
    Inform users when ProtonVPN is using encrypted DNS and warn if a fallback to plaintext occurs, so users understand their privacy posture in real time.

    Why This Matters for ProtonVPN macOS Users

    Eliminates plaintext DNS exposure and prevents metadata leaks.

    Protects against DNS interception, manipulation, and censorship.

    Aligns ProtonVPN’s macOS client with Proton’s broader privacy-by-design philosophy.

    Makes the “Custom DNS” feature genuinely privacy-enhancing for advanced users.

    Supporting encrypted DNS (DoH and DoQ) would close one of the few remaining privacy gaps in ProtonVPN’s macOS app and strengthen Proton’s claim to full end-to-end protection for its users.

    Privacy Advocate supported this idea  · 
  8. 81 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Privacy Advocate supported this idea  · 
    An error occurred while saving the comment
    Privacy Advocate commented  · 

    I’m glad ProtonVPN iOS now supports custom DNS (as mentioned in the original post), but the fact it currently only supports plaintext UDP DNS introduces several real risks. Below are what I see as the drawbacks, followed by clear feature-requests that I hope Proton will prioritize.

    Negative Consequences of Not Supporting Encrypted DNS (DoH / DoQ)

    Exit-node exposure
    DNS queries from Proton’s VPN server to the resolver remain unencrypted. That means the VPN host’s ISP or any network between Proton’s server and the DNS resolver can see which domains users are querying.

    Vulnerability to DNS manipulation or hijacking
    Plaintext DNS is susceptible to MitM attacks: bad actors could intercept or modify DNS responses on that hop, redirecting users to malicious sites or injecting tracking.

    Metadata leakage & profiling
    Even when content is encrypted and tunneled, unencrypted DNS reveals browsing patterns. Observers could see which domains you visited (or at least requested), undermining user privacy.

    Susceptibility to DNS-based attacks
    Without integrity checks or encryption, DNS cache poisoning or spoofed responses become easier for adversaries on that plaintext path.

    Trust gap
    Users choosing Proton expect “privacy by default.” The absence of end-to-end encrypted DNS for custom resolvers creates a discrepancy between Proton’s privacy marketing and its technical exposure.

    Clear & Specific Asks (in response to “Add DoH and DNS-over-QUIC Support for Custom DNS on iOS”)

    Support DNS-over-HTTPS (DoH, RFC 8484)
    Allow users to enter a DoH endpoint (URL or IP + path) as their custom DNS, with DNS-over-HTTPS traffic tunneled securely.

    Support DNS-over-QUIC (DoQ, RFC 9250)
    As a next-generation encrypted DNS protocol optimized for performance, DoQ support ensures minimal latency and full confidentiality.

    Allow mixed IPv4 / IPv6
    Accept both IPv4 and IPv6 custom DNS addresses (or DoH/DoQ endpoints), without forcing users to pick IPv4 only.

    Tunneled + end-to-end encrypted DNS
    Ensure that when DoH/DoQ is selected, DNS queries are sent through the VPN tunnel and remain encrypted all the way to the resolver.

    Backward compatibility / fallback
    If a custom encrypted resolver fails, Proton should fall back to its default DNS (or prompt the user), while warning that plaintext DNS is less secure.

    Expose diagnostics / logs
    In debug mode (or with opt-in), show whether DNS is currently encrypted, which resolver is being used, and whether any fallback to plaintext occurred.

    By listing these pain points and concrete asks, I hope more Proton users will find this thread, vote it up, and help push this feature up the roadmap. If Proton implements this, it makes the “custom DNS” feature genuinely privacy-first.

Feedback and Knowledge Base