rphlx

people vote

The "high taxation is not slavery, because you voted" argument lost all merit once net recipients of the welfare state became able to out-vote its net contributors - which has already happened in the US.

make sure old people don't starve

If only that were what the extent of what social security actually does. But it's not properly asset tested. So broke millenials are paying a ton of payroll taxes, which are - after substantial adminsitrative overhead - transferred to their elders who almost always have significantly more assets than they do, and often don't even need a transfer at all, let alone as their only way of avoiding starvation.

Slavery was not fully eliminated in the US; it was just fractionalized, and the terms - which groups are enslaved, which groups are entitled to their output, and how much of it, etc - were obviously heavily modified. For instance you are able to change employers now, but no matter which one you pick - even if it's your own firm - in most highly-valued fields 40-70%+ of your output will be taken by various layers of government - by force if necessary. Your children are subject to the same obligation so "fractionalized chattel slavery" is a decent first-order description.

It is true that acts of extreme violence are less common than they were in the 19th century South, but that alone does not make the system "not slavery" given that a threat of overwhelming force still underpins it.

It's not legal for Americans to completely avoid taxes simply by operating in a jurisdiction with different tax laws.

This is not correct, and pretty much all of the US Elite, above a certain wealth level, have some offshore structure(s), because there actually are major, legal benefits - including ones that can zero out the US individual tax liability for that activity, at least in some years.

As a result it's only the legally- & financially- relatively unsophisticated middle classes, and perhaps the lower-upper-class, that has literally every single transaction subject to US taxation.

If the untoward event is solely in USD, perhaps, but not if it's in crypto. Exit scams, hacks, rogue employees, etc, could still hit a US exchanges' crypto holdings and the government probably cannot or will not compell a roll back, supply expansion, etc, on a major blockchain.

If anything is actually protecting clients against crypto theft, it's the exchange's privately-purchased insurance rather than the government. Although I wouldn't rely on that for much either as insurers are rarely eager to pay out.

I believe they valued at time-of-transaction. e.g. if you had no other transactions except for a $100 buy in 2013 that you immediately withdrew to personal cold storage, and then that appreciated to $20k+ today, you shouldn't have been included, assuming they supplied only the minimum amount of info legally required.

It doesn't necessarily tax everything but the IRS does seek God-level knowledge/insight into every transaction - and then it just exempts certain things based on size or other factors. If you are deducting charitable contributions to the church they actually do expect you to subtract out the value of coffee, meals, etc. Donate $100 to some non-profit that sends you a t-shirt as a thank-you? Your deduction is $87, not $100, because the t-shirt has to be valued at $13 or something similar that they consider reasonable. Somewhere they actually have federal employees tasked with determining this year's acceptable minimum value for a t-shirt.

The $20 gift from grandma is exempt, but not because they don't demand insight into intra-family transfers.. it's only non-taxable because of its size. If you have a rich grandma and she gives you $20k, that needs to be reported.. even if no tax is ultimately due, it probably reduces the future value of her estate tax exemption. Dying is a very complex taxable event!

If you want to follow the thousands of pages of rules to the letter - sufficient to sign a letter declaring under penalty of purjury, etc - the tracking and compliance burden on many US taxpayers is enormous, even with assistance from the commercial closed-source SW packages that you are more or less forced into buying each year because they won't let you e-file with them directly over HTTPS+JSON or whatever.

AFAICT the risk/reward for this change (and others along the same line) is poor, because like it or not, as a factual matter, there are many tens or hundreds of millions of notionally "open source" devices that will never get an updated Linux/BSD/... kernel. Most of them are probably Android phones but there is also a giant tail of consumer routers, EOL'd network equipment, etc. A lot of this stuff will stay in use until total HW failure, which may be a decade, two decades or more.

There are of course also many closed-source products that will never get a TCP/IP stack update. I haven't tested it but I doubt Win7 will ever be able to reach 0.1.2.3 over the public internet. Even if that's a bogus example, you get the idea: millions of dollars worth of old closed source gear out there where it's impossible for the owner to patch the TCP/IP stack.

