Yeah, I’m not saying aliases should be free to register. I’m saying that Proton should allow somebody to pay to register them and then keep them after their subscription ends. Precisely because there is no recurring operational cost of maintaining them after the subscription ends.
I think that makes sense, even from a business perspective. Email names are desirable and limited. There is a real form of scarcity there. So requiring payment to create them is fine.
But like, suppose you believe that aliases should be individually paid for with a fee so that you can keep them indefinitely. I would wager that fee is already covered by the cost of initiating a subscription. Since you’ve already paid for the ability to create aliases, and it costs nothing to maintain them, disabling them gains Proton nothing technically. The only thing it would do is to coerce a user to keep paying for a feature that would cost the user dearly, and that costs nothing on Proton’s side.
So yes, I would actually be perfectly fine with a one-time fee for registration. Though I would argue that fee is already covered by the first payment of a subscription.
I think it’s trivial to do, the cost to keep it active should be negligible. I’d argue that there’s cost involved with undoing it, keeping track of them, putting them back in place when a person could pay again, development of the system to do that in the first place. I’m also not so sure ‘redirect’ is the right way to describe it or if it’s better to say ‘pointer’ or ‘symlink’ that the mail system checks for when it sends and receives’ is more accurate, but since Proton hasn’t responded, how would we know without looking over the code, and for most of us that’s sort of the same thing as was stated, that he read the TOS the same way everyone reads the Google TOS.
I’m not sure if “vendor lock in" is quite the right term for what you mean. You already commited to vendor lock in when you chose to use a @protonmail address instead of bringing your own custom domain. But it’s a subscription lock in, sure.
Overall I understand your point that it’s lame for Proton to gate features without a direct cost behind a subscription. I tend to agree. Though in this case I’m not sure what the solution is. You could apply the same argument to most of the paid plan features: custom domains, unlimited labels/folders/filters, IMAP/SMTP, etc. Does removing access to those features save them money? Not exactly. (Except storage space - that has an obvious direct cost.) But at the end of the day, developing and supporting all of these features does cost money.
I like the idea of a grace period where you can still access the aliases, because it is a huge problem if you didn’t migrate any accounts from that email alias. Or maybe the aliases become receive-only in a limited kind of way.
Thanks for the great response. I accept the term “subscription lock-in” over “vendor lock-in” since that is more precise.
You bring to attention that most of the paid plan features, like amount of labels/folders/filter, IMAP/SMTP, custom domain, cost nothing on top of the free plan. It’s true, and in my perspective, losing access to those things tends to be a minor inconvenience best. You can make-do without labels, filters, IMAP, or even redirect your custom domain to another provider. But losing access to a Proton alias is catastrophic.
Take my case for example. I have established long-term use of my aliases, some of which are critical to my personal matters. I have government accounts, contact forms, all submitted with reply directions pointing to these aliases. I couldn’t possibly notify them all of a change in address in a timely manner that is guaranteed to maintain a stable communications channel with them, and I would end up missing critical correspondence because my aliases would have been disabled.
In hindsight, building my online identity with Proton aliases was a huge mistake. Because now I’m locked into their subscription, and the cost of unsubscribing is too much to bear. This is exactly why I have a grievance with Proton, because this alias treatment is commercially unnecessary and somewhat cruel.
Not sure. I’ll keep scrounging whatever money I can to continue paying for my subscription for as long as I have a need for those aliases. My grievance remains. I am locked in.
There is also the Lifetime Proton Pass + SimpleLogin deal.
One-time payment and you don’t have to worry about aliases anymore for as long as Proton Pass is still a thing. This could be helpful with your subscription anxiety if the aliases are the thing you’re worried about most. You should be able to forward emails to other emails outside of Proton as well using Proton Pass aliases.
This seems inherent to email aliases, or actually email addresses in general. Switching accounts to a new email generally has no cost, but if you will lose access to the email on an account you have to switch it out- or reset via the backup email on your account, or call tech support to verify your identity… lots of ways to get back in for important stuff, usually.
Preferring paying ($36 per year in the case of proton pass) to doing that is understandable, but it’s a decision one is making.
Also, duck aliases are unlimited and free. I don’t know why people discount them. Maybe they will cost money someday, though, as it can’t be free to run.
Kind of an aside, but related enough to avoid an off-topic mask:
So far as understand, there are two email tools referred to as ‘aliases’ under Proton’s product offerings
ProtonPass/SimpleLogin Aliasing: service furnished by SimpleLogin, whitelabeled under ProtonPass. Create unlimited alias addresses that forward to your main inbox
Native Proton aliasing: create up to 10 aliases that behave similarly, but also double as a logon for your Proton account
OP’s reported issue only applies to #2. It’s really odd that these are not handled identically, or even merged into a single aliasing service.
Case #1: When your subscription ends, aliases created in SimpleAlias will continue to receive emails but you cannot create new ones.
Case #2: When your subscription ends, Proton aliases created in Proton Mail will be disabled entirely. You cannot receive nor send emails through those aliases.
I started off in this thread vehemently opposed to the OP’s stance on this. In fact, I almost vowed not to return to the topic again.
BUT: the more I think about it and the subsequent points raised by the OP (and others) the more I think they have a point - with a good point raised here:
In which cases raises a good point with pricing and, perhaps, a suggestion that a one-off fee should be put in place to purchase Proton aliases if the person no longer wishes to subscribe to all features. Actually, I think this is a good idea.
I don’t agree that it should be without a fee because of “no recurring operational cost”. That’s just irrelevant in my opinion and the model. Although the OP does actually have another good argument with this. Imagine your vehicle contract where you pay monthly (PCP). At the end, you pay the value of what’s left (balloon payment) or return the vehicle. In that case, the vehicle will still hold value so you have to pay the extra to keep it or return it. The e-mail address, in this case, the OP suggests has been paid for already in the existing subscription. So - I do see their point. The way Proton currently structure this is akin to PCH. You pay monthly, but return the car at the end and wave bye bye. It’s been hired.
I think the Proton business model ‘is what it is’. We make that consideration at purchase. It’s interesting how the Proton aliases are handled differently to SimpleLogin, though. It’s almost like two wholly different business models clash.
On reflection, I think Proton should allow access to receiving e-mails in the same way as the SimpleLogin rather than putting a hold on them.
As such, I concede to the points raised by @banana. Thanks for changing my mind!
They are different systems, the aliases you get with protonmail operate as email addresses within protonmail, just like the main one, you can receive emails, send emails and even use them to login to proton.
For users to be able to use them after downgrading in a receive only capacity, it would require a change to the system, code would have to be written, tested etc. All so someone could use their service for free?
By contrast Simplelogin does support this use and provides better aliasing, the op would not need to resort to plus aliasing with a Simplelogin sub.
Methinks they should have chosen more carefully…
Another analogy, which I think works here, is that Proton’s alias model might even be comparable to BMW’s heated car seat subscription. In this case, BMW demanded that car owners paid them a monthly subscription of $12 to enable their car’s seat heating. This is a similar position to Proton’s, where you’re “renting” the aliases, like you’re “renting” the car seat heaters, even though they cost nothing to turn on and off because the mechanisms are already there.
Further, something I’ve since discovered: After your SimpleLogin subscription expires, you can still both send and receive emails through your existing aliases. I had thought that you could only receive, but it turns out that SimpleLogin is more generous than I thought.
The least Proton could do is match SimpleLogin’s own standard within their ecosystem.