Cosmic.link ~ Transactions over URL

Summary

Cosmic.link is the next-gen solution for signing Stellar transactions from various applications without granting them control over your account.

Cosmic.link is user-friendly, open-source, vendor-neutral, community-designed, and production-ready.

Live Example

Goals

• Provide a user-friendly yet secure way to explore the Stellar ecosystem.
• Provide a standardized solution for passing transaction requests between applications and wallets.
• Provide useful open-source libraries to the community.
• Raise awareness around issues related to asymmetric cryptography & the cryptocurrency security model.
• More specifically, raise awareness around the one golden rule in crypto: "Never share your private key!".

At that time, those goals have been met − except of course the part about informing the community which is a never-ending task. Most of the work is currently focused on continuous improvement, communication, and partnerships.

Description

CosmicLink is a project made of several components: an open protocol, a web front-end and several open-source libraries.

Please keep in mind that the front-end (Cosmic.link) is only the emerged part of the iceberg.

What is Cosmic.link?

Cosmic.link is a solution for signing Stellar transactions from various applications without granting them control over your account.

Each CosmicLink contains a request that is displayed on your screen. Then, you can pass it to your wallet where the transaction can be double-checked & safely signed.

Your secret key never leaves your wallet, as it is meant to be.

Why Cosmic.link?

Before Cosmic.link, Stellar applications had two ways to have you sign transactions:

• Have you create and fund a new Stellar account, which they would control.
• Ask for your secret key.

Having as many accounts as applications is painful, and sharing secret keys is dangerous. Cosmic.link solved it all thanks to an innovative solution: transaction requests.

How does Cosmic.link work?

Transaction requests get encoded into what is called a query string for the purpose of passing them into normal web links:

?type=payment&destination=tips*cosmic.link&amount=20

Transaction requests can then get passed to any compatible service by using their address:

https://cosmic.link/${tx_request}
${handler}${tx_request}

