Recent submissions

Comment · 1 year ago
Much of the US/UK legal system is based on common-law rules that are several hundred years old. In some cases those old laws have been codified, in some cases not, but either way there's no need to drop them just because they're old. On the contrary, laws that have stood that long without needing to be changed have demonstrated that they are extraordinarily good ideas.
Comment · 1 year ago
It's unfriendly to developers and power users, but very friendly to the other 99.999% of users.

I used to work for Google, on Android security, and it's an ongoing philosophical debate: How much risk do you expose typical users to in the name of preserving the rights and capabilities of the tiny base of power users? Both are important but at some point the typical users have to win because there are far, far more of them.

The article implies that this move is security theater. It's not. I wasn't involved in this decision at all, but the security benefit is clear: Rate limiting.

As the article points out, Google already scans all the devices for harmful apps. The problem is knowing what apps to look for. Static analysis can catch them, dynamic analysis with apps running in virtual environments can catch them, researchers can catch them, users can report them... all of these channels are taken advantage of to identify bad apps and Google Play Protect (or whatever it's called these days) can then identify them on user devices and warn the users, but if bad actors can iterate fast enough they can get apps deployed to devices before Google catches on.

So, the intention here is to slow down that iteration. If attackers use the same developer account to produce multiple bad apps, the dev account will get shut down, requiring the attackers to create a new account, registered with a different user identity and confirmed with different government identification documents.

Note that in the short term this will just create an additional arms race. In order to iterate their malware rapidly, attackers will also need to fake government IDs rapidly. This means Google will have to get better at verifying the IDs, including, I expect, getting set up to be able to verify the IDs using government databases. Attackers will probably respond by finding countries where Google can't do that for whatever reason. Google will have to find some mitigation for that, and so on.

So it won't be a perfect solution, but in the real world, especially at Google scale, there are no perfect solutions. It's all about raising the bar, introducing additional barriers to abuse and making the attackers have to work harder and move slower, which will make the existing mechanisms more effective.

Comment · 9 years ago
>> 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.

Comment · 11 years ago
(Googler here)

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.

Comment · 11 years ago
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.

Comment · 11 years ago
(Googler here)

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.

Comment · 11 years ago
> 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.

Comment · 11 years ago
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.
Comment · 11 years ago
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.

Comment · 11 years ago
Comment · 11 years ago
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.)

Comment · 11 years ago
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.

Comment · 11 years ago
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.

Comment · 11 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton