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.
No, the bank cannot explain why SARs triggered a debanking, because disclosing the existence of a SAR is illegal. Yes, it is the law in the United States that a private non-court, in possession of a memo written by a non-intelligence analyst, cannot describe the nature of the non-accusation the memo makes. Nor can it confirm or deny the existence of the memo.
It’s not just illegal to disclose a SAR to the customer. It is extremely discouraged, by Compliance, to allow there to be an information flow within the bank itself that would allow most employees who interact directly with customers, like call center reps or their branch banker, to learn the existence of SAR. This is out of the concern that they would provide a customer with a responsive answer to the question “Why are you closing my account?!” And so this is one case where in [Seeing like a Bank] the institution intentionally blinds itself. Very soon after making the decision to close your account the bank does not know specifically why it chose to close your account.
Having worked in Fintech for several years, THIS is the main reason why I moved the majority of my liquid assets to cryptocurrencies.
For all the things people want the. To do, the most important one to me is the "not your keys, not your coin".
I don't trust banks as neither. One time a bank i use to get paid decided to "block" my accounts for 'suspicious avtivity" (i made a transfer to an account number they deemed high-risk). I ended up having to go to a specific physical branch, and literally BEG the clerk to activate the account where they had MY FREAKING MONEY.
I've learned since that, once you give it (lend it actually) to banks, it is not your money.
The idea that I have to not lose a private key file to access my own money is terrifying, and on top of that, if someone else gains access to that file, they will steal my money is just a horror show on top of that. I also worked at a FinTech for a few years but it's not relevant. What is relevant is how much you trust your own opsec and the level of organization you have for your own files. I can believe that some people find self-custodial ownership of significant amounts of crypto reassuring, but I do not.
xtracto doesn't understand security. An individual with crypto must not advertise that they have any or they will be spear targeted (up to and including lead-pipe analysis by distributed anonymous resources). https://archive.ph/PJTZP
Internet anonymity might be a temporary defence, until AI doxing analysis improves or one's government decides to change their rules (good luck securing against that).
I don't have any crypto: firstly because I lack the opsec skills. Also because I travel to other countries, and the best defense is to actually not have anything worth being stolen (or limited financial exposure e.g. my physical wallet was stolen last time I was in Brazil).
People immensely more skilled than I will ever be, still have security failures (e.g. Troy Hunt fell for a phishing attack recently).
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.
As Heartbleed and numerous other examples show, the corporations freeload and then barely give anything back. There should be a nuanced middle ground between charging everyone for everything and not letting corporations that collectively make hundreds of billions if not more of revenue off software get away with contributing nothing back.
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..