As a result, to prevent strange connectivity problems on 0.X% of their connections, almost everyone will pay (and, if needed, significantly bid up) the ~$20/yr "normal" IPv4 address cost to get an existing "non-reclaimed" IPv4 address instead of taking a gamble on one of these new ones that will definitely have problems with many other hosts. In short I don't see a voluntary rational buyer or user until the IPv4 market rises 10X+ and probably more like 100X+; until then they seem like more of a liability than an asset given how annoyingly long it will take to retire (or somehow otherwise ensure that you'll never need to talk with) non-updatable IPv4 hosts.

Not that I like this, or am trying to defend or justify it, but I think it is an accurate assessment.

TLDR: pretty much everyone will actively avoid these addrs given that millions of hosts will never be able to reach them.

This is not a complete, imperfect, optimal, uncontroversial or always-trivial-to-implement list, but some common ways to increase attacker costs are to:

0. Put a CAPTCHA on expensive/abused functionality.

1. Rate-limit costly transactions to 1 per hour/day/etc (whatever's appropriate) per IPv4 address.

2. Limit total amount of data added to the db per time period per IPv4 address.

3. Iff you get a lot of abuse from VPS/cloud providers, block or even-more-severely-limit their published IPv4 ranges. Generally speaking a normal user will not write to a pubkey db from a cloud IP.

4. Iff you get a lot of IPv6 abuse, either go IPv4-only (no doubt this will make some people super-mad.. but when it's the only way to keep the service operational..). Sometimes treating every /64 as roughly equal to one IPv4 address is a sufficient defense.

5. If you don't like using IPv4 as the scarce good, then use some other primitive such as SMS verification of a phone number (that may be unacceptable for sks due to obvious privacy and highjacking concerns.. but it's basically what Signal does..)

6. Users (and environmentalists) will hate it, but if all else fails, require proof-of-work/hashcash. Periodically expire keys that didn't submit a $1-10 POW ticket each year, etc. Or an equivalent minable cryptocurrency payment.

The solution there is to have the app use line buffering rather than a "raw" term mode that exposes inter-char timing on the network. How widely that's followed in practice, I do not know, but one would certainly hope that sudo does it.

If you really cannot use keys, then one mitigation is to use copy/paste to paste the entire password instead of typing it one character at a time. That can open some copy/paste vulnerabilities e.g. in X11 where any app can then read the password until you copy something else in its place. And a network observer may still determine the password length. But it closes the inter-key timing channel that permits direct character recovery.

Right - I believe the whitepaper says it'll be a mix of bank deposits in various currencies plus short-term government securities. Still my point stands: you can have lower systemic risk in a serious crisis by holding t-bills or whatever directly, rather than indirectly via FB or any other stablecoin provider. Plus you'll get the interest payments.

Storing serious amounts of money in any of these stablecoins for any real length of time is economically irrational because by exiting their walled garden, you can obtain a higher return in exchange for reduced risk. Withdrawing is even better than a risk-free reward; it's a risk-reducing reward.

In the US the evidence for a central bank PhD Politburo "preventing" or even "minimizing" financial disasters is dubious at best. Financial panics in the 19th century were generally shorter, less frequent, and probably effected the avg citizen much less, than 1929/1937/1970s/2000/2008.

This seems to be a false either-or because FB is probably not holding 100% reserves as actual paper cash in a giant Scrooge McDuck vault underneath their HQ. It's holding them at a bank, so that it can get the interest payments.

Thus, a user faces systemic banking system risks plus all firm/stablecoin-provider risks. That combined risk will almost certainly be strictly larger than the systemic banking system risk you'd face by just depositing funds in a bank account that you directly control.

That may be the protocol at launch but the protocol can always be changed/hardforked, including (as an extreme example) to just centralize the system into VISA/MC style db at FB after achieving wide adoption.

AFAICT power ultimately rests with whoever can modify the most widely-used consumer SW implementation, which would probably be FB here. Though Apple and Google may have considerable veto power over updates pushed through their app stores, iff FB makes this primarily a cell phone app instead of a web app.

Though not as bad as Win9x it definitely had some frag-of-death/ping-of-death vulns around 1997/98. teardrop et al.

When was the last time Linux had a similar, reliably-remotely-exploitable kernel panic in the TCP/IPv4 stack? Pre-2000?

They use a different TCP/IP stack which implemented SACK without introducing this bug.

It's a Linux-specific implementation defect, not an intrinsic problem with the TCP SACK wire protocol or spec.

that's just how the internet works

Well, the Internet does not strictly require all traffic between two parties to go through a MegaCo Cloud. Location privacy in this system would appear to be greatly enhanced (vs Apple-as-an-adversary) if A and B communicated directly, or through a server that they controlled, instead of through iCloud. In concise security terms, Apple man-in-the-middles the encrypted traffic in this system and thus may perform traffic analysis, deanonymization-via-inference, etc as I said above.

It's certainly true that NAT, firewalls, and a lot of other things make direct communication between two iDevices inconvienent and frequently impossible - that's fine and fair enough. But then the Company should not be making at least partially untrue privacy and anonymity claims that are essentially impossible to satisfy when by design all of the traffic flows through their cloud.

AFAICT Apple (and likely its host governments) will still need to be trusted parties in any scheme that flows through their infra, unless you care only about protecting your precise location, and are willing to expose your coarse location to them.

To be clear, they may already have that info from other services, and you'll have to trust Apple a lot anyway since they're making the phone and some custom silicon within it. And them having coarse location is certainly preferable to them having precise location data - so this system (as we are inferring it to work) is not worthless, and is still an improvement over a naive implementation.

But real internet anonymity and location privacy is hard to achieve; just ask any tor developer. So please don't let the marketing dept openly claim that, or even imply that, when the claim can't realistically survive a two minute security audit by HN infosec nerds. To be specific the WWDC claims that "this whole interaction is ... anonymous" and "there’s no need to worry about your ... privacy" are what I am taking some issue with here.

The Wired article is not detailed enough to definitively poo-poo this scheme, but I am pretty skeptical about some of the claims, given a) how easy it is to map an IP to a coarse location, b) how easy it is to map many IPs to a small number of already-known humans/users.

