I've done incident responses for this exact type of attack multiple times. They've gotten much better organized lately and will often contact developers directly (over LinkedIn or WhatsApp) to run this type of attack. (Although, usually pretending to run a test for a job interview -- which is maybe why the author was confused about the code)
I think this was posted because the of the recent Npm malware fiasco. The malware monkey-patched native JS functions to replace strings that matched crypto addresses in certain the fetch, and XMLHttpRequest functions:
Considering there's no way to check whether a function is monkey-patched, this just tells me the JavaScript ecosystem was not designed with malicious actors in mind
I think the issue with this is that you'll never be able to have the deep integration current FMD implementations have (where you have Bluetooth beacons to track the phone even when it's "off") and also be able to use anything that requires a signed bootloader and OS (such as banking apps)
I think this article sidesteps what this bill also means: a return to cold-war-era thinking of "passive" advancement of military capabilities for the "just in case" scenario
I work in the security industry and use WIZ and while I do despise all of the buzzword acronyms this industry has come up with, CSPMs have been one of the few tools that have actually made my life significantly easier. Due to the nature of the industry I work in, there is a lot of regulation that we need to comply with, and CSPMs (and wiz in particular) gives us both observability and alerting for all of our resources in our cloud environments, including the configuration of the cloud environments themselves. I don't know how they managed to get a $32B offer so soon after coming out of stealth, but considering the amount of problems it solves for me and my team, I can see why they're doing well financially. We're definitely happy with the pain point the product fixes.
I can now say "I know for a fact we have x number of AWS/GCP/Azure accounts that are either not using our IdP or 2A, here's a list" without having to script across multiple cloud APIs
Similarly, I can say "here's a list of people that accessed x resource in the last y days". It really makes my life easier when I want to access metrics about my company's cloud environments
I'm not too familiar with the situation in Portland, but I have heard that programs which decriminalize drugs and provide care centers are not effective without existing social nets such as solid unemployment programmes and public health programmes that treated addicts can use to get themselves out of the socio-economic hole they got themselves into
Maybe the US is lacking in those programmes and is why the drug legalization programme is not effective in Portland?
As explaine by the article, counterfeiting involves pretending to be a product it's not. For example, if you sell your hypothetical channel bags as genuine channel bags instead of as generic, no-brand bags, then that would be counterfeiting because you're pretending they're something that it's not. Using genuine apple parts in third-party screens is more comparable to putting channel bag straps (which, yes, have the channel logo on them) into fake bags and selling them as generic, non-channel bags.
Similarly, if you don't label the third party screen as "genuine apple", you're not infringing copyright.
We do the exact same thing to keep track of some credentials we use sops[1] and AWS KMS to separate credentials by sensitivity, then use the git differ to view the diffs between the encrypted secrets
Definitely not best practice security-wise, but it works well
The mathematical YouTube channel ThreeBlueOneBrown recently organized a competition for people to create the best math explainers they could (in video form or otherwise) and this article was one of the winning entries
If you'd like to see the conclusion to the competition, here's the link:
> Veilid is an open-source, peer-to-peer, mobile-first networked application framework, with a flagship secure messaging application named VeilidChat. Veilid is conceptually similar to IPFS + Tor, but faster and designed from the ground-up to provide all services over a privately routed network. The network also enables development of distributed applications without a 'blockchain' or a 'transactional layer' at their base. Veilid can be included as part of user-facing applications or run as a standalone server for power users who wish to help build the network.
I find it kind of amusing that people still blindly follow their ideology without being pragmatic about things
If hardware doesn't (or barely) works with a free/libre implementation, why do they (gnuboot) refuse to use the proprietary binary blob and in the meantime start development on a better free version?
The technological implementation aspect is not generally what stops new ideas. And, I think the technical aspect comes after deciding how a CBDC will look like, since it depends on what you want to achieve with a CBDC.
Looking at the different aspects of topics like Privacy, Auditability and how the CBDC relations to the government will give you vastly different implementations of CBDC.
For example:
1) Privacy: is every transaction in the blockchain completely public? Is it only accessible to certain authorized parties? Is it private by default and only accessible with a "view" key like with Litecoin or Monero? All of these questions depend on what the goal of the goal of the currency is. Having a more private currency will make it harder to audit, but you probably do not want to make it completely public in the same way that you'd probably not want to make all your bank transactions public.
2) Considering auditability: How can you make sure then money in a transactions didn't come from illegal gains? If all transactions are completely private (even to the central bank), how do you do KYC and comply with AML regulation? Currently, banks do KYCs on every customer, but if the blockchain for the CBDC doesn't have access restrictions, who will do the auditing? Additionally, how would a tax collection agency like the IRS confirm that you're actually telling the truth about your transactions? They'll need to be able to access those transactions at some point too for audit purposes.
3) Considering the relationship with governmental power: does the government have the power to view every transaction at any time? What powers do they have in the blockchain? Are they the ones that develop the code?
Considering all these questions, you can start to get a relatively good idea for what a CBDC would look like:
1. There are probably some access restrictions since someone needs to do KYC.
2. The blockchain needs to be private by default, but accessible by anyone auditing.
Considering privacy, you could set up a system where authorized transaction processors (such as regional or national banks) are permitted to create wallets for their clients after doing KYC. The transactions could be private by default but have a key to allow the KYC provider to audit transactions an comply with audit requests.
> Occamy has a lightweight 32-bit CPU core that acts more as a control chip, and it is responsible for rerouting tasks to the AI cores, which are extensions to the instruction set architecture.
https://en.wikipedia.org/wiki/Lazarus_Group
I've done incident responses for this exact type of attack multiple times. They've gotten much better organized lately and will often contact developers directly (over LinkedIn or WhatsApp) to run this type of attack. (Although, usually pretending to run a test for a job interview -- which is maybe why the author was confused about the code)