>> Note that you are trusting this app with your private key.
On Android, the Kryptonite code uses the AndroidKeyStore to store the private key, which means that the app does not have access to it. At a minimum (on old devices), AndroidKeyStore keeps the private key material in a separate process, so it never exists in the app's process space. On newer devices (launched with M or later), the private key material is kept in the Trusted Execution Environment, so nothing in Android user or even kernel space has access to it.
EDIT: Actually, there's one small flaw in the Kryptonite code that may make the private key accessible to a sophisticated attacker who compromises the app. The key allows signing without using a hash function. Signing a sequence of carefully-chosen plaintexts can reveal the private key. I filed an issue and sent a pull request.
It's a platform feature, so it's open source, but there's always a delay between the announcement and the time the code hits the public repositories. It'll be there before too much longer.
I find it useful to keep in mind the notion that all knowledge is gained by a process of guesswork and criticism. When you listen to my voice or read my words, you must guess at what I mean to convey, because my words by themselves, even if not mumbled, are almost never sufficiently precise to carry my meaning.
So instead, you have to build and discard internal explanatory models of my meaning, criticizing them by cross-checking them with other things I've said, and with your understanding of my understanding of the world. Meanwhile, I'm doing the same thing on the other side, hypothesizing the models that you're creating based on what I've said and trying to add more words to fill any gaps in what I presume that you're presuming that I mean.
When we arrive at a point where you and I both believe that you hold a consistent mental model of what I wished to convey, then we believe that I have communicated to you.
Stated that way, it's clear that communication is really, really hard -- even though we do all of that model building and evaluation without conscious effort in most cases. And it's also quite obvious why it's easier to communicate with people you know well, because both sides have a better mental model of the other's mental model. Both are _wrong_, always, but they're less wrong than similar situations between people with less shared context.
This view also makes it abundantly clear that it's important to validate communication. If you restate to me in your own words what you believe I intended to convey, there's a good chance I'll catch any major discrepancies between what I intended and what you got. A good chance, but we can still end up believing that we're in agreement when we're not.
In theory it is possible to define a language and communication techniques that do not depend on this iterative, contextualized method. This is essentially what we do in formal languages, such as those we use in mathematics or programming. But it is not how people communicate because it's actually far more efficient to rely on compression via shared context than it is to communicate with formal precision. Further, formal communication only obviates guesswork and criticism at the level of understanding which is directly expressed. I can read an assembler program and understand with perfect precision what the individual instructions do, but the leap to understanding the goal of the program again requires guesswork and criticism.
As an aside, it's interesting to note that the process of guess-and-evaluate is essentially the same as the scientific method of hypothesize-and-test and even the same as the evolutionary method of vary-and-select. There's a compelling argument that all knowledge creation occurs via this process -- and communication is knowledge creation, even if it simply conveys an idea from one brain to another, because there's no direct transfer mechanism the receiver of the idea must create it based on observations of the words of the giver.
> communication is knowledge creation, even if it simply conveys an idea from one brain to another, because there's no direct transfer mechanism the receiver of the idea must create it based on observations of the words of the giver.
I feel like science and mathematics (and even computer science) attempts to counter this.
If we can mechanically generate mathematical proofs, and those proofs can be proven equivalent to one another, then we have essentially simplified the abstraction mechanics of the individual brain and transferred them to a computer.
I view abstraction as a means for expanding all potential permutations of a given model and it's application, and then a reduction to a different set of terms that connects models.
We might be able to prove that we can agree with one another, but we might not be able to prove that we agree with our own selves. We can always make the problem more difficult individually by guessing and creating more questions.
To me the process is two sides of the same coin. One side is creation, the other side is destruction. You can't convey an idea without having an idea, and you can't question that idea without having another idea. Negation is still a logical mechanism. You can question whether there is more to think about than a choice between [(exist) or (does not exist)].
I really prefer to think about possibility and potential. It's an open space to me.
You're not wrong, but I think you overstate the case. I wouldn't say employees are encouraged to publicly trash the company's products. Not at all. But the company does respect employees' right to speak their mind in public, and it does encourage thoughtful internal dissent.
I often tread pretty close to the line on what I say in public, and have even been reined in by Google legal counsel in a couple of cases. I found the experience of being told to cool it to be surprisingly affirming and liberating, and a powerful confirmation of the true commitment to openness in Google culture, because of the reasons for which it was done and the way in which it was done. Specifically, in both cases I really had crossed a line which could be potentially troublesome for Google in court, and in both cases the attorney who contacted me was respectful of my opinions and my rights to speak them to the point of being very apologetic about telling me to shut up. It was very clear to me that Google really didn't want to silence me, and did it only because they truly had to. I think that's awesome.
Based on my experience, I have zero concern for Brad's job, and wouldn't be surprised if he gets some mild and unofficial kudos.
> here we have a handful of _startups_ that confess there's isn't enough work to keep everyone in the nimble team up on toes for even forty hours a week
I don't think they said anything of the sort. There's no claim they don't have enough work for 40 hours; I'm sure like most of us there is no end to the work, and it can and will consume all the time we're willing to give it.
They're just not willing to give it as much. It's possible that will put them at a disadvantage to their competitors. It's also possible that they may be sufficiently more creative to overcome that disadvantage.
Yeah, but negative vote is a perfect example of how stupid this community has become. Not even able to digest even the slightest counter-thinking, and the recoil is never short of abusive.
Look at the moron below who calls "up on toes" as corporate slang. NO. It's not a corporate slang, rather a pursuit of a start_up to beat the rest.
Hopeless! This site used to be quality. Now it's full of sheep with one-track mind. My last note here. Go ahead vote it down, enjoy your dumb echo-chamber and live through your satisfaction.
I like a $20 bill more than a $10 bill. Is that an emotional reaction? No, it's an objective value judgement based on the fact that the former is more useful (roughly twice as useful) as the latter. The word "like" merely expresses preference. It's neutral as to the basis of the preference, which may be emotional, rational or some combination.
Correct. At present the only solution for pre-4.4 devices is to avoid using WebView to display untrusted content. If you're an app developer using WebView you should make sure it's only displaying trusted content which means either local content or remote content from trusted sites with non-broken SSL. I recommend using Google's recently-released nogotofail toolkit to test for SSL breakage (https://github.com/google/nogotofail).
The ideal fix for this problem is for OEMs to update devices to 4.4.
Google could invest the resources to create patches. What Google can't do is get those patches delivered to end-user devices. Given the fact that if Google provided patches they'd never reach users anyway, why should Google bother? And we know that OEMs won't provide updates because they are already refusing to provide the one that has existed for some time now: Android 4.4.
(Disclaimer: I'm a Google employee, and I work on Android security, but I'm not a spokesperson and these are only my own opinions.)
>What Google can't do is get those patches delivered to end-user devices.
Apple manage to do it. Google made a conscious decision to trade off allowing end users to keep up to date with achieving faster adoption of Android among OEMs and carriers. You can't now pretend that the results of those decisions are some kind of inevitability. It was Google's choice, and they are responsible for the result.
>And we know that OEMs won't provide updates because they are already refusing to provide the one that has existed for some time now: Android 4.4.
Apple makes all of its devices and therefore controls them. Google can't dictate to Samsung, HTC, LG, etc.
Google has updated the in-support Nexus devices. The Galaxy Nexus is something of a question mark, but the number of active Galaxy Nexus devices is tiny. It would make more sense for Google to offer GNex users a new device than to upgrade the few remaining GNex's to 4.4.
The problem isn't the change. History has shown time and again that we can deal with that. The problem is the rate of change. The industrial revolution took generations to really complete, and even so it was kind of rough in places. These changes are coming much, much faster.
We need to find something between accepting mass poverty and creating a total welfare state which, even if it works economically, will be a disaster for human happiness. People need to feel productive, useful and self-reliant. What that is, I don't know.
I'm encouraging my kids to become technocrats, like me.
"I'm encouraging my kids to become technocrats, like me."
Same here. My family is covered. But the hard reality of unemployment still bothers me. I feel that if we were TRULY an advanced society, we would have already solved this problem. It's a problem. And problems are solvable. We just have to want to solve it.
I've read that Google's position on liability is that it should be on the maker of the autonomous car, which makes perfect sense to me. Traffic accidents (including with pedestrians) rarely involve criminal culpability anyway, except when alcohol or drugs are involved, or when there's clear evidence of gross negligence, so it's really a question of civil liability. Putting that liability on the maker of the machine aligns the interests correctly and ensures that the liability is well-funded.
So, I really don't think it's as much of a problem as you think it is.
On Android, the Kryptonite code uses the AndroidKeyStore to store the private key, which means that the app does not have access to it. At a minimum (on old devices), AndroidKeyStore keeps the private key material in a separate process, so it never exists in the app's process space. On newer devices (launched with M or later), the private key material is kept in the Trusted Execution Environment, so nothing in Android user or even kernel space has access to it.
EDIT: Actually, there's one small flaw in the Kryptonite code that may make the private key accessible to a sophisticated attacker who compromises the app. The key allows signing without using a hash function. Signing a sequence of carefully-chosen plaintexts can reveal the private key. I filed an issue and sent a pull request.