That is to say: the asym crypto may strongly protect the precise (GPS or LTE triangulation) location from Apple and from others, but I do not see how a cloud-based system can ever hide coarse location from Apple and/or from governments as, given the short range of BT, they can reliably infer that a device (and hence its owner) is/was near whatever IP sends the encrypted precise location to their cloud. Then it's just a matter of mapping the device's "randomized" ID back to an actual user/phone. That seems easy enough as soon as a second device accesses it from an IP that's mappable to a specific residential address, Apple account, etc.

e.g.

A and B both log into iTunes or some other Apple service using a@apple.com and b@apple.com from HOMEIP at some point in the past. HOMEIP is never used by any other Apple accounts.

A(lice) and B(ob) exchange a secret and otherwise begin participating in this "private" tracking scheme.

A goes out shopping and while there it pushes its encrypted precise location to the Apple cloud, using random ID 424242, from MALLIP. Perhaps A's device sends it directly, or perhaps it's relayed from BT to Mall wifi to Cloud by C's device if A has both LTE and wifi disabled.

A few minutes later S(omeone) requests encrypted location for random ID 424242, from HOMEIP.

Apple (and any government compelling it to share information) can reliably infer that "Someone" was A or B attempting to track either B or A, and that the tracked phone was at/near the business address of MALLIP - their coarse location - even if they can't decrypt the precise location without the secret key. If you know from public records that A and B are married, and assume that women are more likely to be at a mall on their own than men, you may further assume that A is at the Mall while B is at home.

