How much of this problem is due to old assumptions about running on real hardware? That is to say the entropy pool is fed from lots of sources most of them system devices. Is this just an unintended consequence of running on cut down virtual hardware platforms?
The researchers specifically addressed virtualization in the talk, providing different measurements of entropy available on real vs virtual machines. Real machines generate roughly twice as much entropy per unit of time, but both generate 2-3 orders of magnitude less than systems consume. However, as I noted in my other lengthy post, it's not clear that this really matters.
Basically there's no proof/dev/urandom is less safe than/dev/random
Yep. As I said, the whole pool entropy measurement concept is extremely conservative in that there are no known theoretical attacks, much less practical ones, that depend on drawing from/dev/urandom when it has low entropy.
Also, there's an ioctl you can use [man7.org] on/dev/random - RNDGETENTCNT - to see how much entropy your system currently has, if you want to play around with it a bit.
Or you can cat/proc/sys/kernel/random/entropy_avail
Note that doing that will start a new process, which consumes entropy, so don't be surprised if it gradually drops over repeated calls.
Sure, some penalty other than perjury could work. Perjury is nice because it's well-defined and already in use in the statute, but it's possible something more targeted would be better.
That seems to be the fundamental problem here. Legislating that no-one can make an honest mistake in this kind of field seems unconstructive, given the inherent uncertainty of fair use and the like. However, legislating that someone can maliciously or negligently make a claim that they should reasonably have known to be false is a different thing entirely, and that seems closer to what actually happened.
Correcting this deficiency seems pretty easy -- at least with respect to the text of the law. All we need is another part that specifies that the issuer of the notice makes a statement under penalty of perjury that they have performed due diligence in ascertaining the correctness of their good faith belief. The courts would have to work out what "due diligence" means in this case, but it's obvious that it would have to mean at least verifying that the allegedly infringing work at least references the allegedly infringed work. So, for example, anyone claiming infringement by a work that was uploaded years before the allegedly infringed work clearly did not do their due diligence.
5. OpenSSL seeds its internal CPRNG during startup and then just uses it, potentially forever, without ever reseeding. Worse, when it seeds from/dev/urandom at startup it makes no effort to check whether or not the kernel pool has any entropy to give it. It just gets some bytes and goes.
That would only be a problem if the boot scripts start up OpenSSL before seeding urandom. Are there any server distros that do that? At least CentOS 6 does it in rc.sysinit, way before the network-related stuff is started.
That only helps if there's some stored entropy to load during boot. There generally is something to load... how much entropy it has is harder to say.
I attended the (very interesting) Black Hat talk, and neither the article nor the/. summary do a very good job of summarizing it.
From memory (I didn't take notes), the key points were:
1. Tracking the entropy pool is a little harder than you might expect, because the kernel itself uses quite a lot. The primary reason is ASLR, but there other ways the kernel uses entropy itself. The kernel is effectively drawing from/dev/urandom at a very high rate, pulling thousands of bits every time it starts a process.
2./dev/urandom vs/dev/random work a little differently than most people expect. There are actually three entropy pools, a "main" pool, a/dev/random pool and a/dev/urandom pool. Both/dev/random and/dev/urandom use the same PRNG, and both try to maintain 0 bits of entropy in their local pools, drawing a block from the main pool when needed and mixing it into their local pools (keep in mind that a pool is many bytes of data plus an estimate of how much entropy is in that data)./dev/random, obviously, blocks when it runs out of entropy in its local pool and there isn't enough in the main pool to satisfy the request./dev/urandom works the same way, except that (a) it won't block and (b) it won't draw the main pool below 128 bits. When the main pool drops to 128 bits,/dev/urandom stops pulling from it.
3. The rate of entropy going into the main pool is low, on the order of single-digit bits per second. For some reason Potter and Moore didn't understand, using a daemon to get bits from the CPU HWRNG not only didn't increase the estimated entropy inflow rate, but actually decreased it (I had to step out for a bit around that point in the talk so I missed details).
4. Points 1, 2, and 3 taken together mean that the entropy pool is basically never above 128 bits. The kernel is always drawing on/dev/urandom, typically at a much higher rate (hundreds to thousands of bits per second pulled from urandom vs <10 bits per second going in).
5. OpenSSL seeds its internal CPRNG during startup and then just uses it, potentially forever, without ever reseeding. Worse, when it seeds from/dev/urandom at startup it makes no effort to check whether or not the kernel pool has any entropy to give it. It just gets some bytes and goes. This means that if an apache server starts up when there isn't much entropy in the pool, that very small amount of entropy could get stretched over a very large number of cryptographic operations. (Aside: I do a little work on and with BoringSSL, Google's OpenSSL fork, and it does reseed regularly, and also uses a more trustworthy CPRNG. I highly recommend using BoringSSL rather than OpenSSL.)
6. Android actually does better than desktop/server Linux, producing many more bits per second of entropy, though still far less than are demanded. Potter attributes this to the rich source of randomness available from the cellular radios.
How much any of this matters is hard to say. Entropy estimation is something of a black art at best, or wild ass guess at worst. Also, the kernel is known to be extremely conservative with at least one of its entropy sources: the HW RNG in most CPUs. Because there's concern the NSA may have backdoored those HW RNGs the kernel assumes their output is perfectly predictable, meaning that it provides zero entropy. The kernel mixes in HW bits anyway, because they can't hurt even if they are 100% predictable, and to whatever extent they're unpredictable they help.
In addition, the whole concept of entropy pools of known size which are drawn down and refilled is an extremely conservative one. Modern CPRNGs are able to produce enormous amounts of uniformly-distributed, unpredictable bits from fairly small seeds -- say, 256 bits of entropy. Assuming the kernel ever manages to get even a
really HTC *should* be responsible since they are the ones that customized it in a way that you could not just take straight patches from Google.
It's even more than that, since the security vulnerability in this case was added by HTC. There are no remote support tools in the base Android platform, and therefore no insecure remote support tools.
It's not simply a case of Google saying "fix it" and shipping patches to every single Android device out there. Google doing that would be like the Debian group trying to ship Debian patches to Ubuntu - it wouldn't work.
Especially since in this case Google had nothing whatsoever to do with the problem. This one is entirely a consequence of OEMs adding insecure extensions to the base platform Google provides. Insecure extensions with root privileges, basically.
For example, there's been the long-running practice of reenlistment bonuses. Different jobs get much higher bonuses for reenlisting.
The base pay may be the same, but the difference between, say, a low-ranking cook and a low-ranking nuclear weapons technician is pretty startling when that bonus is calculated. As in "tens of thousands of dollars."
There is also extra pay for various specific skills. Some of them cut across job categories, for example you get more pay if you speak another language. Others are specific to the job; electronics techs get extra pay, medical personnel get extra pay, etc. People in high-skill jobs tend to get promoted faster and therefore be higher in rank than those in low skill jobs, which also boosts their pay.
The idea of using the vulnerability to patch the vulnerability comes up pretty regularly, but it's just too risky. The Android ecosystem is diverse, which means that the "patch attack" would have to be properly customized for every device (which also affects attackers, BTW), plus the fact that a non-trivial number of devices are rooted and modified by the users means that there is a subset of devices for which the patch attack cannot be properly customized. Screwing up a patch attack could brick devices, so getting it exactly right is critical.
Then there's the fact that on Android ICS and newer devices this bug is very hard to exploit due to ASLR. You can easily generate a crash in the mediaserver, but to do more than that you need to figure out the address of something else you can tweak to obtain root access. ASLR makes knowing an address impossible, so you just have to try a bunch of random locations until something works... which means you have to send hundreds or thousands of bad MMS messages and there's a non-zero chance that something you tweak may do some damage. Attackers don't care if they screw up some percentage of the devices they target, but patchers do. Oh, and the hundreds/thousands of bad MMS messages are likely to freak out the users... unless you announce to the world what you're doing, which would make attackers' lives easier by convincing users not to freak out when they're under attack.
Then there's the fact that stagefright by itself doesn't give you root access, and even if you do get root access, that still isn't enough to actually update the system image. You need a kernel-level exploit to be able to remount the system image as read-write so you can fix it. This means that the attack patch would actually need a kernel-level exploit chain in order to patch the bug; stagefright is just the first step. (Note that it's also just the first step for an attacker, since mediaserver probably doesn't give them all the access they want, but they're probably happy with an exploit chain that leads to root compromise; they don't need kernel compromise since they probably don't care about installing a backdoor that persists across reboots.)
And those are just some of the technical challenges. There are also serious legal issues which are probably showstoppers (IANAL). Your intentions may be pure, but that doesn't always matter in court.
(Disclosure: I'm a member of Google's Android security team but I'm not speaking in an official capacity. These are my own opinions.)
Is a system with no security defects known by anyone secure?
This might appear to be a philosophical maundering like "If a tree falls and no one is around to hear it, does it make a sound?", but it's not. It's a very serious question, with real implications... and the answer is yes.
Consider FakeID, a serious vulnerability in the Android app signing infrastructure that basically allowed any app to be claim to be from any provider -- including claiming to be signed by the OEM, to obtain system privileges. The bug was introduced in 2.2.1 in 2010 and existed in all versions of Android until 2014.
But no one knew.
Once the flaw was revealed Google was easily able to go back and examine the certificates of all apps uploaded to Google Play during the entire period of time between when the vulnerability was introduced and when it was fixed. Google also examine the contents of other app stores, and non-store app repositories. There wasn't a single instance of an app with a faked certificate chain, anywhere, until the public disclosure of the bug. Snowden's documents gave no hint that the NSA knew of it. Hacking team's archives had no hint of it. If anyone, anywhere, knew of the bug they were incredibly circumspect and careful with their usage. The more reasonable conclusion is that no one knew.
During those four years, all Android devices were vulnerable to this serious security hole, but none of them were exploited. So, the Android app signing architecture was effectively secure even while it was technically broken.
And as I said above, this is not just a semantic quibble. If your definition of "secure" (under some defined threat model) assumes that the system must have no security defects, then no system of any complexity ever has been or ever will be secure. Security is only meaningful within a defined context, and that context includes the knowledge of the adversaries. Of course, we can never know what the attackers do or do not know, but we can reasonably suppose that if they don't use a devastatingly effective attack it's because they don't know about it. This means that systems actually do get less secure over time, unless they're maintained.
(Note, BTW, that the mere existence of a known security defect also doesn't necessarily make the system insecure. That also depends on threat model and on whatever other mitigations may be in place. For example, take the libstagefright bug. 90% of Android devices in the world are running Ice Cream Sandwich or higher, and have ASLR enabled in their kernels which makes a bug like the one in libstagefright very hard to exploit.)
Somewhat. My Sun workstation ran for years with no software updates. It had bugs, but nothing that required a new operating system or application software.
The big difference was that it was behind a firewall and a 19.2k modem, so there wasn't much anyone could do to attack the--probably numerous--security holes.
So, if we just disable all network interfaces and keep our phones physically secure behind locked doors, updates won't be needed.
The proof that turning it off over the weekend will save money is this. Imagine that they turned it off for some arbitrarily long time (say a century). Would that save money? Of course. How about for half a century. Et cetera. You have to pay to cool it back down again and that offsets some of the savings of letting the temperature rise. The question really is where the break-even point comes in. If you let the temperature rise back to ambient and then immediately cool down to desired temperature, that should be an approximately break-even time. Anything longer and you are ahead. Anything shorter and well you really haven't turned it off!
This is incorrect.
The rate at which heat enters a building from warmer outside air is proportional to the difference between the temperatures. If there's a five-degree difference half as much heat energy per unit of time enters the building than if there's a ten-degree difference. The amount of heat that must be removed Monday morning is the integral of that heat flow function. If you keep the office cool all weekend, you keep the interior/exterior temperature differential large and the heat flow high. If you allow the interior to warm up then the differential decreases and heat flow decreases. Less heat in means less to pump out.
This effect is maximized in the scenario you describe, where interior temperature rises to match exterior temperature, because when the temperatures are the same heat transfer ceases, but it's useful even if the difference never falls to zero. Actually, it's even better when the temperature differential goes negative and heat starts naturally flowing out of the building (e.g. interior temperature rises during the day and exterior temperature falls enough at night to be below the elevated interior temperature). Heat that flows out naturally is heat you don't have to remove. Smart buildings should be able to improve this effect by facilitating beneficial heat transfer (e.g. opening windows or pumping exterior air through the building) and impeding undesired heat transfer (e.g. insulation, keeping doors and windows closed).
Cite? From what I see that ceases being true by about age 30 for the vast majority of people.
No, you've got that backwards. Millenials don't give a shit about cars. But IME the majority of people who give their cars names are over thirty and female, or over fifty and male.
You've changed your claim. You're now discussing not the majority of people but the majority of people who name their cars which as far as I can tell is a very, very small percentage of automobile owners. I find it believable that people who name their cars wouldn't like to rent one. Note that that's not the same as saying I believe it.
Your claim about ages rings hollow to me, though. I don't know anyone over the age of 25 who has named their car. Of course, I only know two people who have named their cars, period (one is 21 and one is 19).
However, my experience doesn't really matter. You're the one making the claim that no one will be willing to buy a car that doesn't perfectly fit all of their needs, so it's on you to support it, not on me to refute it.
I'll have you know, we Facebook refuseniks have equal scorn for Google+.
Speak for yourself. I refuse to use Facebook, but quite like Google+. I also have a Twitter account, which I never use. But I dumped Facebook the second or third time they changed my privacy settings without asking me, and have no intention of every going back.
Apple is innovating by bringing this to cellphones and screwing carries out of voicemail minutes.
Assuming anyone even cares about minutes any more, Google Voice does the same. When GV answers your phone and takes voicemail it doesn't use your cell minutes. And users of GV rarely dial in to listen to their voicemails either; the transcription is so good they just glance at the e-mail/SMS/Hangout message and get what they need to from it.
Apple may indeed be able to find some way to innovate in this space, but simply transcribing voicemails isn't going to do it.
No it doesn't. A 30 min supercharge only gives you a 50% charge, which is about 140 miles, which is a bit over 2 hours at highway speeds. Nobody I know stops to eat every 2.5 hours while on a long trip.
Well, my experience with my kids is that we stop every two hours. Not necessarily to eat. Granted that it's often for 15-20 minutes rather than 30, but it wouldn't be difficult to wait a few minutes more before heading out.
getting people to give up a major factor of anything (in this case Range/"Refueling" time) requires a significant incentive
There is no "refueling time" issue to "give up". Refueling time is a major advantage of EVs for everyday use... refueling my EV takes ten seconds. Five when I get out of the car and plug it in at night, and five more when I unplug it in the morning. I find my ICEV much, much more of a bother to keep fueled.
This is only true in the exceptional case of long-distance, non-stop travel. And even there, all it takes is enough range and fast-enough recharging to ensure that the car doens't need to spend any more time refueling than the people do.
But I get the feeling what theses clowns are aiming to do is get people to learn basic coding in order to flood the market with code monkeys that know how to write an if-then-else statement in order to deflate CS salaries......Make it so that anybody with a high school diploma can apply for entry-level coding jobs.
Right, because what Microsoft and Facebook are looking for is entry-level coders for jobs that don't require much more than an if-then-else statement. I suppose it's remotely possible that flooding the entry-level market could reduce pressure on the higher end, but I highly doubt that the effect would be noticeable. The skills gap is just too large and the productivity difference between the top and bottom ends too large.
What's more likely is that they realize that good programmers are as much born as made, and that there is a percentage of the population who could be good but currently are never even exposed to it enough to find out how much they would like it. In other words, they aren't looking to pull in lots of little fish, they're looking to trawl a bigger part of the ocean for the big fish that they're trying to find.
I suspect there's also an element of "mainstreaming" involved. The programming culture can be offputting to many people, so by making it more normal they hope to interest more of the potentially-great software engineers who currently look at the culture and stay far away. Like women.
Property tax is still an indirect tax on economic activity, as I pointed out above, since the value of property is defined by economic activity (whether the property is actually used or not), and since property tax directly affects the cost of all economic activity involving property which, ultimately, is all economic activity or so close to all as makes no difference. There may be some business, somewhere, which requires no capital expenditures and takes place entirely on public land, but it certainly isn't the norm. It's true that some economic activity is more capital intensive than other economic activity, but I don't see how that implies that economic activity which is less capital-intensive necessarily makes fewer claims on government or should be taxed less.
And I still don't see that the Broken Window Fallacy is a counterexample. Perhaps I'm dense. Or perhaps we disagree on the meaning of "counterexamples". At best it seems to highlight that economic activity and property value aren't the same thing, but I don't think that was ever in dispute.
Slashdot Mirror
How much of this problem is due to old assumptions about running on real hardware? That is to say the entropy pool is fed from lots of sources most of them system devices. Is this just an unintended consequence of running on cut down virtual hardware platforms?
The researchers specifically addressed virtualization in the talk, providing different measurements of entropy available on real vs virtual machines. Real machines generate roughly twice as much entropy per unit of time, but both generate 2-3 orders of magnitude less than systems consume. However, as I noted in my other lengthy post, it's not clear that this really matters.
Basically there's no proof /dev/urandom is less safe than /dev/random
Yep. As I said, the whole pool entropy measurement concept is extremely conservative in that there are no known theoretical attacks, much less practical ones, that depend on drawing from /dev/urandom when it has low entropy.
Also, there's an ioctl you can use [man7.org] on /dev/random - RNDGETENTCNT - to see how much entropy your system currently has, if you want to play around with it a bit.
Or you can cat /proc/sys/kernel/random/entropy_avail
Note that doing that will start a new process, which consumes entropy, so don't be surprised if it gradually drops over repeated calls.
Sure, some penalty other than perjury could work. Perjury is nice because it's well-defined and already in use in the statute, but it's possible something more targeted would be better.
That seems to be the fundamental problem here. Legislating that no-one can make an honest mistake in this kind of field seems unconstructive, given the inherent uncertainty of fair use and the like. However, legislating that someone can maliciously or negligently make a claim that they should reasonably have known to be false is a different thing entirely, and that seems closer to what actually happened.
Correcting this deficiency seems pretty easy -- at least with respect to the text of the law. All we need is another part that specifies that the issuer of the notice makes a statement under penalty of perjury that they have performed due diligence in ascertaining the correctness of their good faith belief. The courts would have to work out what "due diligence" means in this case, but it's obvious that it would have to mean at least verifying that the allegedly infringing work at least references the allegedly infringed work. So, for example, anyone claiming infringement by a work that was uploaded years before the allegedly infringed work clearly did not do their due diligence.
That would only be a problem if the boot scripts start up OpenSSL before seeding urandom. Are there any server distros that do that? At least CentOS 6 does it in rc.sysinit, way before the network-related stuff is started.
That only helps if there's some stored entropy to load during boot. There generally is something to load... how much entropy it has is harder to say.
I attended the (very interesting) Black Hat talk, and neither the article nor the /. summary do a very good job of summarizing it.
From memory (I didn't take notes), the key points were:
1. Tracking the entropy pool is a little harder than you might expect, because the kernel itself uses quite a lot. The primary reason is ASLR, but there other ways the kernel uses entropy itself. The kernel is effectively drawing from /dev/urandom at a very high rate, pulling thousands of bits every time it starts a process.
2. /dev/urandom vs /dev/random work a little differently than most people expect. There are actually three entropy pools, a "main" pool, a /dev/random pool and a /dev/urandom pool. Both /dev/random and /dev/urandom use the same PRNG, and both try to maintain 0 bits of entropy in their local pools, drawing a block from the main pool when needed and mixing it into their local pools (keep in mind that a pool is many bytes of data plus an estimate of how much entropy is in that data). /dev/random, obviously, blocks when it runs out of entropy in its local pool and there isn't enough in the main pool to satisfy the request. /dev/urandom works the same way, except that (a) it won't block and (b) it won't draw the main pool below 128 bits. When the main pool drops to 128 bits, /dev/urandom stops pulling from it.
3. The rate of entropy going into the main pool is low, on the order of single-digit bits per second. For some reason Potter and Moore didn't understand, using a daemon to get bits from the CPU HWRNG not only didn't increase the estimated entropy inflow rate, but actually decreased it (I had to step out for a bit around that point in the talk so I missed details).
4. Points 1, 2, and 3 taken together mean that the entropy pool is basically never above 128 bits. The kernel is always drawing on /dev/urandom, typically at a much higher rate (hundreds to thousands of bits per second pulled from urandom vs <10 bits per second going in).
5. OpenSSL seeds its internal CPRNG during startup and then just uses it, potentially forever, without ever reseeding. Worse, when it seeds from /dev/urandom at startup it makes no effort to check whether or not the kernel pool has any entropy to give it. It just gets some bytes and goes. This means that if an apache server starts up when there isn't much entropy in the pool, that very small amount of entropy could get stretched over a very large number of cryptographic operations. (Aside: I do a little work on and with BoringSSL, Google's OpenSSL fork, and it does reseed regularly, and also uses a more trustworthy CPRNG. I highly recommend using BoringSSL rather than OpenSSL.)
6. Android actually does better than desktop/server Linux, producing many more bits per second of entropy, though still far less than are demanded. Potter attributes this to the rich source of randomness available from the cellular radios.
How much any of this matters is hard to say. Entropy estimation is something of a black art at best, or wild ass guess at worst. Also, the kernel is known to be extremely conservative with at least one of its entropy sources: the HW RNG in most CPUs. Because there's concern the NSA may have backdoored those HW RNGs the kernel assumes their output is perfectly predictable, meaning that it provides zero entropy. The kernel mixes in HW bits anyway, because they can't hurt even if they are 100% predictable, and to whatever extent they're unpredictable they help.
In addition, the whole concept of entropy pools of known size which are drawn down and refilled is an extremely conservative one. Modern CPRNGs are able to produce enormous amounts of uniformly-distributed, unpredictable bits from fairly small seeds -- say, 256 bits of entropy. Assuming the kernel ever manages to get even a
really HTC *should* be responsible since they are the ones that customized it in a way that you could not just take straight patches from Google.
It's even more than that, since the security vulnerability in this case was added by HTC. There are no remote support tools in the base Android platform, and therefore no insecure remote support tools.
No Nexus devices have this problem.
It's not simply a case of Google saying "fix it" and shipping patches to every single Android device out there. Google doing that would be like the Debian group trying to ship Debian patches to Ubuntu - it wouldn't work.
Especially since in this case Google had nothing whatsoever to do with the problem. This one is entirely a consequence of OEMs adding insecure extensions to the base platform Google provides. Insecure extensions with root privileges, basically.
...except that's not actually true.
For example, there's been the long-running practice of reenlistment bonuses. Different jobs get much higher bonuses for reenlisting.
The base pay may be the same, but the difference between, say, a low-ranking cook and a low-ranking nuclear weapons technician is pretty startling when that bonus is calculated. As in "tens of thousands of dollars."
There is also extra pay for various specific skills. Some of them cut across job categories, for example you get more pay if you speak another language. Others are specific to the job; electronics techs get extra pay, medical personnel get extra pay, etc. People in high-skill jobs tend to get promoted faster and therefore be higher in rank than those in low skill jobs, which also boosts their pay.
The idea of using the vulnerability to patch the vulnerability comes up pretty regularly, but it's just too risky. The Android ecosystem is diverse, which means that the "patch attack" would have to be properly customized for every device (which also affects attackers, BTW), plus the fact that a non-trivial number of devices are rooted and modified by the users means that there is a subset of devices for which the patch attack cannot be properly customized. Screwing up a patch attack could brick devices, so getting it exactly right is critical.
Then there's the fact that on Android ICS and newer devices this bug is very hard to exploit due to ASLR. You can easily generate a crash in the mediaserver, but to do more than that you need to figure out the address of something else you can tweak to obtain root access. ASLR makes knowing an address impossible, so you just have to try a bunch of random locations until something works... which means you have to send hundreds or thousands of bad MMS messages and there's a non-zero chance that something you tweak may do some damage. Attackers don't care if they screw up some percentage of the devices they target, but patchers do. Oh, and the hundreds/thousands of bad MMS messages are likely to freak out the users... unless you announce to the world what you're doing, which would make attackers' lives easier by convincing users not to freak out when they're under attack.
Then there's the fact that stagefright by itself doesn't give you root access, and even if you do get root access, that still isn't enough to actually update the system image. You need a kernel-level exploit to be able to remount the system image as read-write so you can fix it. This means that the attack patch would actually need a kernel-level exploit chain in order to patch the bug; stagefright is just the first step. (Note that it's also just the first step for an attacker, since mediaserver probably doesn't give them all the access they want, but they're probably happy with an exploit chain that leads to root compromise; they don't need kernel compromise since they probably don't care about installing a backdoor that persists across reboots.)
And those are just some of the technical challenges. There are also serious legal issues which are probably showstoppers (IANAL). Your intentions may be pure, but that doesn't always matter in court.
(Disclosure: I'm a member of Google's Android security team but I'm not speaking in an official capacity. These are my own opinions.)
I see that you didn't read my post.
You didn't read my post.
Can we stop calling you guys 'editors', and just get on with 'clowns who post story submissions'.
Because it's quite clear you don't actually, you know, edit.
They edit, meaning that they modify the text. The thing is that they generally make it worse, not better.
They stop being secure.
They were never secure
Is a system with no security defects known by anyone secure?
This might appear to be a philosophical maundering like "If a tree falls and no one is around to hear it, does it make a sound?", but it's not. It's a very serious question, with real implications... and the answer is yes.
Consider FakeID, a serious vulnerability in the Android app signing infrastructure that basically allowed any app to be claim to be from any provider -- including claiming to be signed by the OEM, to obtain system privileges. The bug was introduced in 2.2.1 in 2010 and existed in all versions of Android until 2014.
But no one knew.
Once the flaw was revealed Google was easily able to go back and examine the certificates of all apps uploaded to Google Play during the entire period of time between when the vulnerability was introduced and when it was fixed. Google also examine the contents of other app stores, and non-store app repositories. There wasn't a single instance of an app with a faked certificate chain, anywhere, until the public disclosure of the bug. Snowden's documents gave no hint that the NSA knew of it. Hacking team's archives had no hint of it. If anyone, anywhere, knew of the bug they were incredibly circumspect and careful with their usage. The more reasonable conclusion is that no one knew.
During those four years, all Android devices were vulnerable to this serious security hole, but none of them were exploited. So, the Android app signing architecture was effectively secure even while it was technically broken.
And as I said above, this is not just a semantic quibble. If your definition of "secure" (under some defined threat model) assumes that the system must have no security defects, then no system of any complexity ever has been or ever will be secure. Security is only meaningful within a defined context, and that context includes the knowledge of the adversaries. Of course, we can never know what the attackers do or do not know, but we can reasonably suppose that if they don't use a devastatingly effective attack it's because they don't know about it. This means that systems actually do get less secure over time, unless they're maintained.
(Note, BTW, that the mere existence of a known security defect also doesn't necessarily make the system insecure. That also depends on threat model and on whatever other mitigations may be in place. For example, take the libstagefright bug. 90% of Android devices in the world are running Ice Cream Sandwich or higher, and have ASLR enabled in their kernels which makes a bug like the one in libstagefright very hard to exploit.)
Has software ever "just worked"?
Somewhat. My Sun workstation ran for years with no software updates. It had bugs, but nothing that required a new operating system or application software.
The big difference was that it was behind a firewall and a 19.2k modem, so there wasn't much anyone could do to attack the--probably numerous--security holes.
So, if we just disable all network interfaces and keep our phones physically secure behind locked doors, updates won't be needed.
Brilliant!
The proof that turning it off over the weekend will save money is this. Imagine that they turned it off for some arbitrarily long time (say a century). Would that save money? Of course. How about for half a century. Et cetera. You have to pay to cool it back down again and that offsets some of the savings of letting the temperature rise. The question really is where the break-even point comes in. If you let the temperature rise back to ambient and then immediately cool down to desired temperature, that should be an approximately break-even time. Anything longer and you are ahead. Anything shorter and well you really haven't turned it off!
This is incorrect.
The rate at which heat enters a building from warmer outside air is proportional to the difference between the temperatures. If there's a five-degree difference half as much heat energy per unit of time enters the building than if there's a ten-degree difference. The amount of heat that must be removed Monday morning is the integral of that heat flow function. If you keep the office cool all weekend, you keep the interior/exterior temperature differential large and the heat flow high. If you allow the interior to warm up then the differential decreases and heat flow decreases. Less heat in means less to pump out.
This effect is maximized in the scenario you describe, where interior temperature rises to match exterior temperature, because when the temperatures are the same heat transfer ceases, but it's useful even if the difference never falls to zero. Actually, it's even better when the temperature differential goes negative and heat starts naturally flowing out of the building (e.g. interior temperature rises during the day and exterior temperature falls enough at night to be below the elevated interior temperature). Heat that flows out naturally is heat you don't have to remove. Smart buildings should be able to improve this effect by facilitating beneficial heat transfer (e.g. opening windows or pumping exterior air through the building) and impeding undesired heat transfer (e.g. insulation, keeping doors and windows closed).
Cite? From what I see that ceases being true by about age 30 for the vast majority of people.
No, you've got that backwards. Millenials don't give a shit about cars. But IME the majority of people who give their cars names are over thirty and female, or over fifty and male.
You've changed your claim. You're now discussing not the majority of people but the majority of people who name their cars which as far as I can tell is a very, very small percentage of automobile owners. I find it believable that people who name their cars wouldn't like to rent one. Note that that's not the same as saying I believe it.
Your claim about ages rings hollow to me, though. I don't know anyone over the age of 25 who has named their car. Of course, I only know two people who have named their cars, period (one is 21 and one is 19).
However, my experience doesn't really matter. You're the one making the claim that no one will be willing to buy a car that doesn't perfectly fit all of their needs, so it's on you to support it, not on me to refute it.
I'll have you know, we Facebook refuseniks have equal scorn for Google+.
Speak for yourself. I refuse to use Facebook, but quite like Google+. I also have a Twitter account, which I never use. But I dumped Facebook the second or third time they changed my privacy settings without asking me, and have no intention of every going back.
Apple is innovating by bringing this to cellphones and screwing carries out of voicemail minutes.
Assuming anyone even cares about minutes any more, Google Voice does the same. When GV answers your phone and takes voicemail it doesn't use your cell minutes. And users of GV rarely dial in to listen to their voicemails either; the transcription is so good they just glance at the e-mail/SMS/Hangout message and get what they need to from it.
Apple may indeed be able to find some way to innovate in this space, but simply transcribing voicemails isn't going to do it.
No it doesn't. A 30 min supercharge only gives you a 50% charge, which is about 140 miles, which is a bit over 2 hours at highway speeds. Nobody I know stops to eat every 2.5 hours while on a long trip.
Well, my experience with my kids is that we stop every two hours. Not necessarily to eat. Granted that it's often for 15-20 minutes rather than 30, but it wouldn't be difficult to wait a few minutes more before heading out.
To you, a car is just a box. But most people have a relationship with their car
Cite? From what I see that ceases being true by about age 30 for the vast majority of people.
currently the battery packs alone are $8k - $12k
LEAF batteries are $6K.
getting people to give up a major factor of anything (in this case Range/"Refueling" time) requires a significant incentive
There is no "refueling time" issue to "give up". Refueling time is a major advantage of EVs for everyday use... refueling my EV takes ten seconds. Five when I get out of the car and plug it in at night, and five more when I unplug it in the morning. I find my ICEV much, much more of a bother to keep fueled.
This is only true in the exceptional case of long-distance, non-stop travel. And even there, all it takes is enough range and fast-enough recharging to ensure that the car doens't need to spend any more time refueling than the people do.
You keep focusing on the corner cases and implying that they're all that matters.
But I get the feeling what theses clowns are aiming to do is get people to learn basic coding in order to flood the market with code monkeys that know how to write an if-then-else statement in order to deflate CS salaries......Make it so that anybody with a high school diploma can apply for entry-level coding jobs.
Right, because what Microsoft and Facebook are looking for is entry-level coders for jobs that don't require much more than an if-then-else statement. I suppose it's remotely possible that flooding the entry-level market could reduce pressure on the higher end, but I highly doubt that the effect would be noticeable. The skills gap is just too large and the productivity difference between the top and bottom ends too large.
What's more likely is that they realize that good programmers are as much born as made, and that there is a percentage of the population who could be good but currently are never even exposed to it enough to find out how much they would like it. In other words, they aren't looking to pull in lots of little fish, they're looking to trawl a bigger part of the ocean for the big fish that they're trying to find.
I suspect there's also an element of "mainstreaming" involved. The programming culture can be offputting to many people, so by making it more normal they hope to interest more of the potentially-great software engineers who currently look at the culture and stay far away. Like women.
Property tax is still an indirect tax on economic activity, as I pointed out above, since the value of property is defined by economic activity (whether the property is actually used or not), and since property tax directly affects the cost of all economic activity involving property which, ultimately, is all economic activity or so close to all as makes no difference. There may be some business, somewhere, which requires no capital expenditures and takes place entirely on public land, but it certainly isn't the norm. It's true that some economic activity is more capital intensive than other economic activity, but I don't see how that implies that economic activity which is less capital-intensive necessarily makes fewer claims on government or should be taxed less.
And I still don't see that the Broken Window Fallacy is a counterexample. Perhaps I'm dense. Or perhaps we disagree on the meaning of "counterexamples". At best it seems to highlight that economic activity and property value aren't the same thing, but I don't think that was ever in dispute.