So electric cars have electric heaters; I had not thought about that aspect before. That would be a considerable inefficiency; OTOH gas cars use the engine waste heat for heating.
You have an odd definition of inefficiency. The fact that ICEVs generate a lot of waste heat is the real inefficiency, even if it does provide a "free" solution to the problem of cabin heat. An efficient vehicle doesn't waste energy and then sometimes apply a small percentage of the waste to do do something useful.
Even for non-security bugs, the many-eyes hypothesis contains a large dose of wishful thinking
Not true; Torvalds' observation wasn't what he wished would happen, it what what he'd observed repeatedly on a large and complex project over the period of many years.
That said, I think your disagreement is because, like many, you misunderstand the hypothesis. What Torvalds said wasn't that given enough eyes all bugs are visible, but that they're shallow, meaning easy to track down and fix. The hypothesis doesn't even come into play until the existence of the bug is known.
And, undoubtedly, there are some bugs that are deep no matter how many eyes are looking at it, so the hypothesis isn't literally true in all cases. But it is true in nearly all cases, as Torvalds has been in an excellent position to see.
What's particularly funny about all of this is that you actually believe that you're shaming me. In point of fact, assuming anyone actually bothers to read this stuff (very unlikely), you're just making yourself look ridiculous, continuing to accuse me of somehow failing to support a position I never took.
No one is buying it, dude. No one.
Also, I should point out that you're really failing as a stalker. I've made like a dozen posts in other threads and you haven't spammed any but this one. Step it up, man!
But the context of this conversation is taking control of your phone to prevent it being used to spy on you, and you haven't done that.
Whether it "calls home" or not on the new firmware is neither issue nor concern for me, as I don't take it out when I leave the house and I don't discuss sensitive issues over the phone to anyone.
You never take your mobile phone out of the house? Why use a mobile at all, then?
It's all about "Hey, we like Android but we don't want Google forced down our throats."
To be precise it's "Hey, we like the Google Play store (and perhaps other parts of the Google apps bundle; that's not clear) but don't want Google Search". Because you can absolutely use Android without Google. It's open source, Apache 2 licensed.
(Disclaimer: I work for Google, on Android, but don't speak for Google. I'm not offering any opinions on the Russian complaint, just clarifying what they're complaining about, as I see it.)
Please explain how a web browser is the optimal medium through which to play a 3d first person shooter.
Optimal? Obviously not. But... it is in fact adequate these days, for an increasing set of games. And the web makes for fantastically low-friction deployment.
OTOH, A mobile web browser is not adequate except for the most trivial games, and a bad idea for most of them.
"HTTP/2... also introduces unsolicited push of representations from servers to clients."
Seriously? Do we need yet ANOTHER way for a server to push unwanted code and malware onto our client systems?
Yes, we do.
What you're missing here is that this is pushing content that the browser was going to request in a few hundred milliseconds anyway. Why was the browser going to request it? Because the web page included a link to it.
The only way this change could affect security is if you assume a threat model where the attacker is able to modify the web server to get it to push additional content to the browser but is somehow unable to modify the content the server is already pushing anyway. If the attacker can do the latter, he can simply insert links to his additional content and the browser will obediently request them. If we think that this thread model is a risk worth mitigating, the solution is trivial: Browsers should accept pushed content but not begin to parse it until it's referenced from the page or whatever.
Actually, it's pretty unclear what browsers would even do with such pushed content until they'd found it referenced. It would have an attached content type, but most of the time what to do with content depends pretty heavily on the context -- and browsers are generally (rightly) skeptical of content type labels anyway.
This is the greatest gift we could POSSIBLY give to the cybercriminals who want to break into our systems.
Well that's a nice bit of hyperbole. It contains no truth, though.
How about we think of security somewhere in this process, instead of pretending it's someone elses's problem?
How about we understand what's actually going on, before blowing our stack?
Today pipelining works fine. It's disabled because Google rushed SPDY out to preempt pipelining from being turned on.
I stopped reading your comment right here.
Pipelining was introduced in HTTP/1.1, standardized in RFC 2616 which was released in 1999. We've had 16 years to get pipelining working well. 13 if you count up to when Google first started seriously experimenting with SPDY.
(Disclaimer: I work for Google, but has nothing to do with my opinions on this issue. I thought pipelining was obviously broken long before I started working for Google.)
To start with, I should point out that I am far from knowledgeable on these topics. I took physics in college, but my degrees are in math and CS.
But I've been reading a little on cosmology, QM and speculations about where our understanding is headed, and it's occurred to me (probably because one of the books I read suggested it; I don't recall) that a plausible explanation for observed reality may be that matter and energy are merely configurations of an underlying "substance": spacetime. Or, if you're a traditionalist, perhaps you can call it aether, though it's rather different than what used to be hypothesized under that label. What little I've understood of what I've read of string theory accords with an information-based reality, too, since the hypothesized strings encode a lot of information (yes, I'm waving my hands about, intensely).
If true, that means that the nature of the reality that we see really is pure information, and if that's the case, then information theory is really fundamental to cosmology and everything else. That's cool. Especially if, like so many here, you've devoted much of your life to logic and information.
Or maybe reality is something completely different. Or maybe we have no clue, and never will. But it's certainly very cool to speculate about -- and to the degree that our speculations result in models that appear to accurately explain our observations, very useful.
Now, having spouted what is likely a pile of complete nonsense, I'm hoping that someone who actually knows something will reply and straighten me out.
One more point: it occurs to me that the effectiveness of this sort of strategy may explain the evolutionary advantage of getting irrationally angry. The fact is that people don't always behave in their best, most rational interest. Sometimes they behave irrationally in favor of people they perceive to be part of their tribe (which has obvious evolutionary advantages) and sometimes they behave irrationally and kick their opponent in the teeth because they're pissed off, even though it may cost them more. This apparently disadvantageous characteristic may exist specifically to counter the otherwise powerful advantage of extortion over cooperation.
The part of my comment you elided was "and offering medical services", which completely changed the meaning of the quote. Are you aiming for a career in journalism?
To be clear, it is not illegal to claim to be a doctor in contexts that don't involve offering medical advice/service, so there is no conflict with the first amendment.
The rust lang site c0d3g33k linked has all the information you could want, but I think the Wikipedia article is a great high-level summary: http://en.wikipedia.org/wiki/R...
If you're claiming to be a doctor and offering medical services, however, that is a crime. Same for legal services, professional engineering services, etc.
when will most manufacturers realize that range is critical into turning electric cars from a commuters vehicle into a family, general, all purpose car?
All of the manufacturers understand perfectly well exactly how important range is to making an EV a general-purpose vehicle. What no one knows, yet, is how to make an EV with 300-mile range that doesn't cost upwards of $80K. Tesla doesn't have any special knowledge in this regard, but the market for vehicles in that price range is obviously small.
I should point out, though, that my Nissan LEAF is our primary family car. It's not a general-purpose car -- we have a large SUV that does all of the things the LEAF can't do, like haul 7 people, tow heavy loads, go offroad and cover long distances -- but the LEAF is our family car. We drive it far more than the other, in both number of trips and number of miles, and when I say "Okay kids, get in the car!" they pile into the LEAF.
No, you (Alice) encrypt with your private key, then encrypt with 'Bobs' public key, then Bob decrypts with his private key and again with Alice's public key.
Thus Both Alice and Bob are authenticated, and no one besides Alice and Bob can intercept.
If a candidate who claimed to be knowledgeable of cryptography gave me this answer it would be a big red flag, unless they quickly clarified that this was only a high-level, conceptual description and not an outline of the actual sequence of operations.
The biggest problem with this protocol, even if some of the technical defects implied by the description aren't really there but just a result of providing a very high-level description, is that it enables Bob to encrypt Alice's message with Charlie's public key and send it to him, causing Charlie to believe that Alice sent the message.
Honestly, the best answer to this question is something along the lines of "Use PGP and tell it to sign and encrypt to Bob". There are a lot of subtle and tricky pitfalls with cryptographic protocol design and implementation, so smart engineers use existing, well-vetted tools and protocols.
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.
While that's not unreasonable, it really doesn't address the problem. The problem was that not enough people were running unstable, so it wasn't getting enough testing. I suppose slowing progress even further might have pushed a few more people to use the dev kernel... but I doubt it.
Duress codes are an old idea, and a great one in some contexts, but I don't think they're really appropriate for everyone, or even the majority of people. Given the data we have on how many people manage to forget their passcode and lock themselves out of their devices when there's only a single passcode, adding more of them would be a recipe for confusion-generated disaster.
Also, I think having various unlocked-but-not-unlocked modes is the wrong solution. The right solution is to just leave the device locked. Then if the police want to peruse it, they can proceed via the court system.
The wipe feature notion raises really interesting questions: In some cases, it would be awesome, for example activists resisting oppressive regimes (we can debate whether or not we believe the US is such). In others its primary use case is to facilitate destruction of evidence of actual crimes, which isn't so good. There are also risks in pushing the envelope too far because it may facilitate laws like the ones theorized by that other rather paranoid response to my post, which may actually make things worse.
It's worth pointing out that you can already implement the "limited" feature with Lollipop: Just create a separate user account with limited stuff in it. If you want to be very careful, make it look like that is your primary account and the other (real) one is for your significant other's casual use or something. Switching between accounts is very easy and fast, and automatically invokes the lock screen.
None of the ideas you raise are at all new; they've been discussed a thousand times in the Android team and are discussed on a regular basis. I don't know if you find that comforting or not, but there it is:-)
So electric cars have electric heaters; I had not thought about that aspect before. That would be a considerable inefficiency; OTOH gas cars use the engine waste heat for heating.
You have an odd definition of inefficiency. The fact that ICEVs generate a lot of waste heat is the real inefficiency, even if it does provide a "free" solution to the problem of cabin heat. An efficient vehicle doesn't waste energy and then sometimes apply a small percentage of the waste to do do something useful.
Even for non-security bugs, the many-eyes hypothesis contains a large dose of wishful thinking
Not true; Torvalds' observation wasn't what he wished would happen, it what what he'd observed repeatedly on a large and complex project over the period of many years.
That said, I think your disagreement is because, like many, you misunderstand the hypothesis. What Torvalds said wasn't that given enough eyes all bugs are visible, but that they're shallow, meaning easy to track down and fix. The hypothesis doesn't even come into play until the existence of the bug is known.
And, undoubtedly, there are some bugs that are deep no matter how many eyes are looking at it, so the hypothesis isn't literally true in all cases. But it is true in nearly all cases, as Torvalds has been in an excellent position to see.
What's particularly funny about all of this is that you actually believe that you're shaming me. In point of fact, assuming anyone actually bothers to read this stuff (very unlikely), you're just making yourself look ridiculous, continuing to accuse me of somehow failing to support a position I never took.
No one is buying it, dude. No one.
Also, I should point out that you're really failing as a stalker. I've made like a dozen posts in other threads and you haven't spammed any but this one. Step it up, man!
Oh, I never said it's cool to be a troll.
It is, however, great fun to troll you.
I think this is the easiest trolling I've ever done.
That's more like it!
This game is entertaining me :-)
Four whole days to respond? Come on, you can do better than that.
But the context of this conversation is taking control of your phone to prevent it being used to spy on you, and you haven't done that.
Whether it "calls home" or not on the new firmware is neither issue nor concern for me, as I don't take it out when I leave the house and I don't discuss sensitive issues over the phone to anyone.
You never take your mobile phone out of the house? Why use a mobile at all, then?
It's all about "Hey, we like Android but we don't want Google forced down our throats."
To be precise it's "Hey, we like the Google Play store (and perhaps other parts of the Google apps bundle; that's not clear) but don't want Google Search". Because you can absolutely use Android without Google. It's open source, Apache 2 licensed.
(Disclaimer: I work for Google, on Android, but don't speak for Google. I'm not offering any opinions on the Russian complaint, just clarifying what they're complaining about, as I see it.)
Nobody cared before, because CPUs and browser layout engines were the bottleneck not the network.
Nonsense. With some notable exceptions, network has always been the primary bottleneck.
Please explain how a web browser is the optimal medium through which to play a 3d first person shooter.
Optimal? Obviously not. But... it is in fact adequate these days, for an increasing set of games. And the web makes for fantastically low-friction deployment.
OTOH, A mobile web browser is not adequate except for the most trivial games, and a bad idea for most of them.
"HTTP/2... also introduces unsolicited push of representations from servers to clients."
Seriously? Do we need yet ANOTHER way for a server to push unwanted code and malware onto our client systems?
Yes, we do.
What you're missing here is that this is pushing content that the browser was going to request in a few hundred milliseconds anyway. Why was the browser going to request it? Because the web page included a link to it.
The only way this change could affect security is if you assume a threat model where the attacker is able to modify the web server to get it to push additional content to the browser but is somehow unable to modify the content the server is already pushing anyway. If the attacker can do the latter, he can simply insert links to his additional content and the browser will obediently request them. If we think that this thread model is a risk worth mitigating, the solution is trivial: Browsers should accept pushed content but not begin to parse it until it's referenced from the page or whatever.
Actually, it's pretty unclear what browsers would even do with such pushed content until they'd found it referenced. It would have an attached content type, but most of the time what to do with content depends pretty heavily on the context -- and browsers are generally (rightly) skeptical of content type labels anyway.
This is the greatest gift we could POSSIBLY give to the cybercriminals who want to break into our systems.
Well that's a nice bit of hyperbole. It contains no truth, though.
How about we think of security somewhere in this process, instead of pretending it's someone elses's problem?
How about we understand what's actually going on, before blowing our stack?
Today pipelining works fine. It's disabled because Google rushed SPDY out to preempt pipelining from being turned on.
I stopped reading your comment right here.
Pipelining was introduced in HTTP/1.1, standardized in RFC 2616 which was released in 1999. We've had 16 years to get pipelining working well. 13 if you count up to when Google first started seriously experimenting with SPDY.
(Disclaimer: I work for Google, but has nothing to do with my opinions on this issue. I thought pipelining was obviously broken long before I started working for Google.)
To start with, I should point out that I am far from knowledgeable on these topics. I took physics in college, but my degrees are in math and CS.
But I've been reading a little on cosmology, QM and speculations about where our understanding is headed, and it's occurred to me (probably because one of the books I read suggested it; I don't recall) that a plausible explanation for observed reality may be that matter and energy are merely configurations of an underlying "substance": spacetime. Or, if you're a traditionalist, perhaps you can call it aether, though it's rather different than what used to be hypothesized under that label. What little I've understood of what I've read of string theory accords with an information-based reality, too, since the hypothesized strings encode a lot of information (yes, I'm waving my hands about, intensely).
If true, that means that the nature of the reality that we see really is pure information, and if that's the case, then information theory is really fundamental to cosmology and everything else. That's cool. Especially if, like so many here, you've devoted much of your life to logic and information.
Or maybe reality is something completely different. Or maybe we have no clue, and never will. But it's certainly very cool to speculate about -- and to the degree that our speculations result in models that appear to accurately explain our observations, very useful.
Now, having spouted what is likely a pile of complete nonsense, I'm hoping that someone who actually knows something will reply and straighten me out.
One more point: it occurs to me that the effectiveness of this sort of strategy may explain the evolutionary advantage of getting irrationally angry. The fact is that people don't always behave in their best, most rational interest. Sometimes they behave irrationally in favor of people they perceive to be part of their tribe (which has obvious evolutionary advantages) and sometimes they behave irrationally and kick their opponent in the teeth because they're pissed off, even though it may cost them more. This apparently disadvantageous characteristic may exist specifically to counter the otherwise powerful advantage of extortion over cooperation.
Yay, my stalker is back! I missed you, man. Where were you?
The part of my comment you elided was "and offering medical services", which completely changed the meaning of the quote. Are you aiming for a career in journalism?
To be clear, it is not illegal to claim to be a doctor in contexts that don't involve offering medical advice/service, so there is no conflict with the first amendment.
The rust lang site c0d3g33k linked has all the information you could want, but I think the Wikipedia article is a great high-level summary: http://en.wikipedia.org/wiki/R...
You can claim anything you want with no trouble.
Yes, you can, at the bar or wherever.
If you're claiming to be a doctor and offering medical services, however, that is a crime. Same for legal services, professional engineering services, etc.
Tesla knows how to make an EV with 300-mile range that doesn't cost upwards of $80K: a giga (battery) factory.
Well, they think they do. The haven't proven it yet :-)
when will most manufacturers realize that range is critical into turning electric cars from a commuters vehicle into a family, general, all purpose car?
All of the manufacturers understand perfectly well exactly how important range is to making an EV a general-purpose vehicle. What no one knows, yet, is how to make an EV with 300-mile range that doesn't cost upwards of $80K. Tesla doesn't have any special knowledge in this regard, but the market for vehicles in that price range is obviously small.
I should point out, though, that my Nissan LEAF is our primary family car. It's not a general-purpose car -- we have a large SUV that does all of the things the LEAF can't do, like haul 7 people, tow heavy loads, go offroad and cover long distances -- but the LEAF is our family car. We drive it far more than the other, in both number of trips and number of miles, and when I say "Okay kids, get in the car!" they pile into the LEAF.
No, you (Alice) encrypt with your private key, then encrypt with 'Bobs' public key, then Bob decrypts with his private key and again with Alice's public key.
Thus Both Alice and Bob are authenticated, and no one besides Alice and Bob can intercept.
If a candidate who claimed to be knowledgeable of cryptography gave me this answer it would be a big red flag, unless they quickly clarified that this was only a high-level, conceptual description and not an outline of the actual sequence of operations.
The biggest problem with this protocol, even if some of the technical defects implied by the description aren't really there but just a result of providing a very high-level description, is that it enables Bob to encrypt Alice's message with Charlie's public key and send it to him, causing Charlie to believe that Alice sent the message.
Honestly, the best answer to this question is something along the lines of "Use PGP and tell it to sign and encrypt to Bob". There are a lot of subtle and tricky pitfalls with cryptographic protocol design and implementation, so smart engineers use existing, well-vetted tools and protocols.
In my case the script didn't even harass me for five days, assuming it is a script. And the harassment stopped the instant I began calling him out.
The problem was that the odd-numbered versions weren't getting enough testing, so the real testing didn't happen until the even-numbered release. So the system seriously slowed the pace of kernel development without significantly improving stability.
True, and the solution to that should be that nothing except emergency fixes goes into the stable branch until it's tested in unstable.
While that's not unreasonable, it really doesn't address the problem. The problem was that not enough people were running unstable, so it wasn't getting enough testing. I suppose slowing progress even further might have pushed a few more people to use the dev kernel... but I doubt it.
Duress codes are an old idea, and a great one in some contexts, but I don't think they're really appropriate for everyone, or even the majority of people. Given the data we have on how many people manage to forget their passcode and lock themselves out of their devices when there's only a single passcode, adding more of them would be a recipe for confusion-generated disaster.
Also, I think having various unlocked-but-not-unlocked modes is the wrong solution. The right solution is to just leave the device locked. Then if the police want to peruse it, they can proceed via the court system.
The wipe feature notion raises really interesting questions: In some cases, it would be awesome, for example activists resisting oppressive regimes (we can debate whether or not we believe the US is such). In others its primary use case is to facilitate destruction of evidence of actual crimes, which isn't so good. There are also risks in pushing the envelope too far because it may facilitate laws like the ones theorized by that other rather paranoid response to my post, which may actually make things worse.
It's worth pointing out that you can already implement the "limited" feature with Lollipop: Just create a separate user account with limited stuff in it. If you want to be very careful, make it look like that is your primary account and the other (real) one is for your significant other's casual use or something. Switching between accounts is very easy and fast, and automatically invokes the lock screen.
None of the ideas you raise are at all new; they've been discussed a thousand times in the Android team and are discussed on a regular basis. I don't know if you find that comforting or not, but there it is :-)