Result: the "private"/"encrypted" precise location beaconing has an unfixable metadata side channel that will leak coarse location data to Apple and to any governments that compell it.

That's a good idea, though I would still prefer to understand their detailed CPU% abuse criteria pre-deployment rather than via just-try-it-and-see-what-happens. Secret rules are a problem, no matter if the enforcement is automated, manual, or some hybrid of the two.

They don’t care if you use 100% of CPU

They clearly do, at least for some subset of customers meeting various quasi-secret criteria.

they don’t want you to do is use 100% CPU and not pay the bill.

The account here was fully paid up, albeit via credits that they issued rather than via USD. Regardless, it was not past due, so, the high CPU% was the mortal sin.

Indeed, but AFAICT there are apparently still some opaque, undefined CPU% limits for people paying with CC instead of free credits. They also mentioned elsewhere that customers paying via PO are exempt from the automated miner murderer, but that was was news to me and I guess just furthers my point: we shouldn't have to trawl HN threads to understand your CPU% abuse limits; they should be spelled out specifically and quantitatively in the main TOS, for each type of payment method, and any other factor(s) that effect them.

I don't think there is a single cloud provider that accepts unlimited liability and wholly compensates customers for lost data, lost sales during downtime that was the provider's fault, etc. Their liability is generally strictly limited to the cost of service... so something like a $1 credit for the 6 days that your $5/mo VPS was down. Unless of course you are a very large customer that credibly threatens to switch, at which point you may get some special treatment above and beyond the TOS, though even then, rarely enough to fully recover your actual loss..

Ultimately if there is a lot of money on the line you need to do the work and pay the money to be multi-vendor, automatically failing over to AMZN or MS or DO or whatever when there is some massive screwup that takes down GOOG for half a day.

Their apparent conclusion that high CPU% for a few hours or half day or whatever means "cryptocurrency miner - ban ASAP!" is naive and flawed.

Compute offload is an ancient and fairly common use case for the public cloud; my VPS (or ten..) should be able to burn 100% CPU for many hours compiling a large project, even if it means they make less profit than they would have had I instead run a static web server that sleeps on IO, imposing nearly no CPU load.

At the very least they should provide some objective, quantitative guidance on exactly how many CPU-seconds-per-hour they consider acceptable/not-abuse (or, if not CPU-seconds, then increased host power consumption, or whatever they are ultimately trying to limit to ensure they can pack a few hundred near-zero-load servers onto the same host to make glorious truly massive profits all the time).

Don't make customers guess at whether their workload will trigger some opaque but hyper-aggressive abuse automation or not.

FWIW deb9 installs both 3.5 and 2.7 by default.

FWIW Win10 was affected by that same horrific SMB RCE vuln. So the implied argument that 10 has been immune or even much less vulnerable to ransomware over the past year or two is on shaky ground, though I agree it probably will start to have some merit going forward.

These days it would probably make more sense to just require a small cryptocurrency payment in place of hashcash. There are some obvious adoption and scalability issues with that but it may be workable as a prioritization mechanism.

For some further, semi-amusing support for the title's assertion, save all of your work, close important programs, and then run 'sudo systemctl --dry-run reboot'

I reject this premise that every CoC must "promote inclusion" i.e. be approved in full by some social marxist Politburo notionally intended to protect everyone's "feelings" by expunging and banning everything that might be considered "offensive". If you want that for your own project, fine, but you have no right to force it onto others.

In any case, western civ has deep roots in the christian tradition and I don't know any atheists that are so extremely fragile or sensitive that they are "offended" by simply seeing people repeating 1500+ year old fragments of it. Especially when they use the disclaimers that were used here.

I have to quibble with that a bit. The US regularly overflew the USSR and China through at least the mid 70s, meaning our best aircraft were in a very real sense fighting their best air defense systems 20 years+ after the Korean war ended.

There have almost certainly been satellite, submarine and other engagements too, they just aren't generally publicized by either side until 30-40+ years later.