When applications generate those links, they choose which handler to use (it doesn't have to be Cosmic.link). Here's, for example, the request on the cosmic-lib demo interface.

In some cases, it is possible to pass the request directly to the users' wallets. For example, here's the same request pointed at Stellar Authenticator. (You can view it by clicking Guest Mode)

In other cases, wallets don't use the same format for transaction requests, and conversion has to happen. Cosmic.link does it under the hood.

Which Services are Compatible?

Thanks to its open design, CosmicLinks can be implemented in any software, independently from any organization or service. There's a growing list of compatible services, some of them being well-known to the community:

Applications:

• Equilibre.io: Portfolio balancer.
• Cgig.app: Stellar marketplace.
• StellarPay.com: Shopify payment plugin.
• Lumenthropy.com: Donations to NGO.
• PublicNode.org: Community full nodes.
• r/stellar Photons: Reddit community points for Stellar.
• NiceTrade.co: Stellar Decentralized Exchange interface.

Wallets:

• Ledger Wallet
• Trezor
• Stellar Authenticator
• Keybase
• Lobstr*
• StellarTerm*
• Stellar Laboratory (dev tool)

*: For now, those wallets only support a subset of possible transactions.

Libraries

Cosmic.plus philosophy is to provide the community with as many reusable components as possible. Some of them are among the most downloaded Stellar libraries, which is greatly motivating!

The following libraries have been developed in the context of the CosmicLink project:

cosmic-lib

This is the JavaScript implementation of CosmicLinks. It features helpers to create transaction requests:

const { CosmicLink } = require("cosmic-lib")

// Create a request.
const txRequest = new CosmicLink({
  network: "test",
  memo: "Hello, World!",
  maxTime: "+5"
}).addOperation("payment", {
  destination: "tips*cosmic.plus",
  amount: 20
})

// Open the signing interface.
txRequest.open()

It also provides helpers for wallets to receive and sign transactions:

const { CosmicLink } = require("cosmic-lib")

// Configuration.
const network = "public"
const source = keypair.publicKey()

// Parse, sign & send the transaction.
const txRequest = new CosmicLink(location.search)
await txRequest.lock({ network, source })
txRequest.sign(keypair)
const response = await txRequest.send()

Open the documentation

@cosmic-plus/ledger-wallet, @cosmic-plus/trezor-wallet

Popular hardware wallets support, as simple as it can be:

const ledgerWallet = require("@cosmic-plus/ledger-wallet")

// Connect with the device.
await ledgerWallet.connect()

// Get the public key.
const pubkey = ledgerWallet.publicKey

// Sign a transaction.
await ledgerWallet.sign(transaction)

Open the documentation

@cosmic-plus/tx-result

A convenient helper that tells you if a transaction has been validated, and if not, what went wrong:

const TxResult = require("@cosmic-plus/tx-result")
const result = new TxResult(horizonTxResponse)
// {
//  validated: false,
//  title: "The transaction has been rejected",
//  errors: [
//    "Operation 1: The destination account doesn't exist."
//  ]
// }

Open the documentation

Other Contributions

The very nature of CosmicLink is to make connections with other developers and open-source projects.

As the Cosmic.link maintainer, I'm constantly checking over projects such as stellar-sdk, @ledgerhq and trezor-connect.

I'm writing bug reports and pull requests to them when necessary. Lately, this led to major improvements in Trezor wallet support. At that time, I'm working on getting the new Stellar operations into Ledger & Trezor firmware (manageBuyOffer, pathPaymentStrictSend). #Ledger #Trezor

I'm also cooperating with community projects that are looking into using Cosmic.link. For example, I've recently worked with StellarAuth, StellarPay, Lumenthropy, PublicNode, and r/stellar community.

Future

The development of CosmicLink is centric to Cosmic.plus (hence the name). It's been continuously developed since two years, and there's more ahead. Here are the ongoing developments:

• Publish comprehensive, not-so-technical documentation.
• Publish explanations about how to host an alternative CosmicLink relay.
• Publish a library that makes high-level integration even easier.
• Publish a TxRequest library that doesn't depend on StellarSdk (450kb).
• Design a solution for applications to acquire user publicKey/wallet.
• Provide helpers for short-circuiting Cosmic.link (direct application-wallet communication).

Links

Application: Cosmic.link

Organization: Cosmic.plus | @GitHub | @NPM | @CodePen

Weekly updates: Reddit | Twitter

Talk: Keybase | Telegram

Your vote matters

Cosmic.link is an ambitious open-source project. Because it doesn't receive direct funding, community support is critical in financing its continuous development. Thank you!

OrbitLens

Part of your message answers the issue I've raised about StellarTerm and doesn't belong here. Please note that I never said that StellarTerm should use Cosmic.Link. I've shown that it features a broken security model: there are several ways to fix it & I've not advised for one in particular (although I made my point that StellarTerm is not using delegated signing as intended).

Please move the StellarTerm-specific inputs into the right place, I don't want to answer them here as thread-mixing is confusing. I can answer on the copy/pasting here, though.

Edited

OrbitLens Yes, using the clipboard for sensitive data is not recommended because it somewhat simplifies the attack, and that's cool that you are raising awareness. But in your comment, you refer to the far-fetched arguments. [...]. The webcam access is sandboxed in the browser and requires explicit access confirmation (just like the Clipboard API), but if the attacker has root access to your computer, nothing will help you. So it all comes to the client environment security in the end.

However, instead of admitting that you exaggerated the copy-pasting problem (intentionally omitting the attack prerequisites) to support your point, you are throwing pretty aggressive comments.

I believe my description of the issue is in tune with reality, and I think you should have taken the time to understand it before throwing uninformed accusations at me.

I never said that this attack had anything to do with the browser or Chrome in particular.

The clipboard is a system-wide interface, and any data the user copy in it is available to read for any process running on the machine. In some cases, it is also stored for long periods. You don't need root access to read the clipboard: this not an attack but an intended functionality.

For example, on Android (what 20_30% of people use), any app can read the clipboard but none of them can access the compartmented encrypted storage where apps keep secret keys safe.

It is easy to install a malicious app on Android, or malware on most system, but it is considerably harder to break storage compartment - precisely because you need to be root for the second one.

All attacks other than peeking at clipboards also request vendor-specific logic once root is acquired. Consequently, those attacks are harder to perform, easier to mitigate (because it involves sequences of code that is easier to flag as malicious) and less likely to hit (which means less likely to happen, because less profitable).

In other words, storing a private key plain text and copy/pasting it is orders of magnitude less secure than storing it in an encrypted file as well as leveraging OS security features.

I think this is obvious: else nobody would bother implementing those security measures in the first place.

This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.

And going even further, you directly accused StellarTerm team of deliberately weakening the application security or intentionally misleading the users (not quite clear what you ment here) to gain some mysterious "profits":

Absolutely, as part of their SCF#3 marketing StellarTerm promoted secret key copy/pasting as a fancy sign-in method. Now, there's a gap between using this method - which is insecure - and actively promoting it as part of a vote gathering effort - which is factually misleading people.

Misleading applies to situations where someone uses his influence in a way that negatively affects people who trust him. That's definitely what happened here.

Again citing your words, "Dude, that's off-limits." Clearly, you started all personal trolly debate on the unrelated matter.

I maintain that misleading people on security part of a profit-seeking effort is off-limits. There's nothing trolly or personal there.

And btw, bullying someone for exposing & documenting a security issue, and for informing users about crypto good practices, is not much better.

OrbitLens Realistically, you are the only one providing the more or less viable solution for delegated signing with the support of third-party wallets at the moment. It supposed to be stable or at least in production for like a year. Everyone else have only working prototypes at best. So when you started criticizing current StellarTerm key management strategy, and urging them to replace it with delegated signing, which service do you have in mind here? You are happened to be the author of the delegated signer, and the comment is yours, so I assumed that by "we implemented delegated signing" you mean CosmicLink. What else can it be?

I think you're mixing things a bit, and I invite you to read my feedback again.

1. I criticized the way StellarTerm uses SEP-0007. Delegated signing is meant to secure the ecosystem by having apps emit transaction requests, but StellarTerm does it the wrong way by offering people to sign SEP-0007 transactions by inputting their secret, which is self-defeating.

2. I criticized the fact that StellarTerm actively promoted this insecure practice.

My motivation for point 1 was that Gleb regularly claimed support for SEP-0007/delegated signing in SCF context while he implemented about 10% of it so far. I think that's unfair and given how wrongly it is done in StellarTerm, I felt like pointing it.

At no point, I said that StellarTerm had to implement delegated signing, and if I had intended to have them support CosmicLink I'd have used a subtler method. I feel fine with whatever makes user's funds secure.

As I already said in my article, keystores are also an option, and we know that other ways are possible as well, although I'd advise against gathering thousands of keypairs together on a centralized server.

I'll go through UX questions. Remember that I never claimed that Cosmic.link is perfect, and in fact, there are many improvements on the way. Yet, I think that it offers a satisfying yet secure experience to its 1.5k regular users, and I invite you to experience it by yourself.

Some improvements on my roadmap:

MisterTicot

• Publish a TxRequest library that doesn't depend on StellarSdk (450kb).
• Design a solution for applications to acquire user publicKey/wallet.
• Provide helpers for short-circuiting Cosmic.link (direct application-wallet communication).

OrbitLens

1. Each action takes a lot of time and requires multiple confirmations. Case: a user wants to remove two active DEX offers and place a new one. Each time she has to wait for the redirect to CosmicLink website, confirm the transaction, wait for the redirect to, say, a SEP-0007 wallet, confirm the transaction again (this a required step, I guess there is no need to explain why this is important), provide her credentials, press "submit", and wait for the redirect back to StellarTerm. Repeat this 3 times yourself and you will understand why this is frustrating.

1. It is possible to shortcut Cosmic.link and go directly to the wallet. As mentioned, I'll release helpers to make this easier to implement. Nowadays, Cosmic.link offers an automatic redirection option that shortcuts its interface as well (although technically it goes through Cosmic.link).
2. Now, the issue of having to sign each transaction also happens with hardware wallets, which is the very UX delegated signing is meant to mimic. An option here is to pack actions together and to offer to sign everything at once.

2. Single-page applications (like StellarTerm, StellarX, Lobstr, and many others) rely on the client-side state. When a redirect occurs, the application is unloaded and loses the entire current state. So it either needs to encode and transfer the state in the callback URL, or save it temporarily somewhere, for example, in the browser local storage. [...]

Equilibre.io is a single-page application that uses delegated signing, NiceTrade.co is another one. None of those suffers the drawback you described here as they don't use redirection but iframes or popups. Something you can do, when apps have no critical information anymore, is to store client-side state into LocalStorage which keeps data over sessions (the aforementioned apps do so).

There is no way to retrieve the user's public key.
The only way to implement this with your current logic is to ask a user to sign, say, an empty transaction. We won't ask a user to input the public key directly, right? Because asking for a public key and then using a delegated signing to confirm the transactions is the worst UX I can imagine. [...]

In Equilibre.io, I simply ask for pubkey/federated. This is similar to what many wallets implement as read-only accounts, and transaction signing is required only for writing. One nice trick is that we can standardize the pubkey/address field id attribute, and leverage browser auto-filling to get a cheap yet efficient read-only login solution (sign in with pubkey). The browser will propose your addresses across websites the same way it does with emails.

NiceTrade.co proposes either login with public key (works as described) or with sep10, in which case delegated signing callback property is leveraged (available in both sep7 and CosmicLink). We discussed the fact that sep10 transactions don't make their purpose very clear (a network: Won't be validated could be clearer). This is mostly a sep10-related problem.

