The bit shifts were my first idea too where this would break down; but actually, 1-8 bit shifts would be just fine, and they can be encoded in 3 bits. 0 and 9 are special cases anyway (nop and full nonyte/nyte) for the programmer/compiler to become a tiny bit more clever; or use the shift-by-register instruction instead. T
This is not the case for 18 or 36 bits; I would imagine an architecture like this wouldn’t have a swap/swapb but a shuffle type instructions to specify where each nyte is expected to end up, encoded in 4x2 bit in the most generic case.
With this, I think I can get behind the 9-bit archs with the niceties described in the post..
In the UK, similar situations are common when “someone” flags any transaction to or from you as suspicious, at which point they need to freeze it, report it to an appropriate branch of an organisation, and… wait. That organisation most of the times doesn’t respond, so the hold expires in about two weeks, and then everything resumes working.
The thing is, noone can be told of this freeze/hold, that would be mean tipping off the party that made the suspicious transaction - from what I gather, it’s actually illegal to reveal it’s frozen, so they invent all kinds of meaningless/dumb reasons why the transaction (or the account) can’t be used right now.
So, lack of transparency and accountability IS the purpose of the system in that case.
What I hate the most about this is that “is this you” is triggered apparently on a browser version change, which can be up to two times a week.
On top of that, with apple private relay, an iPhone’s IP address changes quite frequently.
Another guilty site is Amazon. As long as you want to buy another phone, they are OK with your session, but if you want to check your order history, suddenly they are not so sure about your identity — no investigate, only buy…
IMHO it is clearly a wrong assumption on the side of any such sender. A verification link should have clear definite actions for the user receiving it:
- It's me, let me confirm my address
- I never signed up for this heap of diamonds
Whenever I (not even a bot) click or follow a link from my mailbox, by accident or on purpose, I don't expect that to validate an account for anyone else, but me, intentionally, using a password I know.
I'm quite confused, the article is supposed to be an advocacy piece, but it is just being all defensive about where the use cases are.
With TCP/IP, or packet switching, they did have an idea that it will be useful, but noone could imagine how popular it's going to be. With crypto, it seems the opposite, I'm afraid.
Noone needs a use case for a Raspberry Pi, or a Raspberry Pi Pico (the latter, many would say, borders on being useless with other, cheaper and/or more complete platforms being available). But I can just buy one, and tinker with it and voila. I don't need a use case to run a Z80 retro emulator on a Pico, I can just do it on my own, without any "industry" deciding which type of emulators should the investors have.
Why "crypto" needs a use case is exactly because people insist it's money, and had to be acquired with money.
While it was all P2P, and you could get whole bitcoins for fun, it were different times. Nowadays, you can't mine any meaningful amount of it unless you invest in thousands, or you buy them with money or credit card. And it's starting to be either illegal in some countries or in a custodial wallet, going poof when the company goes bankrupt.
Are you trying to repeat Bill Gates's Open Letter TO Hobbyists?
You're still missing "Most directly, the thing you do is theft."
I think the past 46 years have proved, that free software works, no matter how many Bills want (or will) get rich off the industry. If there were no hobbyists either literally stealing software, or indirectly "stealing" it, because it's free, there would be no industry to profit from.
pass is great for availability, I think I have several friends even in other countries (if a VPS wouldn't be sufficient) that would lend me space with a shell account for a "pass git push".
Of course, the gpg key is an issue, just as well the password or the ssh key for those accounts. In addition to passphrase2pgp, you could also use paperkey and keep it storage and/or a bank safe. I, for one, store my GPG key on a Yubikey. Of course, I would have thought I'm storing it safely, but it's left in my laptop for a few days now, so chances are I would simply leave it there in an actual emergency. However, pass also supports (re)encrypting with multiple keys, and one more Yubikey can then be kept with friends/family, and it can also store backup SSH keys.
Having multiple copies of ssh and GPG keys and the passwordstore git repo, chances are great to be able to recover most of the online presence.
If a phone/tablet itself can be saved, it could also host another mirror of the GIT repo (for example with an app like Working Copy), accelerating recovery.
This is not the case for 18 or 36 bits; I would imagine an architecture like this wouldn’t have a swap/swapb but a shuffle type instructions to specify where each nyte is expected to end up, encoded in 4x2 bit in the most generic case.
With this, I think I can get behind the 9-bit archs with the niceties described in the post..