Straight keyboards are really poor ergonomically, but I do love the mechanical feel of these old IBM models (and their newer imitators).
Might as well use this as an impromptu Ask Slashdot: are there any ergonomic one-piece mechanical wireless keyboards out there? I periodically Google for it (to replace an old Logitech one that's nearing EOL after a decade or so) but have never been able to find anything suitable.
Pistols, however, are used by criminals, by people committing suicide, and by kids playing around with them. As a direct result, over 30,000 people die every year after being shot with a pistol.
This is an example of a truthful but not useful statement. Yes, 30,000 people die every year as a result of being shot by a pistol. According to the CDC, in 2010 there were 11K firearm homocides and 19K firearm suicides.
That's a big difference in perspective, since a regulation that might be justifiable to prevent an individual from shooting his wife or neighbor might not be justifiable to prevent him from shooting himself. It's not dispositive, of course, but society has a much larger interest in preventing individuals from killing each other than killing themselves.
Do these bags simultaneously keep the phone powered on while preventing the internal clock from advancing? If so, I think there's some folks in Sweden that would like to award the creator some very nice jewelry.
Too bad for "standard forensics" that the passcode is mixed in with a hardware-specific key baked into the SOC. So you'll first need to be able to run arbitrary code on the individual's phone itself in order to keep guessing beyond the limit. That's going to require a significantly more intrusive examination.
Self incrimination has never applied to physical evidence that the individual has in his possession, it only applies to things that are "testimonial" (quotes because this is a term of art). After all, the 5A specifically talks about being a witness against one's self, not about providing evidence. See also Fisher v. United States, 425 U.S. 391 (1976), Schmerber v. California, 384 U.S. 757 (1966) and United States v. Wade, 388 U.S. 218 (1967).
The classic example is business or tax records related to fraud prosecutions. An individual served with a valid order cannot refuse to turn over documents because they would tend to incriminate him, that doesn't make sense. You can't force the individual to testify to anything, but you can compel them to produce physical objects that you have probable cause to believe are evidence relevant to the prosecution of a crime.
Another canonical example is a court order forcing an individual to provide a cheek swab for a DNA test. Again, not testimonial because it's not communicative in any way -- you are just talking about physical, tangible evidence.
In combination with iCloud credentials obtained with iBrute, the password-cracking software for iCloud released on Github over the weekend, EPPB lets anyone impersonate a victimâ(TM)s iPhone and download its full backup rather than the more limited data accessible on iCloud.com.
So basically, in combination with your password, this tools let's you access resources secured by your password. Amazing! Next up you'll tell me there's a tool that lets you open my front door in combination with a copy of my house key!
Let's put this another way -- you tell some/.er that he can buy a new iPhone, enter his password and immediately restore from an iCloud backup. Logically then, we expect that he understands that the password controls access to the backup, since the only thing he needed to provide was that password.
Which is why clamd should provide a systemd.socket, unit in which case the init system installs the sockets and then hands them off to the spawned process as soon as the respective daemon is to be started.
It's just as easy to to do this in systemd as it is to bung together shell that does it, but it's not as familiar. In a few years, most system admins will be able to mash out a systemd.socket unit in their sleep.
An acquaintance recently posted "Six Stages of Debugging" on his g+ page. (1. That can't happen, 2. That doesn't happen on my machine, 3. That shouldn't happen, 4. Why does that happen? 5. Oh, I see, and 6. How did that ever work). Doesn't an software dev who has been working for more than about three years go straight to No. 4?
Absolutely true for debugging. But there's a few steps you missed.
Somewhere near 3-4: Ok, how bad would it be if that happened? Does it recover without user intervention (i.e. service crashes and cron restarts it)? Does it recover with user intervention ("did you turn it off and back on?)? Does it lose user data (oh poop)?
The question here (which is altogether not trivial) is exactly this: "how bad would it be if we wrote an extra '\0' somewhere"? And what geohot did was answer that in the most productive way possible - by actually showing with a real example that the impact is major and permanent. If you aren't explicitly doing assessment of the impact of your bugs for schedule/priorities then you must be doing it implicitly somehow because most projects have more bugs than coders/time.
There's another step you missed, happens probably at step 10 or 11 and probably not by the developer that fixes the bug -- given the impact and the risk of the fix, when/how should this be deployed? Should it be backported to the stable releases? Do we have to ping everyone downstream? Is this so bad we should post on/. telling everyone to pull the emergency fix ASAP or else zombie Putin will kill Natalie Portman?
Again, if you aren't doing this step explicitly, it's either happening implicitly or else you are just letting it land whenever/however.
The (heartless) thing about it is that drugs are not too different from many other things in society that are used by rich and poor alike but harm the latter much more.
The rich are far more likely to own firearms than the poor and far less likely to shoot someone or be shot. The rich buy far more alcohol than the poor but are far less likely to drive drunk or be alcoholics . The rich do far more drugs than the poor but are far less likely to become non-functional addicts. The rich are far more likely to waste their education on party schools than the poor but are less likely to suffer the career consequences. The rich and the poor engage in about the same amount of premarital sex but the former are less likely to have kids out of wedlock. The rich gamble more often than the poor but are far less likely to become chronic gamblers.
To my mind, this suggests that the ultimate cause of these problems isn't the particular vices, but rather the cultural and economic context around them that causes them to be destructive. We should work at fixing that context, along with providing opportunity and support for everyone to work towards their own success, rather than wasting our time on proximate causes.
Hey, I can make all kinds of tasks faster by precomputing much of the work and then looking it up in a table. Congratulations, you've (re)discovered another instance of a Space/Time tradeoff.
Now, in particular what they've done is still wicked cool -- it's a great idea to perform may millions of simulations ahead of time so that at runtime (heh) you can quickly draw on that data to adapt. It would be perfectly good research even without the over-the-top claim that they've somehow made the work faster as opposed to cleverly pre-computing much of it.
But that's research -- you do something neat and then you make a ridiculous overstatement to generate buzz...
No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the.deb. Heck, it was 8 weeks just for the Tor browser.
It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.
tl;dr: it's much harder than just installing an identical version of clang and hitting make.
[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing... ]
If the USA is the bastion of freedom, capitalism and independence, why are cab licenses limited by city bureaucrats? Why not let everyone who qualifies swim in the taxicab business leaving those who cannot stand the waters perish? I just don't get it!
Because historically taxis have engaged in a number of fraudulent and unsavory practices, outright racism in some cases and have generally made cities look bad. So there was a legitimate reason to regulate them in order to ensure that they didn't bilk (or take the long route) for gullible tourists, refuse rides to people of the wrong color, install fake meters, organize into a racket to overcharge customer or skip on carrying decent insurance.
Then, lo-and-behold, the well-meaning regulators were captured by the taxicabs (because they were smart) and turned around and instituted any number of illegitimate regulations designed to stifle competition. This is generally pretty easy in a democracy because when there's a small number of cabbies with a very large interest in certain policies, they can often get their way when there are a large number of citizens with contrary interests. It's the law of diffused costs versus concentrated benefits.
So now, instead of being predictably idiotic with our left/right pro/anti regulation, maybe we should think about stupid regulation versus smart regulation. Then we could distinguish a rule require cabbies to carry insurance for their passengers with one that limits the number of medallions to some artifical number. Or one that requires accurate metering of any form with one that requires a specific brand or type of metering. Or a law that requires cabbies to serve any part of the city with one that requires them to drive home from the airport empty instead of picking up a fare immediately after dropping one off (this one really I don't understand -- there is a line for cabs at the terminal!).
On the other hand, nah, let's just hurf about it....
Part of the problem is that it's easier to hire new folks than to reallocate existing ones without getting into political turf wars -- let alone shrinking some departments* that don't need the headcount. This means that the utility of a new employee is automatically greater than one that's been there forever, even if they are equal in skill, just because they can be put in the most useful position.
This is a facet of downwards-stickiness -- it's easy to tell an overstaffed* department that they don't get to hire new folks, it's nearly impossible to tell them to give up folks. But both of those are equivalent in terms of overall allocation of resources.
* Note: I don't mean to say that these folks are incompetent, only that demands change and a team that might be stretched thin one year because of a large project might have few demands the next. In fact, it's exactly the opposite -- the most talented teams end up overstaffed because they build things well and end up without much maintenance to do, rather than constantly chasing their tails duct-taping things up. We should be moving talent from those teams to where it's needed the most.
The opinion restricts itself to "closely-held corporations" (a phrase used dozens of times) rather than/all/ corporations. They don't define with precision what that exactly means -- that kind of drudgery is the domain of the lower courts -- they did point out that Hobby Lobby is privately held by a small number of folks from the same family. It would seem clear to infer that "closely-held" is sort of an antonym to "publicly-held" here, so I think there's virtually no chance any lower court would allow Wal Mart or Exxon to assert a RFRA claim.
Now, since companies under 100 employees are already exempt from most of PPACA, the net net of this only covers the rare company that simultaneously large enough to be hit by the mandate but still owned closely enough to merit RFRA protection. In other words, not too many in the scheme of things.
[ Full Disclosure: I don't support what Hobby Lobby believes, I think they deserve to lose on the merits. But at the end of the day, I'm not going to make a molehill into a mountain for rhetorical or fundraising purposes. ]
Public: { H(CC+Salt), Salt, Amount of money spent on porn, Amount of student debt }
[ where + is just shorthanded for "mixed with" ]
It's not at all within the realm of possibility for an attacker to brute force the CC space for each salt separately. So yes, an attacker can run through (2**CC_entropy) hashes to brute force a single entry, but that exercise provides him no help when he goes to do the next entry. Moreover, he can't spin up a few TB of storage on S3 and pre-compute anything useful.
The point of the scheme is to turn a pwn-once-win-forever game into a pwn-one-win-one game. This guy paid once and won the entire database. I would like him to have to pay that cost once for each entry.
But there are very important uses for salting that make it better than assigning a random number -- it allows someone that does know the input value look up the relevant entry without any involvement from the secure side.
Imagine you had the following two datasets that you've partitioned:
Private: { Credit Card Number, Random Salt } Public: { H(CC+Salt), Amount of money spent on porn, Amount of student debt }
Now whenever you want to obscure an entry, you do need to go to private one. But if you want to answer the question "How much money did a person with CC X spend on porn", you can look it up without entering the secure domain. But no one without access to the private side can find credit cards in the DB or other stuff -- to within the computational costs of the operation multiplied by the entropy of the salt.
Yes, which is exactly what the person in this article actually did -- he created a lookup table to accelerate brute-forcing the entire released dataset.
And yes, there are a trillion credit cards. But if each one gets a random 32-byte salt added to it, then that's a 4-billion-trillion input space...
Um, the standard is fine. The phrase "One-way hashes based on strong cryptography" means (to any professional in the business) that one must salt the hash with sufficient entropy to make brute-forcing the input space impossible. So 16 digit CC has little entry, but add a 16-byte hash and you've somewhere.
So yeah, "strong cryptography" can't fix stupid, but those that know how to use it are plenty fine.
East Asia: Han, Cantonese, Korean, Japanese, Indian Subcontinent: Telugu, Tamil, Sinhalese, Punjabi, West Asia: Syriac, Turkmen, Arab, Persian, North Asia: Slavs of all flavors, Europe: Scandinavian, Germanic, Anglo-saxons, Castilians, Africa: Hamitic, Bantu,
Looks pretty diverse to me, at least once you get past the crippling simplicity of the "White/Asian/Black/Latin" universe in which the race-baiters are forever trapped.
I also hate to be the one to point this out, but given a free choice much (not all) of the world population starts consuming meat once given the economic means to do so.
In a world that seems to be lurching towards greater individual autonomy and personal choice, your solution does not strike me as likely to get off the ground. At the end, you'll either have to adopt more and more coercive action to meet your goal or accept that there are billions of independent agents with different preferences.
It's an interesting conundrum. We can at least try to pass laws to prevent our governments from spying us, but even if we succeed we can't very well pass a law forbidding others' governments from doing what they will.
Ultimately, I don't see a solution that's plausible here.
Slashdot Mirror
Straight keyboards are really poor ergonomically, but I do love the mechanical feel of these old IBM models (and their newer imitators).
Might as well use this as an impromptu Ask Slashdot: are there any ergonomic one-piece mechanical wireless keyboards out there? I periodically Google for it (to replace an old Logitech one that's nearing EOL after a decade or so) but have never been able to find anything suitable.
Perhaps stories like this will make clear what the costs of disabling code signing really are, to be weighed against the incentive to disable it ...
This is an example of a truthful but not useful statement. Yes, 30,000 people die every year as a result of being shot by a pistol. According to the CDC, in 2010 there were 11K firearm homocides and 19K firearm suicides.
That's a big difference in perspective, since a regulation that might be justifiable to prevent an individual from shooting his wife or neighbor might not be justifiable to prevent him from shooting himself. It's not dispositive, of course, but society has a much larger interest in preventing individuals from killing each other than killing themselves.
Do these bags simultaneously keep the phone powered on while preventing the internal clock from advancing? If so, I think there's some folks in Sweden that would like to award the creator some very nice jewelry.
Too bad for "standard forensics" that the passcode is mixed in with a hardware-specific key baked into the SOC. So you'll first need to be able to run arbitrary code on the individual's phone itself in order to keep guessing beyond the limit. That's going to require a significantly more intrusive examination.
Self incrimination has never applied to physical evidence that the individual has in his possession, it only applies to things that are "testimonial" (quotes because this is a term of art). After all, the 5A specifically talks about being a witness against one's self, not about providing evidence. See also Fisher v. United States, 425 U.S. 391 (1976), Schmerber v. California, 384 U.S. 757 (1966) and United States v. Wade, 388 U.S. 218 (1967).
The classic example is business or tax records related to fraud prosecutions. An individual served with a valid order cannot refuse to turn over documents because they would tend to incriminate him, that doesn't make sense. You can't force the individual to testify to anything, but you can compel them to produce physical objects that you have probable cause to believe are evidence relevant to the prosecution of a crime.
Another canonical example is a court order forcing an individual to provide a cheek swab for a DNA test. Again, not testimonial because it's not communicative in any way -- you are just talking about physical, tangible evidence.
In combination with iCloud credentials obtained with iBrute, the password-cracking software for iCloud released on Github over the weekend, EPPB lets anyone impersonate a victimâ(TM)s iPhone and download its full backup rather than the more limited data accessible on iCloud.com.
So basically, in combination with your password, this tools let's you access resources secured by your password. Amazing! Next up you'll tell me there's a tool that lets you open my front door in combination with a copy of my house key!
Let's put this another way -- you tell some /.er that he can buy a new iPhone, enter his password and immediately restore from an iCloud backup. Logically then, we expect that he understands that the password controls access to the backup, since the only thing he needed to provide was that password.
Which is why clamd should provide a systemd.socket, unit in which case the init system installs the sockets and then hands them off to the spawned process as soon as the respective daemon is to be started.
It's just as easy to to do this in systemd as it is to bung together shell that does it, but it's not as familiar. In a few years, most system admins will be able to mash out a systemd.socket unit in their sleep.
An acquaintance recently posted "Six Stages of Debugging" on his g+ page. (1. That can't happen, 2. That doesn't happen on my machine, 3. That shouldn't happen, 4. Why does that happen? 5. Oh, I see, and 6. How did that ever work). Doesn't an software dev who has been working for more than about three years go straight to No. 4?
Absolutely true for debugging. But there's a few steps you missed.
Somewhere near 3-4: Ok, how bad would it be if that happened? Does it recover without user intervention (i.e. service crashes and cron restarts it)? Does it recover with user intervention ("did you turn it off and back on?)? Does it lose user data (oh poop)?
The question here (which is altogether not trivial) is exactly this: "how bad would it be if we wrote an extra '\0' somewhere"? And what geohot did was answer that in the most productive way possible - by actually showing with a real example that the impact is major and permanent. If you aren't explicitly doing assessment of the impact of your bugs for schedule/priorities then you must be doing it implicitly somehow because most projects have more bugs than coders/time.
There's another step you missed, happens probably at step 10 or 11 and probably not by the developer that fixes the bug -- given the impact and the risk of the fix, when/how should this be deployed? Should it be backported to the stable releases? Do we have to ping everyone downstream? Is this so bad we should post on /. telling everyone to pull the emergency fix ASAP or else zombie Putin will kill Natalie Portman?
Again, if you aren't doing this step explicitly, it's either happening implicitly or else you are just letting it land whenever/however.
There's already binding precedent in the Circuit that covers NYS.
Tunick v. Safir, 228 F.3d 135, 137 (2d Cir. 2000)
loom v. Levy, 159 F.3d 1345 (2d Cir. 1998).
I'm not sure what another case would prove -- the appellate courts are loath to repeat themselves.
The (heartless) thing about it is that drugs are not too different from many other things in society that are used by rich and poor alike but harm the latter much more.
The rich are far more likely to own firearms than the poor and far less likely to shoot someone or be shot.
The rich buy far more alcohol than the poor but are far less likely to drive drunk or be alcoholics .
The rich do far more drugs than the poor but are far less likely to become non-functional addicts.
The rich are far more likely to waste their education on party schools than the poor but are less likely to suffer the career consequences.
The rich and the poor engage in about the same amount of premarital sex but the former are less likely to have kids out of wedlock.
The rich gamble more often than the poor but are far less likely to become chronic gamblers.
To my mind, this suggests that the ultimate cause of these problems isn't the particular vices, but rather the cultural and economic context around them that causes them to be destructive. We should work at fixing that context, along with providing opportunity and support for everyone to work towards their own success, rather than wasting our time on proximate causes.
The only thing you can cryptographically sign is a binary. The rest is inspection by hand which won't scale.
Hey, I can make all kinds of tasks faster by precomputing much of the work and then looking it up in a table. Congratulations, you've (re)discovered another instance of a Space/Time tradeoff.
Now, in particular what they've done is still wicked cool -- it's a great idea to perform may millions of simulations ahead of time so that at runtime (heh) you can quickly draw on that data to adapt. It would be perfectly good research even without the over-the-top claim that they've somehow made the work faster as opposed to cleverly pre-computing much of it.
But that's research -- you do something neat and then you make a ridiculous overstatement to generate buzz ...
No. In fact it's absurdly difficult to reliably create reproducible builds. Debian has been working on this since at least 2009 (afaict) and has been plowing through issues but you still can't get an identical Kernel as the .deb. Heck, it was 8 weeks just for the Tor browser.
It's not just the compilation tools, it's the entire build environment that needs to be homogenized. All kinds of components will insert uname/hostname and paths into the binary, filesystems list the contents of a directory in undefined order, timestamps and permissions are embedded into tarballs and documentation, different locale produces other weirdness.
tl;dr: it's much harder than just installing an identical version of clang and hitting make.
[ And, as an aside, this goes back decades. The infrastructure around builds was never designed with reproducibility as a design goal. We are basically retrofitting this new requirement on decades of legacy code that never even considered that we would want such a thing ... ]
Because historically taxis have engaged in a number of fraudulent and unsavory practices, outright racism in some cases and have generally made cities look bad. So there was a legitimate reason to regulate them in order to ensure that they didn't bilk (or take the long route) for gullible tourists, refuse rides to people of the wrong color, install fake meters, organize into a racket to overcharge customer or skip on carrying decent insurance.
Then, lo-and-behold, the well-meaning regulators were captured by the taxicabs (because they were smart) and turned around and instituted any number of illegitimate regulations designed to stifle competition. This is generally pretty easy in a democracy because when there's a small number of cabbies with a very large interest in certain policies, they can often get their way when there are a large number of citizens with contrary interests. It's the law of diffused costs versus concentrated benefits.
So now, instead of being predictably idiotic with our left/right pro/anti regulation, maybe we should think about stupid regulation versus smart regulation. Then we could distinguish a rule require cabbies to carry insurance for their passengers with one that limits the number of medallions to some artifical number. Or one that requires accurate metering of any form with one that requires a specific brand or type of metering. Or a law that requires cabbies to serve any part of the city with one that requires them to drive home from the airport empty instead of picking up a fare immediately after dropping one off (this one really I don't understand -- there is a line for cabs at the terminal!).
On the other hand, nah, let's just hurf about it....
Part of the problem is that it's easier to hire new folks than to reallocate existing ones without getting into political turf wars -- let alone shrinking some departments* that don't need the headcount. This means that the utility of a new employee is automatically greater than one that's been there forever, even if they are equal in skill, just because they can be put in the most useful position.
This is a facet of downwards-stickiness -- it's easy to tell an overstaffed* department that they don't get to hire new folks, it's nearly impossible to tell them to give up folks. But both of those are equivalent in terms of overall allocation of resources.
* Note: I don't mean to say that these folks are incompetent, only that demands change and a team that might be stretched thin one year because of a large project might have few demands the next. In fact, it's exactly the opposite -- the most talented teams end up overstaffed because they build things well and end up without much maintenance to do, rather than constantly chasing their tails duct-taping things up. We should be moving talent from those teams to where it's needed the most.
Who ever said that the IRS definition for the purposes of taxation is the correct one to apply to a RFRA claim over contraception?
I highly doubt that the Waltons would qualify, given that billions of dollars of WalMart stock is held and traded publicly.
The opinion restricts itself to "closely-held corporations" (a phrase used dozens of times) rather than /all/ corporations. They don't define with precision what that exactly means -- that kind of drudgery is the domain of the lower courts -- they did point out that Hobby Lobby is privately held by a small number of folks from the same family. It would seem clear to infer that "closely-held" is sort of an antonym to "publicly-held" here, so I think there's virtually no chance any lower court would allow Wal Mart or Exxon to assert a RFRA claim.
Now, since companies under 100 employees are already exempt from most of PPACA, the net net of this only covers the rare company that simultaneously large enough to be hit by the mandate but still owned closely enough to merit RFRA protection. In other words, not too many in the scheme of things.
[ Full Disclosure: I don't support what Hobby Lobby believes, I think they deserve to lose on the merits. But at the end of the day, I'm not going to make a molehill into a mountain for rhetorical or fundraising purposes. ]
Yes, you are right, I mistyped.
Public: { H(CC+Salt), Salt, Amount of money spent on porn, Amount of student debt }
[ where + is just shorthanded for "mixed with" ]
It's not at all within the realm of possibility for an attacker to brute force the CC space for each salt separately. So yes, an attacker can run through (2**CC_entropy) hashes to brute force a single entry, but that exercise provides him no help when he goes to do the next entry. Moreover, he can't spin up a few TB of storage on S3 and pre-compute anything useful.
The point of the scheme is to turn a pwn-once-win-forever game into a pwn-one-win-one game. This guy paid once and won the entire database. I would like him to have to pay that cost once for each entry.
Yes, a secret salt is no salt at all.
But there are very important uses for salting that make it better than assigning a random number -- it allows someone that does know the input value look up the relevant entry without any involvement from the secure side.
Imagine you had the following two datasets that you've partitioned:
Private: { Credit Card Number, Random Salt }
Public: { H(CC+Salt), Amount of money spent on porn, Amount of student debt }
Now whenever you want to obscure an entry, you do need to go to private one. But if you want to answer the question "How much money did a person with CC X spend on porn", you can look it up without entering the secure domain. But no one without access to the private side can find credit cards in the DB or other stuff -- to within the computational costs of the operation multiplied by the entropy of the salt.
Yes, which is exactly what the person in this article actually did -- he created a lookup table to accelerate brute-forcing the entire released dataset.
And yes, there are a trillion credit cards. But if each one gets a random 32-byte salt added to it, then that's a 4-billion-trillion input space ...
Um, the standard is fine. The phrase "One-way hashes based on strong cryptography" means (to any professional in the business) that one must salt the hash with sufficient entropy to make brute-forcing the input space impossible. So 16 digit CC has little entry, but add a 16-byte hash and you've somewhere.
So yeah, "strong cryptography" can't fix stupid, but those that know how to use it are plenty fine.
And this is counting just those around me:
East Asia: Han, Cantonese, Korean, Japanese,
Indian Subcontinent: Telugu, Tamil, Sinhalese, Punjabi,
West Asia: Syriac, Turkmen, Arab, Persian,
North Asia: Slavs of all flavors,
Europe: Scandinavian, Germanic, Anglo-saxons, Castilians,
Africa: Hamitic, Bantu,
Looks pretty diverse to me, at least once you get past the crippling simplicity of the "White/Asian/Black/Latin" universe in which the race-baiters are forever trapped.
I also hate to be the one to point this out, but given a free choice much (not all) of the world population starts consuming meat once given the economic means to do so.
In a world that seems to be lurching towards greater individual autonomy and personal choice, your solution does not strike me as likely to get off the ground. At the end, you'll either have to adopt more and more coercive action to meet your goal or accept that there are billions of independent agents with different preferences.
This.
It's an interesting conundrum. We can at least try to pass laws to prevent our governments from spying us, but even if we succeed we can't very well pass a law forbidding others' governments from doing what they will.
Ultimately, I don't see a solution that's plausible here.