[#26583] - License Key implementation in Joomla 4 has a confusing end user UX
- Closed
- 19 Oct 2019
- Medium
- Build: staging
- # 26583
Please test Pull Request gh-26744 which fixes these issues
What needs to be fixed
The new License Key feature for extensions is interesting but its UX is very confusing.
-
Discoverability. Finding where to go to enter a License Key is unlikely for the end user, even if they are experienced administrators. From the front page you have to click on System (arbitrary name not linked to your task) where you see a cognitively overloading page. You then need to find Update Sites (a name only tangentially related to your task). Then you need to know that you need to click on an update site and, in fact, which update site to click. This action is unlikely to be taken by a user, making discovery of this feature improbable.
-
Applicability. No matter which update site you click you get a License Key field. This happens on paid extensions which support this feature (and need the field), paid extensions which do not support this feature, free extensions and even Joomla! Core itself.
Why this should be fixed
-
Discoverability. If the users don't know how to access this feature it's unlikely they will be able to use it when they purchase and install a paid extension. It's also unlikely they will know which update site to use, especially with extension that offer more than one update site (e.g. a collection and an extension-specific update site). They are also unlikely to read a relatively long and convoluted explanation of where to go to enter their license key. This will unnecessarily increase the support load of developers.
-
Applicability. When you see a License Key on free extensions and Joomla itself as an inexperienced to moderately experienced users you conclude that all updates require payment. This will likely drive you to a competitor CMS where everything is allegedly free (selling your soul and your personal information notwithstanding). If you see this for a commercial extension which does not support this feature – because the developer still needs to support Joomla 3, for example – is misleading for the user. They might end up entering their license key in the wrong place and get frustrated that their updates do not work. This will likely and unnecessarily increase the support load of developers.
How would you fix it
Fixing these issues hinges on the necessity of providing a dlid element in the manifest XML to have user enable this feature on extension update. Therefore, we directly know which extensions (therefore, which update sites) can use the License Key feature. From there, both issues can be fixed. Finding which update sites support the License Key feature should be a method in a helper class for easy access in core and 3PD code. This can also help developers migrate their existing license keys from whatever storage system they use to Joomla's centralized license key management.
First, the Update Sites view needs to show a note underneath Update Site records which support the License Key feature. The note can either say that a License Key is present or that one is required to be entered. This helps the user visually check the completeness of their License Keys and aids discoverability. It is also a good idea being able to filter by which update sites require a License Key or not. This would help site integrators print out a report for clients to show them which paid extensions are installed on their site, a major selling point for Joomla.
We need a quick icon plugin to fix discoverability. It can ask the helper for a list of update sites supporting the License Key feature and check how many of these do NOT have a License Key entered. It can then display a warning in its icon that X extensions require a License Key to update. This must link to the Update Sites view, filtered for the update site IDs that need a License Key.
Furthermore, the Update page should do the same. If there are extensions supporting the License Key but whose License Key is empty a warning should be issued, linking to the same filtered view.
On top of that, updating a paid extension which lacks a License Key should NOT proceed, instead throwing a warning that a License Key needs to be entered with the text linking to the edit page of the corresponding Update Site.
Finally, when editing an Update Site we should remove the License Key feature if the Update Site does not support the License Key feature.
Side Effects expected
I expect that this will make users happier by making them NOT having to think about license management :)
This is not an arbitrary conclusion. In 2015 we did user testing for our software and found out that almost all users interviewed had a problem discovering where to enter the license (even though it was in the Options page of each component). We implementing prompting them to enter the license key and drastically decreased the support for updates from dozens of tickets per month to one ticket every two to three months.
Please assign this to me
I plan on working on it for Pizza, Bugs and Fun 2019. Please assign this issue to me.
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Labels |
Added:
?
|
||
@ka3media This is a fair point I have of course given a lot of thought about. However, the sub-key management at the developer's side is (a big part of) the best realistic solution. I put headings where appropriate in the long reply so you can more easily follow my reasoning.
Hashing at the end user's site is a no-go
Download keys need to be used "in the clear" when making a request to the developer's server, to identify the client and determine (at the developer's side) whether the download should be allowed or not. This precludes using a hashing function since, by its very definition, it is a one-way function. That is to say, the hash cannot be converted back to the key.
Hashing at the developer's site is a no-go
What if the developers site accepted the hash instead of the key, you might ask. Well, in this case we just do a whole lot about nothing at all. A malicious user could copy the hash to their site and receive updates. Even if there is no UI to do that they could do a simple DB query.
Encryption at the end user's site (Joomla) is a no-go
If the encryption key is stored at the end user's site then, by definition, a rogue Super User could use it to decrypt the encrypted download key and have it in the clear, just like Joomla would need to do when trying to download the update. So, no go.
If the encryption key is stored at the developer's side you are back to square one: whatever you enter in Joomla will be valid on any site.
Moreover, Joomla needs to provide a UI for the user to enter, view and change the download key. So even if it's not shown in the Update Sites list it will still be visible when editing an update site.
Finally, Joomla would anyway display the failed download URL, including the key, in case of a download error.
Encryption at the developer's site is a no-go
This leads us back to mitigating the risk of key reuse on the developer's side. Ideally, you'd need to create one download key per domain name supported. However, this has two drawbacks:
- Joomla does not send an HTTP Referer when downloading the update, meaning you don't know which site you are downloading the update for.
- The only way you can legally distribute an extension for Joomla is licensing it under GPLv2 or any later version (including GPLv3) which precludes preventing the use of your software on a site dependent on a download key. Restriction of using your software would invalidate the license. Note, however, that restricting the use of any services your provide through your infrastructure / company is still legal.
You can solve this with sub-keys and tying services into your software
Here is a practical solution I've implemented
- Sub-keys (Add-on Download IDs in the case of my software). I ask my clients to create one Add-on Download ID per site or client of their own and revoke them when they cut ties with that client / site or when they have a suspicion that the keys are being abused. Failure to do so can lead to their subscription being terminated without a refund. People generally comply with this and I've found that key management is trivial compared to any other technical solution.
- Tie popular features to a service on my servers where it makes sense. For example, transferring your backups to a remote storage provider which uses OAuth2 (e.g. Dropbox, Google Drive, OneDrive etc) requires an OAuth2 mediator endpoint with my application keys on my servers. That's a service I provide and it requires a valid download key. If I detect abuse, see above (which means that now your backups don't store remotely). This makes people seek compliance with the sub-key policy.
In the end of the day it's about giving a reason to your clients to self-police their behavior and penalize aberrations to your policy.
Why it's not as important as you think
It is worth noting that only Super Users are able to see the Update Sites page and the download keys. Therefore the whole issue is a matter of trust. If you don't trust your client to keep the download keys safe from improper access you can and should penalize them, e.g. by disabling their subscription without a refund. So with normal keys the problem has a known solution and it's the same as dealing with warez. It's not a widespread problem because most people are decent and understand that if the screw over a developer then the developer will screw over them tenfold or will go out of business, in which case they're totally screwed as the software they depend on is dead. Bad apples are actually rare and they're people who wouldn't be paying you anyway.
In the other use case you mentioned (volume pricing), the problem is not critical for you the developer but for your client. If they use their download key in an unsafe environment their limited resource (e.g. picture optimization credits) are depleted by improper use. If they come back to you the developer you can tell them who used the service, when and where from. It's then the client's problem to seek redress from the unauthorized parties.
Let's not reinvent the wheel
I would like to note that this conundrum is not unique to Joomla or even new. It has existed before I was even born and I'm almost 40 :) As long as you have an alphanumeric key to unlock software which is not tied to a specific installation you do run the risk of someone abusing it. The amount of abuse you will witness is too small to warrant any further thought. As I said, most users really do understand that they only way to have reliable software is to pay an affordable price. Only absolute morons and sociopaths will actively try to screw you over by subverting download keys. The good news is that this kind of scum is rare (but I do understand that it's also memorable, hence this discussion).
Moreover, in the case of FOSS we can't really enforce keys tied to installations without invalidating the license of our software, shooting ourselves in the feet.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-10-19 19:00:50 |
| Closed_By | ⇒ | Quy |
Please test PR #26744
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26583.
richard67
- | Labels |
Added:
No Code Attached Yet
Removed: ? ? |
||
I would like to add a suggestion: As far as I can see the keys will be shown and stored in the clear.
From my practical experience there are several situations where you use your own key for client pages or nonsalaried work (for example for a club). And you are not always able to hide it using user access.
This will be a problem with normal keys, but a critical problem if those keys are related to
volume-based billing, e.g picture optimizing.
The best way would be a sub-key management on developer side, but this is unrealistic... It'll be the other way around. With the key feature more devs of small extensions will integrate a key feature with a single key. This is a quick thing, but a sub key management system is a different number.
Is there a way to hash the keys or at least hide them in the backend in order to make access more difficult?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/26583.