Actually, according to a talk by Rich Cannings, Google's "Android Security Leader", at Usenix Security '09 in Montreal, Google can choose whether or not to have your phone ask you for permission for an OS upgrade. If they think it's important enough, they reserve the "right", and definitely retain the technical capability, to install an upgrade without asking. The carriers can probably also do OTA upgrades on their own initiative; that part wasn't clear to me.
The whole tone of his talk was scary. There was no sign that he could imagine that somebody might not want to trust Google with total control of their phone, or that such distrust could possibly be legitimate if it did exist. His whole attitude reeked of "we know better than you do", and he seemed to think of the phone's owner more as a security threat than as the person who should be setting security policy. And he didn't even mention the possibility that Google might get compromised.
He also seemed to think of the Android open source project as something to push code to as an afterthought, rather less important than the carriers... whose interests he seemed to think were terribly, terribly important.
It was not reassuring.
And, yes, my understanding matches yours. The article says that they can also install apps, in addition to OTA OS upgrades. In fact, as I read the supporting material, the Market application works by pushing an "INSTALL_ASSET" message to your phone... the same message they'd use to spontaneously install an app. So there's no fixing the problem without either disabling the Market entirely or patching the implementing code.
And of course an OS upgrade could contain code to do anything they want, including enabling them to install apps if they weren't already able to do so.
It seems to me that what's going to have to happen is that people are going to have to get over the idea that they can actually review every statement a nominee has ever made, get over the idea that people should be automata who never say anything possibly embarrassing (and thus that it even makes sense to want to review everything they've ever written), and get over the idea that there's some absolute bright line between the public and private life.
While we're doing that for the Supreme Court, maybe we should also do it for other random jobs. It's idiotic to check every Facebook a job candidate has ever made to see if they've failed to toe the line at all times. Doing that favors worthless nonentities.
These pretenses are technologically obsolete, and people need to deal with that.
My point is that you should not be liable to anybody at all, for anything. By imposing liability for something, the law is, in effect, saying that that behavior is forbidden. I can murder people, too, but I'll be subject to a criminal penalty because the law forbids murder. More to the point, I can fail to perform on a contract, but I'll be liable for civil damages because the law forbids not performing on contracts. Sorry if German law doesn't have the criminal/civil distinction, but I think it probably does.
To push the car analogy, your approach says that, if I lend my car to my friend, who is a licensed driver with a reasonable record, and if my friend scrapes somebody's fender (which is closer than running over somebody to the level of damage you can do via WiFi), then I should pay for the fender. You may in fact believe that. I don't.
If I were an official of the American government, speaking in my official capacity, you'd be right.
Since I'm not, I'm free to criticize any law, anywhere in the world, and to say what I think should happen anywhere in the world. I am a human being, and that means that, in this and many, many other situations, I outrank artificial constructs like nation states.
I'm happy to listen to German opinions on what should be done with American law. In fact, I think the US needs all the outside opinions it can get right now.
As for what mechanism the law uses to forbid open WiFi, that's not relevant. If ir forbids open WiFi, which seems to be the case, then it needs to be changed. I don't care whether it's phrased in terms of "802.11[abg] without WPA-2", or in terms of "personal responsibility". If the effect is to forbid open WiFi, it's not OK.
I'm perfectly well aware that Germany is a civil law country. What does that have to do with the fact that the law shouldn't forbid running an open WiFi network? I didn't say by what process it should be changed. Taking a German court at its word on its interpretation of German civil law is not the same thing as saying the court makes the law.
And, according to the summaries I've seen of the decision, the court in fact said that, according to local law, you effectively can't run an open WiFi network. That's because any remotely effective "precautions against abuse" make the network not open any more. A network is not open if you need to have a password to join it. It's also not open if it's so loaded up with filters that you can't do anything interesting with it.
I doubt the law will accept a mere pretense of precautions; you're going to have to have a real expectation that what you're doing will work, and that means no open networks.
I can anonymously give or sell people all kinds of things that they could use to commit crimes, and that is a good thing.
Internet access isn't particularly dangerous. Most of the uses of it aren't illegal at all. The actual, direct harm you can cause with it is usually a lot less than the harm you can cause with, say, a hammer. You can buy a hammer with no questions asked down at the hardware store. As long as I have no special reason to believe that that specific person intends to use it illegally, I can also give a hammer to a random person in the street. Same thing for thousands of other objects and services... in fact, for almost all objects and services.
I do, and will continue to, run an open WiFi access point. I really don't give a flying fuck about your issues with that. You're just gonna have to deal. Not everybody wants to live in your world.
I should presumably also be fined if somebody commits a crime using M&Ms from the candy jar on my desk.
There is no legal requirement in the US for an ISP to know who its customers are, nor should there be. Certain people would like to make every citizen responsible for enforcing everything, and not let anybody do anything without being tracked by the Man... but luckily those particular evil forces haven't completely won yet.
I have no idea about German law, other than that, to the extent that it forbids running an open WiFi network, German law needs to be changed.
There's no hardcoded password in that "lawful intercept" stuff. There are bugs in it, and the auditing is inadequate, but it's not like just anybody who knows a password can turn it on, nor can any law enforcement or spy agency turn it on without help from the carrier. The bugs are more like it not complaining loudly enough when somebody tries to brute-force the password the operator has set.
Don't get me wrong. "Lawful intercept" is a bad idea and a huge security hole in every vendor's products (not just Cisco's). But there's a big difference between a documented set of features that have bugs, and an intentional, hidden, sooper-sekrit "back door" with a fixed password.
All carrier products from all vendors have wiretapping support, because it's required by law in a boatload of places. It's stupid and evil to have those laws, but they were openly debated and openly adopted, and the technology that implements them is openly described. Furthermore, using it requires the carrier to participate in the wiretap process; law enforcement can't do it by itself. The problem those articles describe is that it's hackable... which is something the vendors, probably including Cisco, warned could happen when the laws were adopted.
Yes, EROS and I think KeyKOS, are totally persistent, and I don't think
people are ready to program in that model, if we ever will be. But
that's fixable; there's no intrinsic connection between capabilities and
never reinitializing anything. It's convenient, but not necessary.
It's OK that I broke C. It's not type safe anyway.:-)
Seriously, though, you're getting to one of the real limitations; there
are some programs that really do need access to a lot of stuff. A
compiler does need access to all the library declarations.
And most programs need access to a lot of different services.
Even so, there's a big difference between the equivalent of/usr/include
and the whole system.
One of the points of the model is to force people to pick and choose
what access programs need. One of the challenges would be to avoid
ending up with a situation where people just habitually gave every
program capabilities for everything because it was easier. That would
require both cultural changes and good enough tools that you weren't
constantly having to fight the system to get anything done.
There's an analogous weakness at the user level: "Drag your Quicken file
onto this window to win $1000.". Mandatory data tagging could help
there, but it's not going to solve everything, and it turns out to be a
real big PITA.
There will always be ways to get users to hose
themselves. Even so, better the user should lose the Quicken file
than the whole machine.
So, lots of work, lots of cultural changes, and, yeah,
you can expect to rewrite every significant program from scratch,
including the runtime libraries. I did say that I wasn't optimistic.
But I do think that such big changes are a necessary, if not a sufficient,
condition for a qualitatively more trustworthy desktop.
I see one possible path forward. The way things are going, we're going
to end up with every program in its own VM anyway, as people try to
protect one part of the system from another. The next thing people will
want will be ways to let those VMs interact. If those ways are designed
intelligently, we might get another crack at the isolation that wasn't
done in the current generation of operating systems. VMs would play the
role that programs or processes take today, and you could be giving VMs
capabilities to talk to each other.
It would be grossly inefficient, but
if the VMs are going to happen anyway, we might as well do it
right. Unfortunately, getting people to do it right will be a huge, and
possibly insurmountable, educational challenge, for much the same
reasons that put us where we are today.
You can have filenames; you just keep them in a namespace that's
accessible only to the user (or the user's file manager or whatever). If
you have a CLI, you type "program <filename>", and the CLI runs an
instance of that program and gives it a capability to that file, rather
than passing it the name. If you have a GUI, you probably do something
like dragging the file onto the program, and the UI creates an instance
of the program and passes it the capability.
You're correct that most programs wouldn't be able to have their own
open dialogs. They'd have to rely on capabilities passed in from the
user's file manager. Probably you'd express that by dragging
again. That's actually more "desktop" than having an open dialog anyway.
You could support thumbnails by having a little program that generated a
thumbnail from a file and did nothing else. Since you can prevent that
program from leaking the information from the files, it's relatively
safe to have the file manager call it with a read-only capability to
every file in turn, and display the results.
The same applies to things like indexers. Although they'd be relatively
powerful and dangerous, they wouldn't be remotely as dangerous as the
simplest program in today's OSes, because you could prevent them from
leaking the information to anyplace other than their indexes.
If you want to insert a file into a document, that looks like another drag
operation. You drag the file into an existing instance of a program,
rather than onto a factory icon.
It's pretty easy not to pass the same capability to multiple programs or
instances of the same program (and pretty easy for them to detect it if
you do, assuming they have write access to the file, or assuming you
have a reasonable set of locking primitives).
Yeah, you'll lose some memory to separate instances. You can share all
the program text, but the heap is gonna suck up space. It would
presumably pay to be economical about building huge "dynamic" structures
every time anybody ran your program. On the other hand, think of all the
space you won't be wasting on every program having its own open
dialog...
Capdesk isn't really unpleasant conceptually, if you want a toy example.
It's not free, and it can't be invisible to the user, but it's not so horrible as all that.
I have SELinux on my desktop, although it's not as tightly configured as it could be. I'm typing this on it.. It's not what I want, and I don't think it can be made into what I want.
The problem with SELinux is that it falls into the classic "reference monitor" trap, where some outside piece of code tries to intuit the intent of something like a system call. It's a layered-on kludge, like a firewall.
I want something more like KeyKOS or EROS, perhaps with a layer of something like (but not identical to) MLS a la Bell and LaPadula, or some kind of compartment tagging system. In SELinux, I can still say "fopen (/etc/passwd)". In KeyKOS, "/etc/passwd" isn't even a defined name for me; if I need that file, I'll be given an opaque handle for it, which I can then store in my own name space if I want to.
It is not enough to layer on some kind of reference checker if the underlying programs assume that they have access to everything. One of the big reasons that SELinux is a PITA is that the behavior of the programs its trying to control is so complicated and irregular, and the people writing the programs aren't the people writing the SELinux configurations. Without big changes in the APIs and ways of doing things, it's really hard to guess what a program may try to do or what it needs.
SELinux also doesn't have the sort of granularity it would need for network access control. You only get control up to the socket layer. To do it right, you'd need to rearchitect the whole stack, so that you could give programs restricted access at whatever layer was appropriate. It should be possible to express "this program can get this URL (or, better yet, this opaque network handle), but not this other URL".
Sure, I'll take if I can get it, because it might come in handy. But how important is it to me, really?
If I want to steal the user's credit card number, it's right there in a Quicken file. No admin access required.
If I want the user's contact list, it's in Outlook or whatever.
If I want to steal the user's passwords, no problem, I can still hook the keyboard one way or another, or just grab them from the browser's password store.
I may not be able to rewrite the browser, but I can debug the browser process and get the same effect.
If I want to run the webcam, no privileges are required.
If I want to send spam, I can make a TCP connection without administrator access.
OK, I may have trouble hiding myself as well as I'd like from privileged anti-malware programs, or make it monstrously hard for them to remove me. There are a few things I can't change on the local system. I probably can't hook file system or network access, and if I can it's probably for only one user. There are a few not-that-important services I can't talk to. I can't mess with the lower layers of the network very much. I can't create another user. It would be nice to be able to do those things. But it's not like I'm seriously handicapped without administrator access. And, since I also have access to run privileged programs or send requests to privileged services, I have a huge surface available to attack with 'sploits if I do want administrator access.
Same on Linux. Yeah, there are differences, but they're down in the noise; they aren't the sorts of qualitative things that would really matter in terms of making the desktop trustworthy.
The fundamental security model of Linux is no better than that of Windows. The main reason Windows gets nailed is that it's more profitable to write malware for Windows than for anything else. If Linux had the market share of Windows, it would have as much, or nearly as much, malware.
In either Linux or Windows, being able to run any code at all gives you essentially complete access to the user's data, plus almost unlimited access to system resources, plus the ability to talk to the network. Who cares if you're not running as root if everything interesting is owned by the user's account?
There are ways to make systems more secure, starting with strong containment. How strong? Strong enough that your program can't even express the desire to, say, open a file that the user hasn't given it a capability for. Strong enough that the user has to jump through hoops to give certain programs access to certain data. Especially programs with network access... which need to be only the programs that actually need it. Strong enough to subdivide lots of functions that people are used to putting together in the same process. Strong enough that you can forget about most of the APIs you're used to coding with. And, if you're going to run apps out on the network, that whole system has to extend out into the network as well.
On top of that, people ought to be using tools that make it a lot harder
to express common security bugs, and that help you to notice when you've
created others.
If this is to be fixed, users and programmers are going to have to
change the ways they do things. I'm not super optimistic.
Linux helps not at all. Even OpenBSD wouldn't help much.
"Clean" slides are at least as dangerous as cluttered ones.
If your message does not fit on a slide, then don't use a fucking slide.
Some things are too complex to be reduced to bullets. The answer to that is not to bury the complexity in supplemental material that nobody will ever read. All that does is to create the illusion of comprehension... more dangerous than knowing that you don't have a clue. If you know you don't know, you'll either find out, or you'll let somebody else deal with the problem. If you think the problem is simple, but it's not, you'll make stupid decisions.
Don't put up a bunch of "keywords" on a screen to hypnotize the audience. SPEAK to the audience. Flash keywords if you must, but don't leave a slide up there for people to read while they miss the thread of what you're saying, or forget to think about anything that doesn't happen to have fit into the five available lines. And leave yourself some flexibility to respond when they're not getting it, instead of blindly continuing down the track your slides set for you.
Don't waste a lot of time making pretty slides, either. They're basically distracting and misleading. In fact, maybe you should write those keywords on a blackboard.
Is all your information in your slides? Can you say, with a straight face, "read my slides and you'll understand"? Then that's not a presentation. That's what we used to call a "document". Use a document preparation tool for that, not a presentation tool.
Is it too complicated to say in a presentation? Then a document is indeed right for you. Write one. Let people read it. MAKE them read it; don't give them a simplified spoon-fed version that produces false understanding. That's right, people need to actually read and write real text. Can't read and write? Sorry, you don't belong here.
Sure, use charts and graphs. That's what PowerPoint is actually good for. Make sure your analysis and data presentation are respectable, though... you can easily create a graph that gives a thoroughly wrong impression of what's important.
And that Afghanistan slide actually makes a great point. It says "This is complicated, you idiots. Don't knee-jerk". That's a slide I might actually use.
I didn't know that about compartmentation. It's good news. Thank you for answering my ignorance with actual information...
I still don't buy the code inspection thing. Even if Apple ramped their inspection WAY up (to levels they could never afford), I don't think it would stop anybody. It's just too easy to slip a subtle bug past a reviewer. Even if it got to the point of Apple spending $10K for reviews on every revision of every app, I'm pretty confident that within a couple of years, getting around that would be seen as a basic skill in the Bad Guy community. Sure, there'd be some deterrence, but worth the cost?
I'm 100-minus-epsilon percent sure that I could join the iPhone developer program in such a way that neither Apple nor the cops could trace me. The epsilon comes from the fact that I'm working from general knowledge rather than Apple-specific knowledge. I've never seen one of those programs that did any real verification of who was joining. It'd cost you a fortune per developer to do it. There's also the tack of just stealing the credentials of a legitimate developer. If they weren't on Macs, I could just pay a botmaster to give me a set.:-)
As for turning off apps, if it were done with your "greylists" it sounds like a big win. That's the beginning of the kind of global reputation system that could do you some good. You could even have the greylist give the user the reason something had been turned off, and let the user decide what to do. However, if it's done by Apple with no user choice, then the very depths of my soul start screaming out "single point of failure". And, anyway, how much damage can I do before they notice?
As a security person of about 20 years' standing, I'd like to protest that Apple's whitelist doesn't help, and that not all of us have ever asked for whitelists.
No realistic level of code review will detect subtle, deliberately introduced security holes. It won't even detect a lot of accidental ones. I guarantee you that I can write you an iPhone app that passes Apple's (fairly cursory) code reviews, passes any static analysis they apply, and still gives total, remote control of all the interesting data on the phone to anybody who knows some magic incantation.
Remember the halting problem? Code inspection isn't an effective security measure (packet inspection isn't much better, by the way).
Really, what you need most is compartmentation, so that the user can't be screwed by a bad app even if that app gets to run. The way Android does things, with fine-grained permissions and a sandbox for each app, isn't bad, except that the attack surface (the whole Linux kernel, plus other stuff) is too big. A microkernel that enforced a fine-grained capability system, possibly coupled with sticky compartment tagging of data, would help a lot... but every programmer would have to relearn everything to code to it. To get real security, you have to give up things like global file system name spaces.
After that, you need a realistic way for the user to evaluate the motives and trustworthiness of the source of a piece of code. I guess Apple could theoretically help with that on the iPhone, but they don't do it at the moment. In fact, nobody does it, becuase it's really, really hard to do it effectively.
Your family individually, personally contacts the people they know were close to you. Those people fill in the gaps. No, it's not fun. But it's necessary. I've done it. I'll probably be doing it again in a few years.
If actually know somebody well enough to really care if they've died, it's pretty cold to have to read about it in the newspaper. And it's pretty lazy to use the newspaper as an escape hatch.
The good news is that you can do a lot of it by e-mail. An awful lot of older people use e-mail these days, maybe because they're old and wise enough to realize that correspondence and face to face contact aren't, in fact, mutually exclusive. Maybe they even remember when it was actually hard to travel to see somebody, and you sent, you know, letters...
Anyway, which paper should I publish the notice in, given that all those friends have probably also moved?
I'm not sure that learning Morse is meaningful "learning" or a useful "challenge". It's just an artificial barrier, like being willing to grind in an MMORPG... and it gives you just about as much generally useful skill. CW isn't even the best way to get through with a weak signal on a noisy channel any more. It's a relic.
If you want a challenge, why not make people demonstrate some real knowledge of electronics (not just soldering together kits), antennas, propagation, coding theory, or whatever? There's important and generally useful knowledge involved in radio, but Morse code isn't it. I've never had a ham license, but the sample tests I've seen have been very light on actual radio engineering. The lower classes have essentially none, and the higher classes have less than they might have. And they're all multiple choice. Let's license people who really understand how their equipment works, can create new designs, can solve real problems. That's a more meaningful barrier... and a lot more fulfilling thing to learn than decoding beeps.
It's a bid deal because the contract is monstrously one-sided, and you'd
think nobody would agree to it, yet somehow it manages to fly in a big
chunk of the mobile phone market.
It seems like you'd have to be nuts to invest in developing for the App Store,
other than maybe for short-term, tactical purposes.
Why, then, do so many people do it? Isn't that an interesting
question?
Apple has repeatedly demonstrated itself to be an unreliable, capricious
business partner. Apple is slow and inconsistent about approving
apps. It changes the rules and yanks apps all the time... just as this
agreement permits it to do. It makes errors that cost you money and
doesn't compensate you. Apple has shown, repeatedly over the whole
life of the App Store, that those overreaching
clauses aren't just in that contract for CYA purposes. Apple fully intends to
use those clauses to hose your business if it feels like it for any
reason whatsoever, and the reason may have little or nothing to do with
you.
Personally. I won't even buy Apple's phone because of the
way they handle software. Nonetheless, many people seem to be willing to
bet their livelihoods on Apple. That includes people who aren't big
players, and lack the leverage to make it to Apple's advantage to
forget about certain contract terms.
What's the reason for that? Even if the answer just turns out
to be that they're stupid, it's valuable to look at the
question. Heck, you might even get some of them to smarten up.
If the answer is not that they're stupid, but, say, that
they don't have any better options, then one might want to think about
why we have a market that doesn't provide any
better options. Maybe there should be some changes. Maybe somebody
reading this will figure out how to make them. I think there are
better options, but obviously those developing for the iPhone think
otherwise. Maybe they can explain why?
And, yeah, it's about rights. First of all, the whole point of any
contract is that you give up some rights. Second, the law, and the
underlying moral philosophy, sometimes have some nasty things to say
about one-sided contracts, interference with competition, artificial
limitations of liability, and the like. Not everybody agrees, but
there's a perfectly respectable and intellectually consistent body of
thought that says a contract like that shouldn't be legal.
The problem with having perspective about this kind of thing is that it makes your posts really long. And my posts already run too long. So I took the chance that people would read me too literally, in order to keep what I wrote brief. Guess I lost that bet.
Yes, you're right. There's a tradeoff. Nobody is going to accept certain death. Even if they'll accept it for themselves, they're not going to accept certain death for everybody.
... which is why I mentioned that the reduction in risk is small. We're NOT talking about getting beheaded, and we're certainly not talking about everybody getting beheaded. We're talking about each person accepting a slightly increased statistical risk of getting bombed or whatever. Even if you take the most inflated estimates, the risks involved are smaller than risks all of us accept every day.
Look at the context in which I was writing; I was objecting to the parent post's unwillingness to admit that there was any risk. All I was really trying to convey was that even if there is some risk, that doesn't magically dispel the evil of doing the wiretapping... and also, perhaps clumsily, that there isn't enough risk to outweigh that evil.
You write:
Its easy to say 'There are some things you don't do' when your life, or your families life isn't on the line.".
What does that mean? My life and my family's lives are as much on the line as anybody's. Nobody knows who might get hit by this risk.
I'm not sitting in a bunker somewhere.
For the record, the "thing you don't do" is to turn into an authoritarian gargoyle based on a small statistical risk. Another thing you don't do is to spy illegally, in contravention of your oath of office, based on anything short of a major existential threat. And nobody seriously believes that there's a major existential threat here.
You also write:
'These people' that we're 'fighting' believe THEY have the moral high ground and that we are scum of the Earth. Nothing anyone does is going to change that.
I don't believe I used the word "fighting" anywhere. And by "these people", I meant the people doing and defending the wiretapping. The wiretappers do not, as far as I know, think that "we", whoever "we" are, are the scum of the earth. They seem to have different moral values than I do, but I don't think they hate the populace at large. Quite the contrary.
As for "moral high ground", yes, the wiretappers are in fact knowingly yielding the moral high ground. "Moral high ground" is a common expression referring to how the world at large sees the morality of your actions. It's only coincidentally related to their actual morality. It means, basically, the PR value of the morality of your actions. Are you going to claim that illegal wiretapping makes people think you're more moral, or that the wiretappers think that illegal wiretapping is good PR for them? I don't think they're that dumb.
I get the feeling that by "these people", you mean the terrorists. I have nothing to say to that, other than to mention that terrorists are
human beings with human motivations. It's easier to recruit new terrorists to hate an establishment that's generally seen as evil than it is to recruit them to hate an establishment that's seen as fair and moral.
It's not "We need to respect our constitution, even if it makes our security agencies do a little more work.".
It's "We need to respect our constitution, even if some of us die".
By not addressing their arguments head on, you give the bad guys strength. This is a matter of principle; you don't need to hide from their safety claims.
I don't actually believe that these methods save lives in the long run. I think that these people underestimate the real, physical risks of making enemies and losing the moral high ground. But I could be wrong. It's possible that there is some increase in safety.... small, compared to the risk of say driving a car, but real nonetheless. The point is that this stuff is wrong even if it does make people safer.
Fuck the cowards. There are some things you don't do.
You didn't read the article, did you? They didn't say one word about preventing people from modifying their own robots. There wasn't the slightest mention of any such thing. The whole issue of "preventing modification" did not come up in the article. At all. Not explicitly. Not by implication. Not by suggestion. Not at all.
The article complained, very specifically, that the robots, when you took them out of the box, didn't enforce passwords where they should, and/or that they didn't encrypt network traffic that should be encrypted. The concern was that it was therefore easy to compromise somebody else's robot without physical access to it. The issue of unauthorized access to media streams was emphasized.
And, yes, the same issues would exist if you had a camera with crappy security and no wheels. So what? They were looking at robots, not cameras.
By the way, encrypting WiFi is actually a pretty crappy way to secure this, because it means that there's still no encryption if you communicate with the device over the Internet. The most important encryption is end-to-end encryption. Encrypting the link layer is icing on the cake.
They want you to play with them and make them do cool things. They don't necessarily want other people to drive up outside your house and use the robots' cameras and microphones to spy on you over WiFi. The problem is that the features that enable the first aren't secured, and therefore they can also be used to do the second.
Slashdot Mirror
Actually, according to a talk by Rich Cannings, Google's "Android Security Leader", at Usenix Security '09 in Montreal, Google can choose whether or not to have your phone ask you for permission for an OS upgrade. If they think it's important enough, they reserve the "right", and definitely retain the technical capability, to install an upgrade without asking. The carriers can probably also do OTA upgrades on their own initiative; that part wasn't clear to me.
The whole tone of his talk was scary. There was no sign that he could imagine that somebody might not want to trust Google with total control of their phone, or that such distrust could possibly be legitimate if it did exist. His whole attitude reeked of "we know better than you do", and he seemed to think of the phone's owner more as a security threat than as the person who should be setting security policy. And he didn't even mention the possibility that Google might get compromised.
He also seemed to think of the Android open source project as something to push code to as an afterthought, rather less important than the carriers... whose interests he seemed to think were terribly, terribly important.
It was not reassuring.
And, yes, my understanding matches yours. The article says that they can also install apps, in addition to OTA OS upgrades. In fact, as I read the supporting material, the Market application works by pushing an "INSTALL_ASSET" message to your phone... the same message they'd use to spontaneously install an app. So there's no fixing the problem without either disabling the Market entirely or patching the implementing code.
And of course an OS upgrade could contain code to do anything they want, including enabling them to install apps if they weren't already able to do so.
It seems to me that what's going to have to happen is that people are going to have to get over the idea that they can actually review every statement a nominee has ever made, get over the idea that people should be automata who never say anything possibly embarrassing (and thus that it even makes sense to want to review everything they've ever written), and get over the idea that there's some absolute bright line between the public and private life.
While we're doing that for the Supreme Court, maybe we should also do it for other random jobs. It's idiotic to check every Facebook a job candidate has ever made to see if they've failed to toe the line at all times. Doing that favors worthless nonentities.
These pretenses are technologically obsolete, and people need to deal with that.
My point is that you should not be liable to anybody at all, for anything. By imposing liability for something, the law is, in effect, saying that that behavior is forbidden. I can murder people, too, but I'll be subject to a criminal penalty because the law forbids murder. More to the point, I can fail to perform on a contract, but I'll be liable for civil damages because the law forbids not performing on contracts. Sorry if German law doesn't have the criminal/civil distinction, but I think it probably does.
To push the car analogy, your approach says that, if I lend my car to my friend, who is a licensed driver with a reasonable record, and if my friend scrapes somebody's fender (which is closer than running over somebody to the level of damage you can do via WiFi), then I should pay for the fender. You may in fact believe that. I don't.
If I were an official of the American government, speaking in my official capacity, you'd be right.
Since I'm not, I'm free to criticize any law, anywhere in the world, and to say what I think should happen anywhere in the world. I am a human being, and that means that, in this and many, many other situations, I outrank artificial constructs like nation states.
I'm happy to listen to German opinions on what should be done with American law. In fact, I think the US needs all the outside opinions it can get right now.
As for what mechanism the law uses to forbid open WiFi, that's not relevant. If ir forbids open WiFi, which seems to be the case, then it needs to be changed. I don't care whether it's phrased in terms of "802.11[abg] without WPA-2", or in terms of "personal responsibility". If the effect is to forbid open WiFi, it's not OK.
I'm perfectly well aware that Germany is a civil law country. What does that have to do with the fact that the law shouldn't forbid running an open WiFi network? I didn't say by what process it should be changed. Taking a German court at its word on its interpretation of German civil law is not the same thing as saying the court makes the law.
And, according to the summaries I've seen of the decision, the court in fact said that, according to local law, you effectively can't run an open WiFi network. That's because any remotely effective "precautions against abuse" make the network not open any more. A network is not open if you need to have a password to join it. It's also not open if it's so loaded up with filters that you can't do anything interesting with it.
I doubt the law will accept a mere pretense of precautions; you're going to have to have a real expectation that what you're doing will work, and that means no open networks.
I can anonymously give or sell people all kinds of things that they could use to commit crimes, and that is a good thing.
Internet access isn't particularly dangerous. Most of the uses of it aren't illegal at all. The actual, direct harm you can cause with it is usually a lot less than the harm you can cause with, say, a hammer. You can buy a hammer with no questions asked down at the hardware store. As long as I have no special reason to believe that that specific person intends to use it illegally, I can also give a hammer to a random person in the street. Same thing for thousands of other objects and services... in fact, for almost all objects and services.
I do, and will continue to, run an open WiFi access point. I really don't give a flying fuck about your issues with that. You're just gonna have to deal. Not everybody wants to live in your world.
In decent countries, they have to prove that you broke the law. You don't have to prove anything.
I should presumably also be fined if somebody commits a crime using M&Ms from the candy jar on my desk.
There is no legal requirement in the US for an ISP to know who its customers are, nor should there be. Certain people would like to make every citizen responsible for enforcing everything, and not let anybody do anything without being tracked by the Man... but luckily those particular evil forces haven't completely won yet.
I have no idea about German law, other than that, to the extent that it forbids running an open WiFi network, German law needs to be changed.
There's no hardcoded password in that "lawful intercept" stuff. There are bugs in it, and the auditing is inadequate, but it's not like just anybody who knows a password can turn it on, nor can any law enforcement or spy agency turn it on without help from the carrier. The bugs are more like it not complaining loudly enough when somebody tries to brute-force the password the operator has set.
Don't get me wrong. "Lawful intercept" is a bad idea and a huge security hole in every vendor's products (not just Cisco's). But there's a big difference between a documented set of features that have bugs, and an intentional, hidden, sooper-sekrit "back door" with a fixed password.
All carrier products from all vendors have wiretapping support, because it's required by law in a boatload of places. It's stupid and evil to have those laws, but they were openly debated and openly adopted, and the technology that implements them is openly described. Furthermore, using it requires the carrier to participate in the wiretap process; law enforcement can't do it by itself. The problem those articles describe is that it's hackable... which is something the vendors, probably including Cisco, warned could happen when the laws were adopted.
No conspiracy there, I'm afraid.
Model numbers and versions, please.
Yes, EROS and I think KeyKOS, are totally persistent, and I don't think people are ready to program in that model, if we ever will be. But that's fixable; there's no intrinsic connection between capabilities and never reinitializing anything. It's convenient, but not necessary.
It's OK that I broke C. It's not type safe anyway. :-)
Seriously, though, you're getting to one of the real limitations; there are some programs that really do need access to a lot of stuff. A compiler does need access to all the library declarations. And most programs need access to a lot of different services. Even so, there's a big difference between the equivalent of /usr/include
and the whole system.
One of the points of the model is to force people to pick and choose what access programs need. One of the challenges would be to avoid ending up with a situation where people just habitually gave every program capabilities for everything because it was easier. That would require both cultural changes and good enough tools that you weren't constantly having to fight the system to get anything done.
There's an analogous weakness at the user level: "Drag your Quicken file onto this window to win $1000.". Mandatory data tagging could help there, but it's not going to solve everything, and it turns out to be a real big PITA.
There will always be ways to get users to hose themselves. Even so, better the user should lose the Quicken file than the whole machine.
So, lots of work, lots of cultural changes, and, yeah, you can expect to rewrite every significant program from scratch, including the runtime libraries. I did say that I wasn't optimistic. But I do think that such big changes are a necessary, if not a sufficient, condition for a qualitatively more trustworthy desktop.
I see one possible path forward. The way things are going, we're going to end up with every program in its own VM anyway, as people try to protect one part of the system from another. The next thing people will want will be ways to let those VMs interact. If those ways are designed intelligently, we might get another crack at the isolation that wasn't done in the current generation of operating systems. VMs would play the role that programs or processes take today, and you could be giving VMs capabilities to talk to each other.
It would be grossly inefficient, but if the VMs are going to happen anyway, we might as well do it right. Unfortunately, getting people to do it right will be a huge, and possibly insurmountable, educational challenge, for much the same reasons that put us where we are today.
You can have filenames; you just keep them in a namespace that's accessible only to the user (or the user's file manager or whatever). If you have a CLI, you type "program <filename>", and the CLI runs an instance of that program and gives it a capability to that file, rather than passing it the name. If you have a GUI, you probably do something like dragging the file onto the program, and the UI creates an instance of the program and passes it the capability.
You're correct that most programs wouldn't be able to have their own open dialogs. They'd have to rely on capabilities passed in from the user's file manager. Probably you'd express that by dragging again. That's actually more "desktop" than having an open dialog anyway.
You could support thumbnails by having a little program that generated a thumbnail from a file and did nothing else. Since you can prevent that program from leaking the information from the files, it's relatively safe to have the file manager call it with a read-only capability to every file in turn, and display the results.
The same applies to things like indexers. Although they'd be relatively powerful and dangerous, they wouldn't be remotely as dangerous as the simplest program in today's OSes, because you could prevent them from leaking the information to anyplace other than their indexes.
If you want to insert a file into a document, that looks like another drag operation. You drag the file into an existing instance of a program, rather than onto a factory icon.
It's pretty easy not to pass the same capability to multiple programs or instances of the same program (and pretty easy for them to detect it if you do, assuming they have write access to the file, or assuming you have a reasonable set of locking primitives).
Yeah, you'll lose some memory to separate instances. You can share all the program text, but the heap is gonna suck up space. It would presumably pay to be economical about building huge "dynamic" structures every time anybody ran your program. On the other hand, think of all the space you won't be wasting on every program having its own open dialog...
Capdesk isn't really unpleasant conceptually, if you want a toy example.
It's not free, and it can't be invisible to the user, but it's not so horrible as all that.
I have SELinux on my desktop, although it's not as tightly configured as it could be. I'm typing this on it.. It's not what I want, and I don't think it can be made into what I want.
The problem with SELinux is that it falls into the classic "reference monitor" trap, where some outside piece of code tries to intuit the intent of something like a system call. It's a layered-on kludge, like a firewall.
I want something more like KeyKOS or EROS, perhaps with a layer of something like (but not identical to) MLS a la Bell and LaPadula, or some kind of compartment tagging system. In SELinux, I can still say "fopen (/etc/passwd)". In KeyKOS, "/etc/passwd" isn't even a defined name for me; if I need that file, I'll be given an opaque handle for it, which I can then store in my own name space if I want to.
It is not enough to layer on some kind of reference checker if the underlying programs assume that they have access to everything. One of the big reasons that SELinux is a PITA is that the behavior of the programs its trying to control is so complicated and irregular, and the people writing the programs aren't the people writing the SELinux configurations. Without big changes in the APIs and ways of doing things, it's really hard to guess what a program may try to do or what it needs.
SELinux also doesn't have the sort of granularity it would need for network access control. You only get control up to the socket layer. To do it right, you'd need to rearchitect the whole stack, so that you could give programs restricted access at whatever layer was appropriate. It should be possible to express "this program can get this URL (or, better yet, this opaque network handle), but not this other URL".
So, suppose I'm the business end of a botnet.
What does administrator access give me?
Sure, I'll take if I can get it, because it might come in handy. But how important is it to me, really?
If I want to steal the user's credit card number, it's right there in a Quicken file. No admin access required.
If I want the user's contact list, it's in Outlook or whatever.
If I want to steal the user's passwords, no problem, I can still hook the keyboard one way or another, or just grab them from the browser's password store.
I may not be able to rewrite the browser, but I can debug the browser process and get the same effect.
If I want to run the webcam, no privileges are required.
If I want to send spam, I can make a TCP connection without administrator access.
OK, I may have trouble hiding myself as well as I'd like from privileged anti-malware programs, or make it monstrously hard for them to remove me. There are a few things I can't change on the local system. I probably can't hook file system or network access, and if I can it's probably for only one user. There are a few not-that-important services I can't talk to. I can't mess with the lower layers of the network very much. I can't create another user. It would be nice to be able to do those things. But it's not like I'm seriously handicapped without administrator access. And, since I also have access to run privileged programs or send requests to privileged services, I have a huge surface available to attack with 'sploits if I do want administrator access.
Same on Linux. Yeah, there are differences, but they're down in the noise; they aren't the sorts of qualitative things that would really matter in terms of making the desktop trustworthy.
The fundamental security model of Linux is no better than that of Windows. The main reason Windows gets nailed is that it's more profitable to write malware for Windows than for anything else. If Linux had the market share of Windows, it would have as much, or nearly as much, malware.
In either Linux or Windows, being able to run any code at all gives you essentially complete access to the user's data, plus almost unlimited access to system resources, plus the ability to talk to the network. Who cares if you're not running as root if everything interesting is owned by the user's account?
There are ways to make systems more secure, starting with strong containment. How strong? Strong enough that your program can't even express the desire to, say, open a file that the user hasn't given it a capability for. Strong enough that the user has to jump through hoops to give certain programs access to certain data. Especially programs with network access... which need to be only the programs that actually need it. Strong enough to subdivide lots of functions that people are used to putting together in the same process. Strong enough that you can forget about most of the APIs you're used to coding with. And, if you're going to run apps out on the network, that whole system has to extend out into the network as well.
On top of that, people ought to be using tools that make it a lot harder to express common security bugs, and that help you to notice when you've created others.
If this is to be fixed, users and programmers are going to have to change the ways they do things. I'm not super optimistic.
Linux helps not at all. Even OpenBSD wouldn't help much.
Um, no.
"Clean" slides are at least as dangerous as cluttered ones.
If your message does not fit on a slide, then don't use a fucking slide.
Some things are too complex to be reduced to bullets. The answer to that is not to bury the complexity in supplemental material that nobody will ever read. All that does is to create the illusion of comprehension... more dangerous than knowing that you don't have a clue. If you know you don't know, you'll either find out, or you'll let somebody else deal with the problem. If you think the problem is simple, but it's not, you'll make stupid decisions.
Don't put up a bunch of "keywords" on a screen to hypnotize the audience. SPEAK to the audience. Flash keywords if you must, but don't leave a slide up there for people to read while they miss the thread of what you're saying, or forget to think about anything that doesn't happen to have fit into the five available lines. And leave yourself some flexibility to respond when they're not getting it, instead of blindly continuing down the track your slides set for you.
Don't waste a lot of time making pretty slides, either. They're basically distracting and misleading. In fact, maybe you should write those keywords on a blackboard.
Is all your information in your slides? Can you say, with a straight face, "read my slides and you'll understand"? Then that's not a presentation. That's what we used to call a "document". Use a document preparation tool for that, not a presentation tool.
Is it too complicated to say in a presentation? Then a document is indeed right for you. Write one. Let people read it. MAKE them read it; don't give them a simplified spoon-fed version that produces false understanding. That's right, people need to actually read and write real text. Can't read and write? Sorry, you don't belong here.
Sure, use charts and graphs. That's what PowerPoint is actually good for. Make sure your analysis and data presentation are respectable, though... you can easily create a graph that gives a thoroughly wrong impression of what's important.
And that Afghanistan slide actually makes a great point. It says "This is complicated, you idiots. Don't knee-jerk". That's a slide I might actually use.
I didn't know that about compartmentation. It's good news. Thank you for answering my ignorance with actual information...
I still don't buy the code inspection thing. Even if Apple ramped their inspection WAY up (to levels they could never afford), I don't think it would stop anybody. It's just too easy to slip a subtle bug past a reviewer. Even if it got to the point of Apple spending $10K for reviews on every revision of every app, I'm pretty confident that within a couple of years, getting around that would be seen as a basic skill in the Bad Guy community. Sure, there'd be some deterrence, but worth the cost?
I'm 100-minus-epsilon percent sure that I could join the iPhone developer program in such a way that neither Apple nor the cops could trace me. The epsilon comes from the fact that I'm working from general knowledge rather than Apple-specific knowledge. I've never seen one of those programs that did any real verification of who was joining. It'd cost you a fortune per developer to do it. There's also the tack of just stealing the credentials of a legitimate developer. If they weren't on Macs, I could just pay a botmaster to give me a set. :-)
As for turning off apps, if it were done with your "greylists" it sounds like a big win. That's the beginning of the kind of global reputation system that could do you some good. You could even have the greylist give the user the reason something had been turned off, and let the user decide what to do. However, if it's done by Apple with no user choice, then the very depths of my soul start screaming out "single point of failure". And, anyway, how much damage can I do before they notice?
As a security person of about 20 years' standing, I'd like to protest that Apple's whitelist doesn't help, and that not all of us have ever asked for whitelists.
No realistic level of code review will detect subtle, deliberately introduced security holes. It won't even detect a lot of accidental ones. I guarantee you that I can write you an iPhone app that passes Apple's (fairly cursory) code reviews, passes any static analysis they apply, and still gives total, remote control of all the interesting data on the phone to anybody who knows some magic incantation.
Remember the halting problem? Code inspection isn't an effective security measure (packet inspection isn't much better, by the way).
Really, what you need most is compartmentation, so that the user can't be screwed by a bad app even if that app gets to run. The way Android does things, with fine-grained permissions and a sandbox for each app, isn't bad, except that the attack surface (the whole Linux kernel, plus other stuff) is too big. A microkernel that enforced a fine-grained capability system, possibly coupled with sticky compartment tagging of data, would help a lot... but every programmer would have to relearn everything to code to it. To get real security, you have to give up things like global file system name spaces.
After that, you need a realistic way for the user to evaluate the motives and trustworthiness of the source of a piece of code. I guess Apple could theoretically help with that on the iPhone, but they don't do it at the moment. In fact, nobody does it, becuase it's really, really hard to do it effectively.
Your family individually, personally contacts the people they know were close to you. Those people fill in the gaps. No, it's not fun. But it's necessary. I've done it. I'll probably be doing it again in a few years.
If actually know somebody well enough to really care if they've died, it's pretty cold to have to read about it in the newspaper. And it's pretty lazy to use the newspaper as an escape hatch.
The good news is that you can do a lot of it by e-mail. An awful lot of older people use e-mail these days, maybe because they're old and wise enough to realize that correspondence and face to face contact aren't, in fact, mutually exclusive. Maybe they even remember when it was actually hard to travel to see somebody, and you sent, you know, letters...
Anyway, which paper should I publish the notice in, given that all those friends have probably also moved?
I'm not sure that learning Morse is meaningful "learning" or a useful "challenge". It's just an artificial barrier, like being willing to grind in an MMORPG... and it gives you just about as much generally useful skill. CW isn't even the best way to get through with a weak signal on a noisy channel any more. It's a relic.
If you want a challenge, why not make people demonstrate some real knowledge of electronics (not just soldering together kits), antennas, propagation, coding theory, or whatever? There's important and generally useful knowledge involved in radio, but Morse code isn't it. I've never had a ham license, but the sample tests I've seen have been very light on actual radio engineering. The lower classes have essentially none, and the higher classes have less than they might have. And they're all multiple choice. Let's license people who really understand how their equipment works, can create new designs, can solve real problems. That's a more meaningful barrier... and a lot more fulfilling thing to learn than decoding beeps.
It's a bid deal because the contract is monstrously one-sided, and you'd think nobody would agree to it, yet somehow it manages to fly in a big chunk of the mobile phone market.
It seems like you'd have to be nuts to invest in developing for the App Store, other than maybe for short-term, tactical purposes. Why, then, do so many people do it? Isn't that an interesting question?
Apple has repeatedly demonstrated itself to be an unreliable, capricious business partner. Apple is slow and inconsistent about approving apps. It changes the rules and yanks apps all the time... just as this agreement permits it to do. It makes errors that cost you money and doesn't compensate you. Apple has shown, repeatedly over the whole life of the App Store, that those overreaching clauses aren't just in that contract for CYA purposes. Apple fully intends to use those clauses to hose your business if it feels like it for any reason whatsoever, and the reason may have little or nothing to do with you.
Personally. I won't even buy Apple's phone because of the way they handle software. Nonetheless, many people seem to be willing to bet their livelihoods on Apple. That includes people who aren't big players, and lack the leverage to make it to Apple's advantage to forget about certain contract terms.
What's the reason for that? Even if the answer just turns out to be that they're stupid, it's valuable to look at the question. Heck, you might even get some of them to smarten up.
If the answer is not that they're stupid, but, say, that they don't have any better options, then one might want to think about why we have a market that doesn't provide any better options. Maybe there should be some changes. Maybe somebody reading this will figure out how to make them. I think there are better options, but obviously those developing for the iPhone think otherwise. Maybe they can explain why?
And, yeah, it's about rights. First of all, the whole point of any contract is that you give up some rights. Second, the law, and the underlying moral philosophy, sometimes have some nasty things to say about one-sided contracts, interference with competition, artificial limitations of liability, and the like. Not everybody agrees, but there's a perfectly respectable and intellectually consistent body of thought that says a contract like that shouldn't be legal.
The problem with having perspective about this kind of thing is that it makes your posts really long. And my posts already run too long. So I took the chance that people would read me too literally, in order to keep what I wrote brief. Guess I lost that bet.
Yes, you're right. There's a tradeoff. Nobody is going to accept certain death. Even if they'll accept it for themselves, they're not going to accept certain death for everybody.
Look at the context in which I was writing; I was objecting to the parent post's unwillingness to admit that there was any risk. All I was really trying to convey was that even if there is some risk, that doesn't magically dispel the evil of doing the wiretapping... and also, perhaps clumsily, that there isn't enough risk to outweigh that evil.
You write:
What does that mean? My life and my family's lives are as much on the line as anybody's. Nobody knows who might get hit by this risk. I'm not sitting in a bunker somewhere.
For the record, the "thing you don't do" is to turn into an authoritarian gargoyle based on a small statistical risk. Another thing you don't do is to spy illegally, in contravention of your oath of office, based on anything short of a major existential threat. And nobody seriously believes that there's a major existential threat here.
You also write:
I don't believe I used the word "fighting" anywhere. And by "these people", I meant the people doing and defending the wiretapping. The wiretappers do not, as far as I know, think that "we", whoever "we" are, are the scum of the earth. They seem to have different moral values than I do, but I don't think they hate the populace at large. Quite the contrary.
As for "moral high ground", yes, the wiretappers are in fact knowingly yielding the moral high ground. "Moral high ground" is a common expression referring to how the world at large sees the morality of your actions. It's only coincidentally related to their actual morality. It means, basically, the PR value of the morality of your actions. Are you going to claim that illegal wiretapping makes people think you're more moral, or that the wiretappers think that illegal wiretapping is good PR for them? I don't think they're that dumb.
I get the feeling that by "these people", you mean the terrorists. I have nothing to say to that, other than to mention that terrorists are human beings with human motivations. It's easier to recruit new terrorists to hate an establishment that's generally seen as evil than it is to recruit them to hate an establishment that's seen as fair and moral.
No, you're wrong.
It's not "We need to respect our constitution, even if it makes our security agencies do a little more work.".
It's "We need to respect our constitution, even if some of us die".
By not addressing their arguments head on, you give the bad guys strength. This is a matter of principle; you don't need to hide from their safety claims.
I don't actually believe that these methods save lives in the long run. I think that these people underestimate the real, physical risks of making enemies and losing the moral high ground. But I could be wrong. It's possible that there is some increase in safety.... small, compared to the risk of say driving a car, but real nonetheless. The point is that this stuff is wrong even if it does make people safer.
Fuck the cowards. There are some things you don't do.
You didn't read the article, did you? They didn't say one word about preventing people from modifying their own robots. There wasn't the slightest mention of any such thing. The whole issue of "preventing modification" did not come up in the article. At all. Not explicitly. Not by implication. Not by suggestion. Not at all.
The article complained, very specifically, that the robots, when you took them out of the box, didn't enforce passwords where they should, and/or that they didn't encrypt network traffic that should be encrypted. The concern was that it was therefore easy to compromise somebody else's robot without physical access to it. The issue of unauthorized access to media streams was emphasized.
And, yes, the same issues would exist if you had a camera with crappy security and no wheels. So what? They were looking at robots, not cameras.
By the way, encrypting WiFi is actually a pretty crappy way to secure this, because it means that there's still no encryption if you communicate with the device over the Internet. The most important encryption is end-to-end encryption. Encrypting the link layer is icing on the cake.
They want you to play with them and make them do cool things. They don't necessarily want other people to drive up outside your house and use the robots' cameras and microphones to spy on you over WiFi. The problem is that the features that enable the first aren't secured, and therefore they can also be used to do the second.