Re: Why do we have to keep paying for something, time after time after time?
What? Never heard of rentals?
16605 publicly visible posts • joined 10 Jun 2009
"Oh! The humanity! I have to put this stuff down! I really don't have 15 seconds spare in my day to do this!"
NO, because there are many reasons why you don't want to put that stuff even for five seconds, one of the most common being bad weather. Do you really want to put your bags on the wet ground (because it's raining pretty hard and your car's outdoors--and I don't trust even plastic bags to be watertight)? Or how about on a slope because you're parked on a hill (Ask someone say in San Francisco), where the mere act of putting them down runs the risk of things escaping downhill? Or maybe it's the wife busy with an infant and other kids?
So basically, we're screwed. Any form of remote communication can never be sufficiently secured against a sufficiently-determined adversary (like a government-backed evil twin). Plus the malcontents are taking advantage of the very things that make our forms of communication useful (like anonymity), so there will never be a solution that doesn't carry significant collateral damage. Stateful Internet means Big Brother. Whitelists mean you can't receive truly useful stuff from newcomers, and registries can be subverted or hacked.
The problem here is that a PR system would swing the influence to the most populous parts of the country: the dense cities.
Frankly, I don't think a single system will be sufficiently satisfactory. Like the Connecticut Compromise, you need multiple systems. In this case, three. Count the votes three times: by person, by district, and by state: best of three wins. This can help to keep the influence of sparse rural states while still allowing for two more granular measurements.
"No. With a larger population, the number of districts, voting officials and observers just has to be increased so that each district still covers about the same number of voters. And with a larger population you will have a larger pool from which to select those officials."
All of which costs money. Try doing all that from the same shoestring budget...
"No, human counting of ballots only please. Sure you could have the odd bad actor, but arranging for an army of them is a lot more difficult."
Even with the kind of size and clout the major political parties can bear? Does the term "political machine" ring a bell back to the old Gilded Age? Wasn't the pursuit of nonhuman ballotting the result of the corruption of the human ballot process, regardless of its supposed safeguards?
"Are men really that hopeless at cooking? Surely not. Even if they were, they could use a single app, plus Apple Pay, to have the food cooked for them and delivered to their door."
What if they DON'T have Apple Pay...or their accounts are empty? If all you've got to work with is in the kitchen, desperate times and all that...
"If i suddenly need to know the time in the kitchen there's a clock on the kitchen wall, a watch on my arm, a clock in the microwave...I don't need that many clocks in one room."
Except how many clocks are actually displaying time (instead of having a dead battery or blinking 12:00) and how many people actually wear watches these days because it sweats their wrists?
"...has to be cryptographically secure."
But worse comes to worse, the TLAs can dirty the communications channels to be sure the process can NEVER be cryptographically secure: turning it into a DoS attack. IOW, if they can't sniff the channels, they can block them instead, which amounts to the least-bad scenario for them.
Don't think compromised. Think subverted either with or without the authority's knowledge. And as long as one is there for them to subvert, they can just block all the rest so that there's a chain of one who can give all the correct signals...don't trust him, you don't trust anyone and it becomes a DoS attack, so it's lose-lose.
"(As an aside the current issue with CPUs is that the care of design needed to defeat covert channels done for the RDRAND instruction needs to be repeated throughout the CPU design for other instructions.)"
Well, one problem with that approach is that these CPUs are more often being put into portable applications where power isn't a given. In which case efficiency trumps security unless you can achieve both (which last I checked, you can't; efficiency inevitably leaves tells).
"so while, yes, one single person can't be certain that the CPU doesn't switch completely predictable bytes in place where the USB provided random bytes should be, as a community we can be reasonably sure it doesn't do that; can't say the same of the built-in RNG"
HOW? Particularly against something of state-level resources like a TLA? If they can hide corrupt RNGs in a CPU beyond the ability to detect even via things like x-rays, can't the same technique be used to corrupt any other I/O stream? After all, things like heartbleed and shellshock got past "the community" for a long time, too. For all we know, something like this has been a black project since before it was even a concern to us.
"Done already in the 1980's for the VIPER architecture, a simple 32-bit CPU."
But there was some controversy over whether it really was formally verified, plus you still need to defeat a state-level actor who could get some things slipped into the mask after the original is verified.
No, what we would actually ACTUALLY need is a solid way to be sure what we asked for is what we're actually getting, even in hardware (since we know state-level adversaries are now working at the bare metal level). Some form of authenticity checking that can't readily be faked because it relies on physical phenomena like quantum. Trouble is, I don't think that's really possible for something as complicated as a processor; there are too many "parts" that allow ways for a fake to get through.
Problem is, that first step is often the hardest, as the top brass are often the LEAST likely to approve of ANY security plan, seeing as how they need to get to the crown jewels anytime, without notice (in their perception) in order to keep the business going. They basically can't see it until it hits them directly, by which point it's probably already too late.
Recipes are probably a clue as to cultural background or maybe even ethnicity, since these kinds of things tend to begin with local ingredients and get passed through the generations if they don't stick to regions. Consider: Not too many people not of German background would probably carry a spaetzle recipe. Fewer still that AND a rouladen recipe, etc.
"For executives, make receipt of *any* bonuses contingent on same."
Chicken-and-egg question: How do you enforce rules on executives when it's the executives who make the rules...and often are the ones who demand exceptions or replace the IT people with those who will? And note, this is not as rare as you think.
"Been there, had local bank closed, online version became a complicated mess that didn't work with script blocking and barely worked without. So I looked around for a bank with a local presence..."
And for many, there isn't any, or the only bank(s) around have that same sucky online interface, and since most employers insist on checks or online deposits to more easily fulfill their bookkeeping and tax obligations, it's kind of hard to go without.
And who controls that update service? The OEM, not Google. That's what I'm talking about. Google can't force security updates onto older phones because Android had to go through the OEMs before they can be released at all. Thus all the EOL complaints. It gets worse when SoC component manufacturers refuse to update their blob drivers (and they will NEVER open-source them for stiff competition reasons--they could always move on to IoT if push came to shove). Thus the transition with Nougat and so on. By placing more of the core of the OS under Google's direct control, they have a better chance of pushing security updates regardless of the will of the manufacturer. This also allows them to work around recalcitrant component manufacturers. With better control of the core, they can work around blob driver issues.
Since I'm going at this more from a layman's perspective, perhaps I can explain.
1. Imagine your walk into a bar with a pint glass and find everyone drinks their beer by the liter. Sort of a "When in Rome" kind of situation. Which would be easier: getting them down to your level or adapting and fitting in to theirs?
2. RFC791 was necessarily constrained due to the limits of computing technology at the time (think 1MHz processors and where kilobytes were at a premium). It's like the whole "640K" thing. At some point, reality eclipses the imagination, at which point it's time to start fresh.
3. The IPv6 packet format isn't so much more complicated as it is different. It's like an Englishman suddenly getting thrown deep into China. You're just going to have to sit down with the specs and work this bit by bit, much like a language course. One thing about IPv6 is that its most basic header just gets down to the nitty-gritty. The rest of the stuff is optional. Wikipedia provides some relatively simple descriptions and diagrams. Compare IPv6's format to IPv4's. As for the 128-bit address format, that's future-proofing. It's not the first standard to even use it, either (look up ZFS and its thought process for using number formats that large). Current theory is that there aren't even that many molecules in the entire universe. So there's room to solve that other problem I've been mentioning but your system never addresses (complicated routing tables--that MUST be addressed from the root to be effective or you just have TWO complicated routing tables to mess with)..
"Imagine a world where the mandatory standards on radio modulation (AM!) and television signal encoding (analog!) were still in force."
Odd. I don't see anything that demands that standards don't change as the need arises. Thus NTSC makes way for ATSC and so on.
"Standards belong in real safety situations"
Handling electricity tends to count as a safety situation. I've had a couple of cheap USB cable suddenly get pretty hot as wiring began to short, so I'm aware that even things like 5V power cables can get pretty dicey.
That's only possible with local-only apps like a text editor or a sensor reader. Anything interactive MUST collect data as a matter of course, and usually use that data. There's a lot of potential for weaseling just from that, no matter what laws you put in place.
The ONLY way you can prevent something like an e-tailer from collecting and PII is to trust a third party to do it for them. But that just shifts the burden, resulting in a "Quis custodiet ipsos custodes?" situation, which last I checked is an intractable problem. Commerce requires trust at some point, and that trust can always be betrayed.