Which is why you wouldn't pay it in the first place and which is why you would actually try to make your system secure instead of having an insurance pay for your gross negligence.
Some people might think their IT department is fully omniscient (or competent in other cases) and knows every flaw they could be targeted by which is why it would make sense to hire an external firm to audit you.
> Which is why you wouldn't pay it in the first place
Currently, ransomware operators could just decrypt half your files upon 50% payment, and demand yet another payment for the rest. But they don't. Why? Because they seem to have naturally converged upon honoring their decryption payments in order to maximize total profit. I think if paying the ransom was made more explicitly illegal, the ransomware operators would probably converge on not outing their clients. At least for now.
> I think if paying the ransom was made more explicitly illegal, the ransomware operators would probably converge on not outing their clients. At least for now.
Or they can threaten to release your information and demand more ransom to keep your information a secret. If you stop paying they'll make it public making what you did illegal.
So, now, not only would law enforcement struggle at catching the criminal asking for ransom, they would additionally struggle to enforce the law on the victims
I assume they are referring to victims hiding their payments from the government. It definitely just looks like an additional ingredient in this wild goose chase.
It’s hard to get cooperation from a crime victim if cooperating is rewarded only with a choice between ruin through loss of his business and ruin through criminal charges. You’ll just see silence as people rationally seek to avoid ruin and fail to report the crime at all.
The point of my comment should becomes clearer if the first few paragraphs is read: the author thinks it's great idea to tell law enforcement to target victims through an hypothetical law he is proposing that would make it illegal to pay ransoms.
He's basing his opinion on treasury department decision to (seemingly) ban ransom payments to ransomware groups.
What he seems to be misrepresenting is: treasury department is not banning ransom payments. They are clarifying that payments (including ransom ones) to an entity on sanctioned list is illegal.
How does this translate to the rest of ransom requests seen in society is beyond me.
Are we setting up a precog unit to classify all people and entities in the world as sanctioned/non-sanctioned?
Millions of dollars paid in ransoms don’t just disappear off the books. And if they did, that would be an entirely different problem, which is perhaps even more illegal than paying the ransom.
Ransomed company pays data recovery company, data recovery company pays ransom. I believe it is actually a common thing.
The ransomed company is in the clear. They paid for a legitimate service, it is in the books, taxes paid, all that stuff. They may even really think that they got their data back without a ransom being paid.
Less so for the data recovery company, but they can probably try to justify expenses by hiring "foreign cryptography experts", or doing "security research".
No, enforcing this law on the victims would be much easier. The criminal is most likely in a foreign jurisdiction, and trying hard to hide their identity; the victim is in a local jurisdiction (otherwise, this law wouldn't even apply), their identity is known (on the jurisdictions I know of, companies must be registered with the government), and the government has a large amount of tools at their disposition to enforce a judgment (for instance, freezing and/or seizing bank accounts, or in extreme cases even suspending the company's registration).
That means, for many victims, that that's it, game over, you go out of business. A lot of ransom money is paid because often as not it is very hard and expensive to ensure not only that a business can recover from such an attack, but also on a timeframe and at a cost that doesn't by itself break it, so a great many can't unless it gets detected and stopped very early. Lots of businesses will pay regardless of a ban and eat the fine, or try to pay clandestinely, diverting resources law enforcement should be using to catch the perpetrators. Not sure this is worth a bit more pressure to catch criminals that probably won't get caught anyway.
There is always going to be money in it as long as there is ever anything worth ransoming.
What's new here is a new type of criminalization and an incentive to hide your actions from the government. And if the ransomer is asking $5,000 and the government will fine you $50,000, then you have a good incentive to gamble on never getting caught, and that's already a game corporations play (very successfully) with taxes.
Corporations are not hiding their money from taxes out of sight. They are hiding it in plain site - the exceptions in the tax laws. Hiding out of site is basically impossible for any large company: somebody internally is sure to get disgruntled at some time and tell the police (often for a significant reward).
The Corporates just add a shield layer of employing an 'external consultant' who offers to 'find a way of fixing it'. In fact, there is already a term for it. A quick search of the term 'Ransomware Negotiator' provides citations.
Is it a good thing that paying OFAC sanctioned extortionists and thereby illegally financing further ransomware attacks via cryptocurrencies is a "solved problem"?
Paying someone on the OFAC list was already illegal whether ransomware was involved or not. The novelty of the circumstances don't change anything.
The novelty of the circumstances do change the futile utility of making an announcement about it, as there should be no way of knowing that a ransomware operator is on the OFAC list, and there should be no way of knowing that you paid a ransomware operator that was or was not on the OFAC list.
I don't have an opinion about your question and never addressed it and won't address it, as it is completely moot. As people adopt these technologies for more benign purposes, the peculiarity of using them "when you need to" goes away.
By the same logic, shouldn’t it be illegal to hand over your wallet if you get mugged?
Companies aren’t really paying this money by choice, they are paying it because losing systems/data can in some cases result in an inability to operate - otherwise it wouldn’t really be a ransom.
The difference is that if you get mugged, your physical safety is being threated. So giving your money to the mugger is reasonably considered defense against bodily harm. I believe that in most randomware cases, nobody's physical safety is in immediate danger (except cases that involve hospital systems or other remote-controlled/networked medical device).
I'd say there should be an exception for ransomeware cases where physical safety is being threatened.
I don't think so, because critical services/systems are targetted by ransomware operators regardless of the exception. And I don't think the victim should be burdened to decide between losing a life vs paying hefty fines.
Is it clear that it’s illegal? Is the group clearly defined on a list somewhere or are those sending money supposed to use their judgment? If you’ve been defrauded is that also illegal, making you a criminal as well as a victim? Or is only ransom prohibited? If my local car dealership commits some environmental crime by pouring motor oil down the drain, does this make it illegal for me to pay them to service my car there? What about if your neighbor’s kid is in a gang, but you want to set him straight and give him opportunity, so you pay him to mow the lawn: is that illegal too? What if the whole gang mows your lawn? And if the mafia is shaking down your business for extortion payments, does it make you more or less likely to talk to the cops if that makes you a criminal too?
There are answers to these, but it’s inherently a fuzzy area.
> You are basically financing a criminal group. In normal cases that's clearly illegal.
Clearly, not the case. That might be an interesting way to naturally limit the size of corporations and their influence; if everyone who fills up their car at a gas station becomes a felon by being a customer.
Yet it seems to scale too low for some purposes. Its the rare restaurant that has never had a minor (or major?) health code violation. Certainly we shouldn't shut down all restaurants?
Maybe the strategy to implement "sons inherit the sins of their fathers" as government policy would be customers inherit one step down from the sins of their corporate retail operator. So a step down from a minor regulatory issue at a local restaurant would be nothing, but a step down from a major felony committing megacorporation would be a misdemeanor ticket violation.
Building my own PC recently after a decade on Linux/macOS made me realize how much more susceptible to ransomware PC users are at a PC cultural level.
Literally every program I saw recommended when setting up my environment was available from download sites like FileHippo and Softpedia. Here's the second download link for "AutoHotkey" on google: https://autohotkey.en.uptodown.com/windows - wtf is uptodown? They even train you to get used to that classic subdomain spam that malicious websites use. Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do. Always from a shady mirror website that trains you to run .exes from any website that shows up in search.
It was a breath of fresh air to get WSL + Debian up and running on Windows so I could rely on apt-get.
The Microsoft Store is surprisingly bad, not having anything you're looking for, but plenty of apps that claim to be that thing or would confuse people who don't know any better.
Normal users are really being let down from a security standpoint in computing, in general.
macOS has similar issues with websites like macupdate.com, but it's slightly farther along with its much more compelling app store library. My girlfriend is a UX professional and the only few apps she uses outside of the app store is Chrome and Sketch. It definitely feels like this approach is moving in the right direction that can satisfy most people and power users as well.
And for completeness, I would think a GUI over linux repos like Synaptic is also nice for normal users. I have one not-so-technical friend on Linux Mint where I saw them using whichever GUI to grab packages.
Chocolatey is far better than downloading installers manually, but it's just slow as every installer has to do its own thing rather than just relying on a package manager to place files where they belong. It also doesn't remember why a package was installed, so dependencies of a package aren't removed after uninstalling it.
Last I checked the dependency management there is pretty basic. Also you have the additional problem, as in my case: the software requires a JDK, how likely is it that the user already has a JDK installed without chocolatey, and if not, which one will I install (not sure if it was even possible to say "any JDK between version X and Y").
Yeah. I'm not too familiar with other distros, but Arch has a really nice thing where packages can specify e.g. "java-runtime>=11". If the user already has a compatible JRE installed, it'll be used, otherwise the user will be prompted to pick a version.
Back in 2013 or so, there was a small GUI I had made, and wanted to host the executable somewhere. (A utility for making character sheets in an out-of-print tabletop RPG, only ever used by the group I ran.) It was about two weeks between uploading it to sourceforge and there being an unexpected mirror on softpedia. I never did check whether it was virus-ridden or not.
When something that was written by a single person, and maybe had half a dozen users at the very most, gets an illegitimate mirror, how can anything larger stand a hope?
Agreed, there are definitely advantages to having older downloads available. Having an iOS-style walled garden is a recipe for disaster, as the blessed version can be revoked and made unavailable by either the developer or the distributer, leaving the user out of the cold. The main issue I run into is the lack of long-term reputation, and that things that scale (e.g. allowing any user to upload files) do so at the expense of trustworthiness.
I'd like to be in a position where I can recommend specific sites as safe and reliable, specifically when giving recommendations to less technically adept family/friends. However, with how quickly those reputations become stale (e.g. Sourceforge being bought out, then immediately burning its reputation by adding malware to downloads), that's not something that really can be done without coupling to a hardware ecosystem as well.
The opposite problem, which comes from relying on a package manager + repo, is that anything you want to do that isn't in the repo (more up to date stuff, obscure stuff) is a giant pain in the ass to get. You end up having to compile it yourself from source (and it isn't like build environments don't have their own compatibility issues), or use something like PPAs (assuming they exist for what you want), or manually doing the job of a package manger to adapt a foreign package. Static executables and AppImage make this a lot better, but they are not the convention so they can't really be relied upon either. Good luck getting a package manager to install anything to a non-standard location like a removable disk.
When it comes right down to it, I prefer the Windows convention of installers and zips to package management and all its limitations. Precisely because things like "Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do." are easily available with that model. Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer.
However, what we should really be doing, in my opinion, is something like AppImage (or NeXT Application Directories , or RiscOS AppDirs, etc.) combined with a sandbox-by-default similar to what exists on mobile, but without pops or the ability for the application to tell when it has been denied a permission.
> Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer.
Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up.
Fragmentation exists on Windows too, it's just internal.
> However, what we should really be doing, in my opinion, is something like AppImage (or NeXT Application Directories , or RiscOS AppDirs, etc.) combined with a sandbox-by-default similar to what exists on mobile, but without pops or the ability for the application to tell when it has been denied a permission.
You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions).
> Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up.
Due to the convention of not relying on fixed-paths in Windows software, as well as Windows providing a stable base platform of common libraries, pretty much anyone can just compile a program and put it and its resources into a zip file. The vast majority of the software I install is distributed this way.
> Fragmentation exists on Windows too, it's just internal.
The fragmentation of Windows is orders of magnitude less than Linux. I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation[0]. Occasionally there are minor incompatibilities between Windows versions and editions, but it isn't that way for most software.
> You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions).
No, I'm not. In my opinion Flatpak and Snap combine the worst of both worlds in that they still require repos and a special tool to manage them. I meant exactly what I said: AppDirs with default sandboxing.
[0] Hell, thanks to WINE it will probably even work on Linux without recompilation.
>I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation
On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing.
I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
> On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing.
Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them.
So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break.
By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation.
> I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.
>By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation.
This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different.
>I'm curious what this library could be.
The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app.
And even if I am that responsible, I as a user have to count on all the developers of apps I'm using to be just as responsible themselves. I mostly have no way to know whether they are, unlike the situation for example as a Debian user where they have a known track record and I can have some level of confidence.
> This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different.
Closed source or unmaintained. Setting up build environments is such a chore with a high probability of conflict that people often use docker containers for it. On top of that, compiling unmaintained older software yourself often requires enough knowledge to dig into the code and correctly fix the errors that have been introduced by API changes. Personally, I find it easier to try and get old binaries working instead.
Besides, closed source software not only exists, but also describes some of the most popular professional tools in existence.
> The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates?
Windows provides both its own media and GUI layers. I don't see why Windows should be expected to maintain any alternatives people choose to use.
> If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app.
Your choices as a developer have consequences! Windows has its own APIs for this. If you don't want the burden of maintaining a non-platform dependency then don't use one. If it is "just a hobby project" and you don't want to update your dependencies then just don't. The alternative is being beholden to third party volunteers to keep your software both available and working.
>Windows provides both its own media and GUI layers
Yes and using the Windows APIs in any meaningful way requires the user to install a ffmpeg-based backend for it anyway (LAVFilters) as it is insufficient in and of itself. And even this leads to problems often enough that media players seem to bundle their own version of LAVFilters anyway (defeating the purpose of using the API...at this point why not just use ffmpeg directly?) and forego using the globally installed ones.
Unless the system APIs can cover every use case that a software could need a library for, and do it just as well as the commonly used standard, I think the fact that there are some Windows APIs for some of these things is kind of beside the point. This dependency problem will still rear its head at some point.
> I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation.
I had a Windows user loudly say this in a room while I was in it. It's true Microsoft does a reasonable job of keeping one programs working. Not perfect, I've had many stand alone programs fail to run in "compatibility mode". It's a commendable effort nonetheless.
But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. So upon hearing someone claim yet again how much better Windows does this than Linux, laptop running some 2020 debian stable and a 64 bit Linux kernel, download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. I could do that with any distribution on my modern Debian laptop.
> But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly.
Yes, because Linus gets it. The people behind the userspace of desktop Linux really really don't though. If I want to write a Linux program that will work in 20 years without recompilation I can only depend on the kernel. Case in point:
> download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works.
You basically had to swap out the entire userspace to do that because ABI compatibility outside of the kernel is practically nonexistant.
Sometimes yes, other times there are conflicts because a lot of libraries are not forward compatible (glibc for instance) and different distributions have different conventions for library naming and paths. In my experience, you usually have to use a lot of LD_LIBRARY_PATH and related shenanigans to get anything working and it will still break when interfacing with software that uses a different version of GLIBC.
Even with the source issue being the same the installation process on mac os is just extremely far ahead. While on Windows you have to give any simple tool root privileges (?!?!?!?!) for installation, with many mac apps you just drag the file into your "Applications" folder and that's it.
> While on Windows you have to give any simple tool root privileges (?!?!?!?!) for installation
Bit of a stretch. Most simple tools I'm aware of do not require elevation, or even installation for that matter. That said, a lot of tools do insist on elevation even when it is unnecessary.
I agree with the overall point: Mac does it better with Application Directories. You don't even need to drag them to the Applications folder, they run anywhere including off of removable media.
I think things like snaps may eventually bring the same sort of nonsense to the linux world.
"Because packages in the Snap Store are maintained by developers themselves, distribution maintainers cannot ensure packages meet quality standards and are timely updated."
Years ago Linus succinctly expressed why the distribution-specific linux package manager approach sucks as a way of distributing software and is a major reason why a lot of developers hate writing software for Linux.
I remember reading and do you know what the difference is between different distributions? basically a repository + a package manager. that is what a distro is.
"The current situation, where there is no criminalisation of payment has created a market place where a number of companies working with insurers are handling the vast majority of ransomware incidents. There are crisis responders who help the companies recover, who arrange a minimal payment, and who get paid by the insurers. This is market governance and it keeps the prices down because there is a sort of gentlemen’s agreement between the gangs and the payment companies. Also, the lack of prohibition means these companies operate in the open and they can share information about pricing etc internally and with each other. (Transparency)
The status quo is not the ideal world, but it is far better than the nightmare of ineffective partial prohibition."
Out of curiosity, how is paying randomware all that much different from handing a mugger your money? And is it also illegal to pay kidnappers? Honest question.
> Out of curiosity, how is paying randomware all that much different from handing a mugger your money?
The difference is obvious: not handing the mugger your money is an immediate threat on your life. You won't die just because you didn't pay a ransomware operator.
> And is it also illegal to pay kidnappers?
The article already answered that: in some countries, it already is. "[...] In response to a wave of kidnappings by organized crime, Italy prohibited ransom payments in 1991. Colombia and Switzerland have also made ransom payments illegal. The Group of Seven has a long-standing policy of refusing to pay ransoms for hostages of terrorist groups."
It is illegal to pay kidnappers. Kidnapping isn't nearly as common as it used to be because it is so hard to get money. Though when it happens it is harder to trace because those who would pay don't talk. The same goes for bribing foreign officials.
There are exceptions for Fear for your life situations. Which is why paying a mugger is legal.
You don't actually pay your mugger. Forced consent isn't consent. The mugger steals from you (even if the money was actually "stolen" by your hand, not his/hers).
I agree with this. When you give a company gross profit (price higher than what it took them to get you the product) you are literally paying for them to spend some of that on getting their next customer.
Anyone who is paying a ransom is literally paying a ransomer to do that to someone else. Not in a metaphorical sense. You are literally transferring the ransomer money which the ransomer will literally use to finance the next ransom. They will pay out of pocket for the person doing the next ransom to go and do it. It should be totally illegal to finance this.
This is not how it works. If you pay a company money and they earn a profit, they will have more money. But the next customer doesn’t come specifically out of your revenue. They generally won’t have waited for you at all, and they would still pay for ads and similar acquisition costs without your money, whether from their reserves or any lines of credit.
You charge your own acquisition cost against the profit from your custom, not the next guys’ cost. In the case of crime you have paid them to hack you, not others.
The us needs to release and update a list of criminal bitcoin accounts. Any bitcoin coming from these accounts should be poisonous and any account ever receiving coins tracked back to that account should be fined plus repay the bitcoin value (receiving stolen property).
The scammers can hide, but their bitcoin money can be tracked forever and interacting with the real world in significant sums requires giving up anonymity. It seems very easy for wallets to access a database and alert their user that they're about to purchase tainted bitcoins.
That ledger is already public. Every government in the world is guaranteed to track users. The illusion of anonymity is dangerous.
If bitcoin dies because it's only used by thieves, extortionists, and cartels, then it deserves to die. I don't think the majority of transactions are of that sort though.
> That ledger is already public. Every government in the world is guaranteed to track users. The illusion of anonymity is dangerous.
That's not the point. Any bitcoin coming from these accounts should be poisonous and any account ever receiving coins tracked back to that account should be fined plus repay the bitcoin value (receiving stolen property). is what would destroy bitcoin.
So I can just buy one "poisoned" bitcoin and send a tiny fraction of it to every public address I can find. Now the entire network is poisoned.
Criminals use a variety of money laundering techniques, such as "tumblers": big buckets where you put in both legitimate and illegal transactions and get back an unidentifiable mix of both. But I'm sure a lot more cleverness is happening.
Sure you can, but there are two points worth mentioning.
The network could and should be built to adapt to such potential attacks. Spamming transactions (essentially a ddos attack) should be banned anyway.
Accidental receipt of stolen goods isn't a crime if you immediately turn them over to the police. People could forward all those coins over to a law enforcement account and receive no penalties while the sender would lose money without gaining anything. This too could be automated.
This is actually not such a big problem. Bitcoin's accounting methodology uses something called UTXOs (unspent transaction outputs). It gets complex fast, but short version is that if you send me some bad bitcoins, I can separate the good bitcoins from the bad.
The problem you mention comes up in the other direction - I am a money launderer and I have some bad BTCs. I can use the UTXO system to mix it with good BTCs I control, creating questionable BTCS. This is is why there was recently news of bitcoin mixers being fined: https://cointelegraph.com/news/us-financial-watchdog-fines-e...
> So I can just buy one "poisoned" bitcoin and send a tiny fraction of it to every public address I can find. Now the entire network is poisoned.
Only if these tiny fractions are actually used. When you send something to a Bitcoin address, what you are actually doing is creating an unspent transaction output which can only be spent by that Bitcoin address. Nothing prevents the wallet software from ignoring that tiny fraction and instead using a larger unspent transaction output to the same address, which would result in a smaller transaction (one input instead of two, since the tiny fraction most probably wouldn't be enough for the transaction).
The US already does this. Its called OFAC (Office of Foreign Assets Control) and they maintain a list of bitcoin (and other) addresses linked to malicious activity. They are the ones actually doing the work to lock down bank accounts when you hear 'US sanctions 5 people from country X', but this bitcoin stuff is a natural fit for them. I think they mainly focus on terrorist and state sponsored stuff, but at least in principle its there.
I didn't google, but I thought they monitored and prevented banks from interacting, but not everybody in general.
There needs to be widespread buy-in from many countries at a granular level for it to be particularly successful. Otherwise bitcoin makes it too easy to turn day-trading into laundering.
Correct, OFAC only works for people who abide by it (mostly banks).
But how do you get your idea working? The whole point of bitcoin and crypto is that its decentralized. Even if governments bought in, they cant stop individuals
Bitcoin is digital, but the stuff bought with bitcoin is not. This "analog hole" is trackable. Sooner or later, someone is going to want to convert bitcoin into some other currency or buy something from a business. Businesses are required to reveal things like bitcoin on their taxes. I'd wager that a large amount of traffic is easily trackable based on cellular data.
Imagine you try to buy something and are greeted with "The US government has forbidden access to your account due to it containing bitcoin involved in criminal activity. Go to blah.gov to see what you can do to unfreeze your account and try again". You go there and find out you have to turn over X bitcoin to unfreeze your account and maybe get a recommendation to get a wallet app that can alert you before you get bad bitcoin.
After just one time, most people will move to something that makes sure it never happens again which will trickle down into bitcoin to bitcoin transfers too and stop these illegal transfers in their tracks. Extorters will move to other means of payment which will either be easy to track (physical payment or traditional money transfer) or some super-volatile coin where they're very unlikely to get a meaningful payout.
The logic here is if there's a big risk to victims from paying they won't pay, and if 99% of victims won't pay, attackers won't attack.
It seems to me that logic only works when attacks are expensive. With something like kidnapping, you couldn't possibly kidnap 1000 people in the hopes of getting a single $10,000 ransom payment.
But with malware, where launching an attack costs almost nothing? Attacks could still be profitable even if only 1 in 1000 victim pay up.
But the long-term plan is, that the attacks become more expensive, because it would cause companies to stop having insecure systems (and up the product chain, e.g. Microsoft would have to patch Windows or suffer losses).
Same as with spam - the simple solution is that spam (mail/email/calls) are charged to the operator/provider - I can assure you that a solution would instantly appear whereby the providers would take great care about blocking spam at its source.
The status quo in both cases is just to "solve" (but not really) the problem with the cheapest, shittiest possible solution.
This will have the effect of reducing the number of cases of ransomware that law enforcement sees. Not by actually reducing the cases, but instead by making it untenable for a victim to notify law enforcement.
<rant>This is unfettered metric fetishization -- the idea that a problem can be quantified as a metric and when the metric is reduced the problem is reduced. The map is not the territory, you can't just look for your keys where the light is good, the bed of Procrustes, etc. Or maybe it has nothing to do with this and is just a well-intentioned but stupid idea.</rant>
I would think that for less than 400k in random payment, the perpetrators of the attack (and anyone complicit) could be located and permanently removed. That might deter future attackers, unless of course these are government sponsored attacks.
First of all, no you can't simply locate them by paying money to some all-knowing crypto god. And even if you could, the US would order a drone-strike on some apartment building in Moscow?
I've had the idea floating around my head for a while that instead of banning the payment, they should tax them.
If you start putting a 500% levy on any business paying a ransom the whole concept becomes a lot less profitable because assuming attackers are not settling for 5x less than what they think businesses would really pay, they'll have to slash the ransoms.
And the government gets a nice funding pot to try and fight them.
The key here is that you will not be able to use ‘security insurance’ money to pay for ransom. What is happening now is that companies are saying: we do not need backup, let’s just have security insurance (and some minimal backup so that insurance is valid).
I will probably take some heat for this response but as a Canadian here is how I see this happening. My computer gets hacked. I am a low level target so the Ransomware asks me for something trivial like $1000. Now I have a couple choices. Not pay and not break the law or pay and break the law but get back all my baby pictures. I am going to pay and take the consequences. In Canada we had a guy literally decapitate another man and then cannibalizes the body. He did 7 years. We don’t jail people for things like paying ransom and if we did we slap people on the wrist. This law will have no teeth for some because we watch the revolving door court system where all criminal are given a slap on the wrist. It is only repeat offenders getting anything other then probation. So at worst I would risk a fine or probation. I live in Canada though so we don’t bend over backwards to screw people so my fine would be insignificant compared to the loss of all my baby pictures. Even if the punishment was 5000$ I would still be leaning towards paying to get those baby pictures I haven’t backed up. If the punishment was a week in jail again I am still going to pay we have really nice jails with all sorts of rights when you get there. I guess my point is we need a better way then telling victims they can’t pay. Thankfully I have backed up my pictures and don’t worry about this scenario currently.
Banning ransom payments outright would eliminate the possibility of investigating by blockchain analysis.
Implementing a maximum legal payment amount and mandating that all ransomware payments’ TXIDs be reported to law enforcement would be a reasonable compromise in my opinion.
101 comments
[ 5.6 ms ] story [ 164 ms ] threadCurrently, ransomware operators could just decrypt half your files upon 50% payment, and demand yet another payment for the rest. But they don't. Why? Because they seem to have naturally converged upon honoring their decryption payments in order to maximize total profit. I think if paying the ransom was made more explicitly illegal, the ransomware operators would probably converge on not outing their clients. At least for now.
Or they can threaten to release your information and demand more ransom to keep your information a secret. If you stop paying they'll make it public making what you did illegal.
In non-sarcastic words, I'm unsure what point your comment is trying to convey.
He's basing his opinion on treasury department decision to (seemingly) ban ransom payments to ransomware groups.
What he seems to be misrepresenting is: treasury department is not banning ransom payments. They are clarifying that payments (including ransom ones) to an entity on sanctioned list is illegal.
How does this translate to the rest of ransom requests seen in society is beyond me.
Are we setting up a precog unit to classify all people and entities in the world as sanctioned/non-sanctioned?
The ransomed company is in the clear. They paid for a legitimate service, it is in the books, taxes paid, all that stuff. They may even really think that they got their data back without a ransom being paid.
Less so for the data recovery company, but they can probably try to justify expenses by hiring "foreign cryptography experts", or doing "security research".
What's new here is a new type of criminalization and an incentive to hide your actions from the government. And if the ransomer is asking $5,000 and the government will fine you $50,000, then you have a good incentive to gamble on never getting caught, and that's already a game corporations play (very successfully) with taxes.
Stop using surveillance coins.
You can send a tornado.cash note to the operator.
You can send Monero.
These are solved problems.
The novelty of the circumstances do change the futile utility of making an announcement about it, as there should be no way of knowing that a ransomware operator is on the OFAC list, and there should be no way of knowing that you paid a ransomware operator that was or was not on the OFAC list.
I don't have an opinion about your question and never addressed it and won't address it, as it is completely moot. As people adopt these technologies for more benign purposes, the peculiarity of using them "when you need to" goes away.
How do you even book it in your accounting and taxes? Do the criminals give you an invoice?
Companies aren’t really paying this money by choice, they are paying it because losing systems/data can in some cases result in an inability to operate - otherwise it wouldn’t really be a ransom.
I'd say there should be an exception for ransomeware cases where physical safety is being threatened.
doesn't that incentivise attacks on critical services/systems?
There are answers to these, but it’s inherently a fuzzy area.
Clearly, not the case. That might be an interesting way to naturally limit the size of corporations and their influence; if everyone who fills up their car at a gas station becomes a felon by being a customer.
Yet it seems to scale too low for some purposes. Its the rare restaurant that has never had a minor (or major?) health code violation. Certainly we shouldn't shut down all restaurants?
Maybe the strategy to implement "sons inherit the sins of their fathers" as government policy would be customers inherit one step down from the sins of their corporate retail operator. So a step down from a minor regulatory issue at a local restaurant would be nothing, but a step down from a major felony committing megacorporation would be a misdemeanor ticket violation.
Literally every program I saw recommended when setting up my environment was available from download sites like FileHippo and Softpedia. Here's the second download link for "AutoHotkey" on google: https://autohotkey.en.uptodown.com/windows - wtf is uptodown? They even train you to get used to that classic subdomain spam that malicious websites use. Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do. Always from a shady mirror website that trains you to run .exes from any website that shows up in search.
It was a breath of fresh air to get WSL + Debian up and running on Windows so I could rely on apt-get.
The Microsoft Store is surprisingly bad, not having anything you're looking for, but plenty of apps that claim to be that thing or would confuse people who don't know any better.
Normal users are really being let down from a security standpoint in computing, in general.
macOS has similar issues with websites like macupdate.com, but it's slightly farther along with its much more compelling app store library. My girlfriend is a UX professional and the only few apps she uses outside of the app store is Chrome and Sketch. It definitely feels like this approach is moving in the right direction that can satisfy most people and power users as well.
And for completeness, I would think a GUI over linux repos like Synaptic is also nice for normal users. I have one not-so-technical friend on Linux Mint where I saw them using whichever GUI to grab packages.
When something that was written by a single person, and maybe had half a dozen users at the very most, gets an illegitimate mirror, how can anything larger stand a hope?
I upgraded the firmware on a hardly-used Lexmark printer, which promptly blocked me from printing as my original cartridge was old — a DRM failure.
I think it was Softpedia where I found the older firmware and was able to downgrade.
I'd like to be in a position where I can recommend specific sites as safe and reliable, specifically when giving recommendations to less technically adept family/friends. However, with how quickly those reputations become stale (e.g. Sourceforge being bought out, then immediately burning its reputation by adding malware to downloads), that's not something that really can be done without coupling to a hardware ecosystem as well.
When it comes right down to it, I prefer the Windows convention of installers and zips to package management and all its limitations. Precisely because things like "Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do." are easily available with that model. Distributing software on Windows is something anyone can do very easily, without relying on a third party package repo or maintainer.
However, what we should really be doing, in my opinion, is something like AppImage (or NeXT Application Directories , or RiscOS AppDirs, etc.) combined with a sandbox-by-default similar to what exists on mobile, but without pops or the ability for the application to tell when it has been denied a permission.
Is that so? Last time I checked you had to choose between 3 installation approaches and then choose a 3rd party installer (all of which have bad UX) and set that up.
Fragmentation exists on Windows too, it's just internal.
> However, what we should really be doing, in my opinion, is something like AppImage (or NeXT Application Directories , or RiscOS AppDirs, etc.) combined with a sandbox-by-default similar to what exists on mobile, but without pops or the ability for the application to tell when it has been denied a permission.
You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions).
Due to the convention of not relying on fixed-paths in Windows software, as well as Windows providing a stable base platform of common libraries, pretty much anyone can just compile a program and put it and its resources into a zip file. The vast majority of the software I install is distributed this way.
> Fragmentation exists on Windows too, it's just internal.
The fragmentation of Windows is orders of magnitude less than Linux. I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation[0]. Occasionally there are minor incompatibilities between Windows versions and editions, but it isn't that way for most software.
> You're probably taking about Flatpak and Snap. One has great marketing but is not usable for ethical/practical concerns while I haven't had a very good experience with with Flatpak (its "runtimes" are basically extra Linux distributions).
No, I'm not. In my opinion Flatpak and Snap combine the worst of both worlds in that they still require repos and a special tool to manage them. I meant exactly what I said: AppDirs with default sandboxing.
[0] Hell, thanks to WINE it will probably even work on Linux without recompilation.
On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing.
I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them.
So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break.
By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation.
> I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.
I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.
This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different.
>I'm curious what this library could be.
The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app.
And even if I am that responsible, I as a user have to count on all the developers of apps I'm using to be just as responsible themselves. I mostly have no way to know whether they are, unlike the situation for example as a Debian user where they have a known track record and I can have some level of confidence.
Closed source or unmaintained. Setting up build environments is such a chore with a high probability of conflict that people often use docker containers for it. On top of that, compiling unmaintained older software yourself often requires enough knowledge to dig into the code and correctly fix the errors that have been introduced by API changes. Personally, I find it easier to try and get old binaries working instead.
Besides, closed source software not only exists, but also describes some of the most popular professional tools in existence.
> The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates?
Windows provides both its own media and GUI layers. I don't see why Windows should be expected to maintain any alternatives people choose to use.
> If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app.
Your choices as a developer have consequences! Windows has its own APIs for this. If you don't want the burden of maintaining a non-platform dependency then don't use one. If it is "just a hobby project" and you don't want to update your dependencies then just don't. The alternative is being beholden to third party volunteers to keep your software both available and working.
Yes and using the Windows APIs in any meaningful way requires the user to install a ffmpeg-based backend for it anyway (LAVFilters) as it is insufficient in and of itself. And even this leads to problems often enough that media players seem to bundle their own version of LAVFilters anyway (defeating the purpose of using the API...at this point why not just use ffmpeg directly?) and forego using the globally installed ones.
Unless the system APIs can cover every use case that a software could need a library for, and do it just as well as the commonly used standard, I think the fact that there are some Windows APIs for some of these things is kind of beside the point. This dependency problem will still rear its head at some point.
I had a Windows user loudly say this in a room while I was in it. It's true Microsoft does a reasonable job of keeping one programs working. Not perfect, I've had many stand alone programs fail to run in "compatibility mode". It's a commendable effort nonetheless.
But in contrast, Linus has kept his "don't break userspace" promise damned near perfectly. So upon hearing someone claim yet again how much better Windows does this than Linux, laptop running some 2020 debian stable and a 64 bit Linux kernel, download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works. I could do that with any distribution on my modern Debian laptop.
Yes, because Linus gets it. The people behind the userspace of desktop Linux really really don't though. If I want to write a Linux program that will work in 20 years without recompilation I can only depend on the kernel. Case in point:
> download Debian potato (circa 2000) and expand to a directory on machine running the latest Linux 64 (potato is 32 bit only), chrooted into it, apt install whatever, and showed him it all just works.
You basically had to swap out the entire userspace to do that because ABI compatibility outside of the kernel is practically nonexistant.
Bit of a stretch. Most simple tools I'm aware of do not require elevation, or even installation for that matter. That said, a lot of tools do insist on elevation even when it is unnecessary.
I agree with the overall point: Mac does it better with Application Directories. You don't even need to drag them to the Applications folder, they run anywhere including off of removable media.
"Because packages in the Snap Store are maintained by developers themselves, distribution maintainers cannot ensure packages meet quality standards and are timely updated."
https://en.wikipedia.org/wiki/Snap_(package_manager)
https://www.youtube.com/watch?v=7SofmXIYvGM&t=359s
It's an alternative android store https://en.uptodown.com/aboutus/uptodown
>Another example were various driver tweaks/hacks or anything else a gamer or power user might want to do.
Never saw a driver hack a power user might want to do.
What were you using Linux/macOS on if not a PC?
https://gru.gq/2020/10/18/ransomware-prohibition/
"The current situation, where there is no criminalisation of payment has created a market place where a number of companies working with insurers are handling the vast majority of ransomware incidents. There are crisis responders who help the companies recover, who arrange a minimal payment, and who get paid by the insurers. This is market governance and it keeps the prices down because there is a sort of gentlemen’s agreement between the gangs and the payment companies. Also, the lack of prohibition means these companies operate in the open and they can share information about pricing etc internally and with each other. (Transparency)
The status quo is not the ideal world, but it is far better than the nightmare of ineffective partial prohibition."
The difference is obvious: not handing the mugger your money is an immediate threat on your life. You won't die just because you didn't pay a ransomware operator.
> And is it also illegal to pay kidnappers?
The article already answered that: in some countries, it already is. "[...] In response to a wave of kidnappings by organized crime, Italy prohibited ransom payments in 1991. Colombia and Switzerland have also made ransom payments illegal. The Group of Seven has a long-standing policy of refusing to pay ransoms for hostages of terrorist groups."
There are exceptions for Fear for your life situations. Which is why paying a mugger is legal.
Anyone who is paying a ransom is literally paying a ransomer to do that to someone else. Not in a metaphorical sense. You are literally transferring the ransomer money which the ransomer will literally use to finance the next ransom. They will pay out of pocket for the person doing the next ransom to go and do it. It should be totally illegal to finance this.
You charge your own acquisition cost against the profit from your custom, not the next guys’ cost. In the case of crime you have paid them to hack you, not others.
The scammers can hide, but their bitcoin money can be tracked forever and interacting with the real world in significant sums requires giving up anonymity. It seems very easy for wallets to access a database and alert their user that they're about to purchase tainted bitcoins.
If bitcoin dies because it's only used by thieves, extortionists, and cartels, then it deserves to die. I don't think the majority of transactions are of that sort though.
That's not the point. Any bitcoin coming from these accounts should be poisonous and any account ever receiving coins tracked back to that account should be fined plus repay the bitcoin value (receiving stolen property). is what would destroy bitcoin.
Criminals use a variety of money laundering techniques, such as "tumblers": big buckets where you put in both legitimate and illegal transactions and get back an unidentifiable mix of both. But I'm sure a lot more cleverness is happening.
The network could and should be built to adapt to such potential attacks. Spamming transactions (essentially a ddos attack) should be banned anyway.
Accidental receipt of stolen goods isn't a crime if you immediately turn them over to the police. People could forward all those coins over to a law enforcement account and receive no penalties while the sender would lose money without gaining anything. This too could be automated.
The problem you mention comes up in the other direction - I am a money launderer and I have some bad BTCs. I can use the UTXO system to mix it with good BTCs I control, creating questionable BTCS. This is is why there was recently news of bitcoin mixers being fined: https://cointelegraph.com/news/us-financial-watchdog-fines-e...
Only if these tiny fractions are actually used. When you send something to a Bitcoin address, what you are actually doing is creating an unspent transaction output which can only be spent by that Bitcoin address. Nothing prevents the wallet software from ignoring that tiny fraction and instead using a larger unspent transaction output to the same address, which would result in a smaller transaction (one input instead of two, since the tiny fraction most probably wouldn't be enough for the transaction).
edit: fix wrong link
There needs to be widespread buy-in from many countries at a granular level for it to be particularly successful. Otherwise bitcoin makes it too easy to turn day-trading into laundering.
But how do you get your idea working? The whole point of bitcoin and crypto is that its decentralized. Even if governments bought in, they cant stop individuals
Imagine you try to buy something and are greeted with "The US government has forbidden access to your account due to it containing bitcoin involved in criminal activity. Go to blah.gov to see what you can do to unfreeze your account and try again". You go there and find out you have to turn over X bitcoin to unfreeze your account and maybe get a recommendation to get a wallet app that can alert you before you get bad bitcoin.
After just one time, most people will move to something that makes sure it never happens again which will trickle down into bitcoin to bitcoin transfers too and stop these illegal transfers in their tracks. Extorters will move to other means of payment which will either be easy to track (physical payment or traditional money transfer) or some super-volatile coin where they're very unlikely to get a meaningful payout.
It seems to me that logic only works when attacks are expensive. With something like kidnapping, you couldn't possibly kidnap 1000 people in the hopes of getting a single $10,000 ransom payment.
But with malware, where launching an attack costs almost nothing? Attacks could still be profitable even if only 1 in 1000 victim pay up.
Same as with spam - the simple solution is that spam (mail/email/calls) are charged to the operator/provider - I can assure you that a solution would instantly appear whereby the providers would take great care about blocking spam at its source.
The status quo in both cases is just to "solve" (but not really) the problem with the cheapest, shittiest possible solution.
This will have the effect of reducing the number of cases of ransomware that law enforcement sees. Not by actually reducing the cases, but instead by making it untenable for a victim to notify law enforcement.
<rant>This is unfettered metric fetishization -- the idea that a problem can be quantified as a metric and when the metric is reduced the problem is reduced. The map is not the territory, you can't just look for your keys where the light is good, the bed of Procrustes, etc. Or maybe it has nothing to do with this and is just a well-intentioned but stupid idea.</rant>
How this author extrapolates this to "let's put the victim of any kidnap/ransom through hell" is beyond me.
Implementing a maximum legal payment amount and mandating that all ransomware payments’ TXIDs be reported to law enforcement would be a reasonable compromise in my opinion.