In any case, those 2 options have room for improvement. Option 1 could be improved by CosmicLink passing pubkeys to the application providing user grant permission, and option 2 could be improved by adding specific UX constraints to sep10 (a specific way to display sep10 tx to users).

4. Poor onboarding flow for new users.
   Case: a new user decided to explore StellarTerm and see how it works. When she clicks the login button, the browser redirects her to the CosmicLink website, which is literally hostile to newcomers. What transaction should she sign if she doesn't have any Stellar account in the first place? What's the signing method, and which one she supposed to choose, "Stellar Laboratory" or "Copy/Paste XDR"? What does the "Register as web+stellar links handler (SEP-0007)" means? What's an "Automatic redirection"? [...]

This pertains to the Cosmic.link UI itself rather than delegated signing. I'm in the process of upgrading the client-side framework I used for Equilibre.io and to port Cosmic.link & StellarAuthenticator on top of it. Then, I'll improve the Cosmic.link UI.

It is also possible to develop an alternative UI on top of cosmic-lib and other Cosmic.plus libraries, which provides most of the Cosmic.link logic at that point.

How do you suppose to support mobile platforms? Maybe this is covered somewhere, but I didn't find. Opening a CosmicLink URL from the app is pretty straightforward, but what about returning the response back to the caller application once the transaction is signed? [...]

