Quite frankly, at this point I think it is pointless to keep trying to explain to you why the “solution” pushed to Westend is completely messed up.
It reminds me of that time when I tried to explain to you how incredibly problematic it was that a major breaking change was introduced into the Bounties pallet without any kind of downward communication or heads-up, and you doubled down on the idea that everything had been done by the book. Not only that, you dismissed all my recommendations for improving the workflow so that these kinds of incidents would stop happening.
So here we are again. 
This is, once again, the same underlying problem: a runtime engineer looking at everything from an ivory tower, without being willing to put themselves in the shoes of users or dApp developers. Quite frankly, someone with that attitude and that kind of tunnel vision should not be in charge of this. So yes, I think Parity leadership should seriously reconsider who is entrusted with this kind of task. And I am starting to suspect that there is a broader issue at play here.
I do not say that lightly. In fact, it would be much easier for me not to say it at all. But it would be dishonest not to say things as they are. Problems do not get fixed unless they are first acknowledged.
Look @Muharem, this is very easy to understand. I will say it again, and maybe this time it lands. I am going to lay down some hard facts. These are not matters of opinion. These are facts that can be verified by anyone. So if you disagree with any of them, then please verify them yourself, and if any of them do not hold up, prove me wrong with evidence.
These are the hard facts about the solution Parity deployed to Westend:
- Users with wallets on hardware devices like Ledger cannot authorize meta-transactions, as they can’t create the signature that it’s needed.
- Users with wallets on Nova cannot authorize meta-transactions, as they can’t create the signature that it’s needed.
- Users with wallets inside browser extension wallets such as Talisman, SubWallet, polkadot-js extension, etc. cannot authorize meta-transactions, as they can’t create the signature that it’s needed.
And the list goes on.
The reason is very simple: dApps do not (and in most cases should not) have direct access to the raw signer, the private keys or the seed-phrases, because that would be incredibly dangerous and insecure. Therefore, dApps must communicate with signers through standardized APIs, which, by the way, my team has been trying to improve for some time with proposals like this one which aim at getting our ecosystem closer to the “Extrinsic Horizon”.
The solution that is currently on Westend:
- does not define how dApps should securely interact with signers in order to create these “meta signatures”;
- does not properly consider the security implications of how dApps are supposed to create those “meta signatures”;
- does not propose an API for dApps to interact with signers and request those “meta signatures”;
- makes it impossible to properly leverage the
CheckMetadataHashextension, because one of the fields being signed is not even declared anywhere in the metadata. Ironically,CheckMetadataHashis still a required field when creating a “meta signature”.
Up to this point, these are simply facts that can be verified.
In fact, I invite you, @Muharem, to go ahead and try to authorize a meta-transaction with the account where you receive your Fellowship salary (5DMDbLHtrLhQfhvJWKRiixUeWtFTquHRvea3ccjbAueR86hS on Westend), and try to relay that authorized transaction from any other account. Perhaps then you will realize that the only way to do that is to be in direct control of the private key or seed phrase, which is obviously incredibly insecure and absolutely not something we should ever expect dApp users to do.
Now, based on all of the facts above, I think it is perfectly fair to conclude that this solution is, in practical terms, completely useless and insecure.
It is also my opinion that there was no need to create such a convoluted solution in the first place, and that the signature of a normal v4 transaction would have sufficed. But that is a discussion for another post, and for a proper RFC that I plan to submit to the Polkadot Fellowship, proposing a more robust, secure, and useful alternative to the atrocity that has been deployed to Westend.
And yes, I do think it is incredibly audacious for something this sensitive to be pushed as an ad hoc solution without proper Fellowship RFC discussion and approval. I hope we learn something from this, although I am not especially optimistic.
I am still shocked that someone could share that code and think: “yes, this is good stuff.”
It should be self-evident, just by reading the code, that the solution is fundamentally wrong. I mean, the mere fact that it only works when the dApp has direct access to the raw signer is already a massive red flag. And that is before even getting into the fact that a normal dApp developer should not be touching low-level concerns like manually assembling signed-extension values, especially without deriving them from metadata.
So no, sorry, but no: what was tested is obviously insecure and unrealistic.
I mean… how is that even relevant?
That is a completely irrelevant implementation detail for the criticism I am making here.
For starters:
- It does not address the fact that the method for creating these “meta signatures” is insecure.
- It would still be insecure even if we were already fully ready for “Extrinsic Horizon” and Extrinsic v5.
- The reality is that we are not yet ready for “Extrinsic Horizon”.
Once we are actually there, and once Extrinsic v5 becomes the real transaction model in practice, then we can start talking about all the fancy things that new reality enables. But as of today, it is not even possible to create general transactions using Extrinsic v5 in the ecosystem as it actually exists.
In other words: we are not there yet.
Even the example that @cirko33 shared still uses an Extrinsic v4 transaction on the relayer side to broadcast the meta-transaction. So I genuinely do not understand why we are getting ahead of ourselves here.
We could have had a solution that works properly with the reality we have today, and then, once “Extrinsic Horizon” and Extrinsic v5 become real, we could evolve it using the new constructs that future reality enables. Instead, what we got is this insecure and unrealistic in-between solution that is neither here nor there, and ends up being the worst of both worlds.
PS: I previously said that it is not possible to create a “meta signature” using browser extensions. For all realistic purposes, that is still accurate. There is a hacky way to exploit a vulnerability in PJS-based extensions in combination with the legacy signPayload API that could make that possible, although I strongly doubt that any Parity engineer is even remotely aware of that. I am not going to describe it here, because that would amount to abusing an existing vulnerability that we are actively trying to remove with the new createTransaction interface. So if you happen to know about that, please keep it to yourself, because that should absolutely not be treated as a valid option.