That's what the callback parameter is for. There is also the option of listening for transaction submission from the parent frame, which is something I'd like to implement but designing it is somewhat of a puzzle given the number of configurations involved. We already found out some cases will have to be left unsupported (mobile signing + callback that don't submit = impossible to catch submission from parent frame).

OrbitLens [...] but this is not essential because copy-pasting secret at least once is potentially almost as dangerous as using it all the time. The fact is that copy-pasting is ubiquitous and it can't be easily addressed right now because the existing ecosystem tools are not mature enough.

Many applications have addressed it already in many ways, and I'd advise against using "it's difficult" as an excuse for not implementing solid security. In fact, any excuse that goes toward lesser security should be looked at as suspicious, as in most cases it doesn't hold the test of healthy reasoning.

I can start a new thread if you like, as discussing theoretical problems of the whole ecosystem in the StellarTerm thread doesn't seem right to me, especially after that heated dispute. Moreover, can we please just turn this page and continue debating on the things that really matter for the future? I'm genuinely interested in your opinion about improving delegated signer flow, and it would be cool to hear your thoughts on the highlighted problems as I'm engaged in this matter myself.

Then let's do just that!

Edit:

• Add NiceTrade.co
• Keybase Wallet is now fully compatible. Hooray!!

OrbitLens

Your repeated gaslighting attempts hardly hide your inability to make sense at the technical level. You should take care: people notice.

I didn't mean to stir it up again, but it bothers me to leave so many misstatements & petty attacks unanswered in my own thread, so here we go:

Message 1:

[About Equilibre.io] They will still need to provide credentials and confirm the signing request in the target wallet, [...].

False Equilibre.io signing interface doesn't ask for user public keys.

Users have to wait for at least 3 browser redirects and provide credentials, so each operation takes 10-20 seconds instead of one click as before. That's maybe ok for Equilibre [...]

False There's no configuration under which Equilibre.io requires 3 browser redirections + providing credential for tx signing.

As for all other questions... Looks like you completely missed some of my points, as your answers do not address most of them at all.

Unbacked accusation That sentence is dropped as it. We'll never know which point wasn't answered, and I believe there wasn't any.

And I checked NiceTrade.co. I must say that it's the worst login form I have ever seen.

Insulting Dexter is the first dev to use sep10 in production and deserves kudos for that. The first step is rarely perfect.

Forcing a user to save a public key separately (where? in text file?) and copy-pasting it (following your logic, that's a big no-no, as it may break user's privacy by associating a person/device with a Stellar account)

False There's no such thing as forcing users to save public key - federated addresses are supported in the software I mentioned. There's no such thing as copying a pubkeys from text files - most wallets provide a copy-on-click feature.

Reinterpretation I never said that public key should not be copied.

Poor technical understanding There's a difference between public and private keys. Public keys are meant to be shared and can safely be copy/pasted. The idea that an attacker would listen to the clipboard for public keys to break one's privacy is kind of ridiculous at that point.

[about NiceTrade.co] each time when a user needs to log in,

Disinformation it sounds like it happens a lot, while NiceTrade sessions are remembered. You need to log in once per machine, just like Keybase.

Even requesting to sign an empty transaction is better than that, at least it's possible to authenticate a user and retrieve a pubkey in one go.

Poor technical understanding Doing it that way, it wouldn't be possible to authenticate the origin of the login request... In other words, it wouldn't work.

About my statement that copy-pasting is ubiquitous:

[MisterTicot] Many applications have addressed it already in many ways

Nope. I haven't seen any other option across the entire Stellar ecosystem

Denial Here are solutions that have been used to prevent secret sharing, some of them since years:

• Custodial wallet (PapayaBot)
• Pubkey scanning (Stargazer)
• Payment request (StellarKey, Stargazer)
• Keystore (StellarPort)
• Key Encryption + local storage (Stellar Authenticator)
• Key encryption + distant storage (StellarX)
• XDR copy/pasting (StellarLaboratory, Stellar Authenticator)
• Sep7 (Keybase)
• Sep10 (NiceTrade)
• SatoshiPay (Lumenthropy)
• Cosmic.link (PublicNode)
• Payment plugins (StellarPay, SWPlug)

If you need to submit transactions on behalf of an existing account, you need to either request a secret key (at least once) or use delegated signing.

False Submitting transactions on the behalf of the user is not the same as signing transactions on the behalf of the user. The first happens part of multi-signature coordination and doesn't require secret key nor delegated signing. (e.g: StellarGuard)

Given current progress, mature delegated signing tools for Stellar Network will be ready in a year or so (hopefully)

Denial Mature delegated signing tools are ready right now, and Cosmic.link is production-ready since a year and a half. I'll add that no other cryptocurrency project has such a generic tool available yet.

The browser Clipboard API [...] was just an illustrative example for one of a few attack vectors exploiting the potential vulnerability you mentioned without breaking the sandbox

Technically false The browser clipboard API is precisely not an attack vector because it is sandboxed. There are workarounds but at that point, this renders the attack unprofitable.

The Android example, of course, demonstrates much stronger case than, say, Windows XP

Denial Using "of course" about something you couldn't figure out by yourself.

careless Linux user running all processes under the root privileges (btw, why we are overlooking them?)

Because nobody does that.

For the particular case you described, I can agree that "it is orders of magnitude less secure", as you wrote.

Denial Storing secrets in plain text and copy/pasting them around is orders of magnitude less secure in all possible cases.

However, my main point here is that a compromised system (with the malware code in userspace) can't be viewed as secure even with all the delegated signing in place.

Denial In your previous comment, you defined a "compromised system" as one where root access was gained. Now, you redefine it to avoid admitting your point was wrong.

Technical false A malware is typically under the same security restrictions as other software and cannot perform actions that require permissions without asking the user first. Under Android/iOs, only copy/pasting is weak against malware without permission, and most of the alternative ways I mentioned are resistant against malware with permissions.

(Namely: custodial wallet, pubkey scanning, payment request, key encryption + local storage, XDR copy/pasting, sep10, SatoshiPay, Cosmic.link, Payment plugins are resistant. Keystore, key encryption + distant storage and sep7 can be broken under certain specific conditions)

Android Autofill framework and Accessibility API (previously it was used by password managers like LastPass to interact with text input of third-party apps) make it much simpler to steal login/password credentials

False Accessibility API requires permission and both can be broken only when devs leave a hole. Peeking at clipboard is easier, works against all app and is less likely to get spotted as malicious.

And if users are naive enough to install the malware [...]

Denial This statement is meme-epic. Users don't know they are installing malware, that's the very concept. Under Windows, they remove them by dozen using tools such as CCleaner. On phones, most apps intentionally embed malware that shows ads, track users and harvest data for money.

Apps that got spotted mining XMR could as well had peeked at clipboard for private keys. If your "view" of security only includes people who never installed malware, then you'll only have to care about a handful of *BSD users... who can already deal with themselves.

So the app storing user's secret key on the server can be as easily hacked as the one requesting it directly from the user.

Reinterpretation What I previously said was that applications storing encrypted keys locally, such as Stellar Authenticator, are resistant against the attack. Apps that store secrets online & allow to sign in from any client are out of the public key cryptography security model & are indeed weak to credentials stealing attacks.

It's always worth mentioning specific details about the environment and prerequisites in security-related articles.

Denial No it's not: it would inform script kiddies, it would be too complicated for casual readers, and wouldn't be of much use for decent developers as they can figure out by themselves the consequences of a statement such as "the clipboard is readable system-wide".

[MisterTicot] This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.

It would be really awesome to check statistics supporting this claim.

Denial If scammers were the only ones to ask for secrets, few people would get caught. It doesn't take statistics to understand that.

Someone might even say that the intentionally misleading article that purposely omits important facts and attack prerequisites in profit-seeking effort may be viewed as unethical

Denial Security advisories are always written in a concise way (example). They describe a security flaw & devs are expected to be able to infer attacks for that description. For obvious reason, I never intended to describe the attack or provide the code snippets Gleb asked for (sic!).

Gaslighting

1. Your friend market secret sharing in his SCF communication.
2. I inform users that this is an insecure practice.
3. You say that my work could be seen as unethical.

Also, I apologize if any of my previous questions/comments upset or distressed you.

Gaslighting is a form of intentional aggression that is meant to trigger those very emotions. This is offensive regardless of whether or not it succeeds.

Comment 2:

That's exactly what I'm talking about. According to MrTicot, your application security model is flawed by default as clipboard is insecure. I have the opposite view - copy-pasting public or secret key may be a convenient option to login, at least until we have a better way to achieve that.

Re-interpretation I never said copy/pasting public keys was a problem.

Denial You make it sound like we're discussing opinions, but cryptography is rarely a matter of views but a matter of logic. By "security model", I refer to a set of conditions under which a given security feature is guaranteed. For instance, when it comes to asymmetric cryptography:

The identity of the signer is guaranteed as long as he did not share his private key.

Security feature: The identity of the signer is guaranteed.
Set of condition (1): The private key hasn't been shared.

That's how keypairs are meant to be used, this has been settled by scientists & experts more than 25 years ago and I don't think there's any debate going on on that matter.

IF the set of condition is not respected, THEN the security model is broken.

I agree that there are cases where it doesn't matter so much, but wallets in production are not one of these.

If one is looking for a well-implemented usage of cryptographic keypairs, GPG is the way to go. It protects identities, not money, but still: devs were serious and did things "the right way".

I reiterate my belief that cryptocurrency applications which doesn't respect this security model will hit a disastrous fail on their way toward mass adoption.

1. My point was about the signing process, but you posted a screenshot of the login form. I already said in my entry that login was worked on.

2. My point was about the number of redirections: there are at most two (->Cosmic.link->wallet). You answered on the number of interactions, which is not related to my software. Lobstr takes two. Trezor takes more. Keybase takes less.

3. Cosmic.link development has been limited by SDF funding, which ceased its programs for almost a year and preferred to promote sep7. I never said it was under development for one year and a half: I said it's been ready all that time.

4. In two years, I received $7,500 for it and worked for about 6 months, including studying Stellar functioning, debatting the concept & its design, doing researches about different ways to make it work, then writing the specs, the SDK, the front-end, the Ledger and Trezor libraries, the developer tools, articles, documentation, and helping people integrating it. Not bad for a "student on a hackathon".

5. Fun fact: that wallet you never released, and that is inspired by my work, received more funds than that. (StellarExpertID got money from the SBC#7 and the SDP)

6. My point was about solutions that don't require copy/pasting secrets, and you answered that all wallets need private keys to sign transactions. This is true but unrelated.

7. My "wrath" was specifically about one well-known dev who went out of his way by promoting private keys copy/pasting as part of his SCF strategy. So yes, it happened during SCF.

8. You're defending private keys disclosure and public keys protection in the same post. I guess you just invented the one-man-pincer-movement.

9. I said that copy/pasting secrets is insecure and it is. I said that secrets are not meant to be shared and they aren't. Ultimately, there are only two ways devs can figure that out: by thinking or by failing.

10. Here's your demonstration: even by doing things the right way some systems won't protect the secrets very well (namely Windows) THEREFORE MisterTicot intentionally exaggerated the issue of copy/pasting secrets. This is not actually logic, and you're not doing good at reading my intentions.

11. Security measures are rarely 100% effective. Audits, peer reviews, firewalls, sandboxing, permissions, antivirus, antimalware, antispam, passwords... We only hope several layers of those will be enough to prevent or mitigate the consequences of breaches. Let's see why proper keypair handling is worth implementing:

    • As I already explained, this is efficient in defending secrets in several scenarios - including on infected systems - which is in itself a sufficient reason.
    • Even on insecure systems, people copy/pasting secrets will get harvested before people encrypting keys. Security is not about being 100% but about doing better than that neighbor who leaves the doors wide open.
    • The threat I mentioned will make the news in a spectacular way sooner or later. Why? Because there will always be careless developers who don't understand an issue until it blows in their face. And that day, those people who red my article and understood it won't be part of the casualty. This is what "informing users" achieves.

12. Only hate is hateful.