Culp says, "When you choose to run a program, you are making a decision to turn over control of your computer to it."
That is a design decision they made, not an immutable law of the universe. Windows is intentionally designed so that when you run a program, it runs with your identity and all your privileges. It is conceivable that one could design a system that handled privileges differently, and of course people have designed such systems. (One of them is the browser you are using right now, if it supports JavaScript.) Therefore, this is not a "law." It's a design flaw. To call it a "law" is to evade responsibility for making that design decision.
I'm not saying operating systems have no bugs. There's a big difference between creating a system that is broken by design, and a system that happens to have a bug in it. The unattainability of perfection is no reason to ignore security altogether. Consider the context here -- Larry is citing this "law" as a reason to ignore threats. In doing so, he is ignoring defense in depth. The operating system should isolate and protect applications, AND applications should be written defensively.
You appear to be saying that it's infeasible to limit the privileges of programs just because it's inconvenient in Vista. I hope you don't expect anyone to take that argument seriously -- "Microsoft did it poorly" is hardly evidence that something isn't possible.
The thinking behind Law #1 -- that when a user runs a program, that program automatically gets full rights to pull all the user's privileges out of thin air and exercise them in whatever way it wants -- runs counter to all of these fundamental security concepts.
Running a program should not mean handing over rights to everything "you yourself can do on the computer."
I see they're still using the old, tired, "Immutable Law #1" that Scott Culp made up many years ago.
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore [...] When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer.
It's simply wrong, and it's deceptively named.
One of the important jobs of any operating system is to isolate and protect applications from one another. To assume the so-called "Immutable Law #1" is to pretend that this responsibility doesn't exist.
I'm sure they've heard of encapsulation, right? Defense in depth? How about the principle of least privilege? The thinking behind Law #1 -- that when a user runs a program, that program automatically gets full rights to pull all the user's privileges out of thin air and exercise them in whatever way it wants -- runs counter to all of these fundamental security concepts.
A revision of the Law that's somewhat closer to the truth would be something like: "If a bad guy can persuade you to run his program on your computer, and your operating system allows that program to damage the system, other programs, or your data, it's not your computer anymore." The operating system does not get a free pass.
No, it's not quite the same. The choices are presented to the voter by a machine rather than on a printed piece of paper. This means the machine can lie to the voter.
In a simple election, the voter might easily detect when the machine lies. But for a U. S. election, which might have dozens of contests, the machine could lie in many ways with a low chance of being noticed (e.g. omit a contest, change the wording of a proposition).
The machine doesn't even have to lie outright. All it has to do is bias the measurement: feature one option somewhat more prominently, be slightly more likely to malfunction for certain voters or choices, etc.
An electronic ballot printer is still a lot better that having no paper ballot at all, but it's not as straightforward to assure fairness as with a hand-marked paper ballot.
Thank you for taking the time to refute (yet again) this common suggestion -- it seems to crop up in every voting discussion. We'll have to keep repeating the counterargument for a while to stamp it out.
Even if you think that, if it's not a bomb, why can't she be released?
People should be smart enough to know not to go wandering around with that kinda stuff like that.
We don't point guns at people, arrest them, and charge them just for not being "smart enough". Being "not smart enough" is not a crime. She was no threat to anyone. The fault is with the security personnel for the ludicrous misidentification of blinking lights as a bomb and for choosing to respond to this by surrounding her with machine guns.
There were three source code reports released -- for Diebold, Hart, and Sequoia, not just Diebold. All three systems had serious weaknesses, including viral propagation vectors. All of the reports are worth checking out.
I have yet to hear a reasonable argument for electronic voting machines over tried and true optical scan ballots for any criteria
Uh, you just gave one: accessibility.
Electronic voting machines, in general, offer more possibilities for user interfaces beyond paper. This can mean better accessibility, better usability, more languages, or ways of helping voters detect and correct mistakes. That to me seems to be the strongest set of arguments on the "pro" side of the balance.
The arguments on the "con" side you've already mentioned -- lack of transparency, complexity, and greater difficulty assuring security and reliability.
It's entirely reasonable to argue that one side outweighs the other, but I don't think it's fair to completely discount the arguments on either side.
Communities are tended and grown into healthy, fun, productive communities. They are not made that way merely by declaring them so.
This Code of Conduct is being presented as if a central entity is trying to own the process, and that's just not going to fly. Respectfulness is not something that can be owned and branded with a name and a logo.
A person can make a "fair dealing" with copyright material for any of the following purposes:
research or study;
criticism or review;
parody or satire;
reporting news; or
professional advice by a lawyer, patent attorney or trade marks attorney.
The above is quoted from their Information Sheet on Fair Dealing. The third page of that document has more detail on "Fair dealing for parody or satire" and draws a distinction between parody and satire:
A parody is an imitation of a work, and may include parts of the original. In some cases, a parody may not be
effective unless parts of the original are included. It seems that the purpose of a true parody is to make some
comment on the imitated work or on its creator.
The purpose of satire, on the other hand, is to draw attention to characteristics or actions - such as vice or folly -
by using certain forms of expression - such as irony, sarcasm and ridicule. It seems that both elements are
required: the object to which attention is drawn (vice or folly etc) and the manner in which it is done (irony,
ridicule etc). It is not clear, for example, that a work which uses irony or ridicule about something other than
something like vice or folly would be satire.
[...]
It is not so clear that use of a copyright work for satiric purposes would be as likely to be "reasonable" in all the
circumstances. This is because, unlike parody, the object of satire is generally not the copyright material itself or
its creator(s). The copyright material used may enhance a work that has a satirical purpose, but is unlikely to be
necessary for the for the satirical purpose.
The argument in favour of message queues instead of shared state isn't just about Java; Java is just an example. I am fairly sure that the Observer problem (and other simple coordination problems) are hard to solve reliably on any platform based on the conventional multithreading paradigm as taught in most computer science departments (threads, mutexes, critical sections, etc.).
I think you may have misunderstood the problem. You don't get to specify how your clients behave; the challenge here is just to implement the publish/subscribe component (the "Subject").
"must be kept up to date" is ill-defined. What ordering of updates to you want? A properly implemented Subject should guarantee that the last notification sent to each subscriber contains the last value that was published.
Then don't allow changes while a publish is in progress, or have a queue of outstanding publishes. You can't lock out changes while a publish is in progress, because then any client trying to publish would cause a deadlock, and you don't get to specify what the clients do.
Using a queue of outstanding publishes is heading in the right direction: toward event-queue concurrency instead of shared-state concurrency (which is the point i was originally trying to make).
This sounds pretty much like event queueing, similar to the solution proposed by the paper i linked to.
Notice that this is no longer "shared-state" concurrency. If every object is running in its own thread, no threads share state. I think you've helped prove my point (shared-state concurrency is hard and ought to be avoided).
If publishing triggers a subscriber to trigger another publish, that's either programming error or intended behavior in my book. A strict reading of the spec you've provided suggests we must notify all subscribers all publishes, not merely the newest. No problem with that. For correctness we just need to make sure that the last update received by each subscriber contains the latest published value.
My approach, without reading the paper, would be to make a copy the subscriber list on a publish. Indeed, this is exactly the solution considered in the discussion (section 4.2 of the paper). But if you have a notification loop like this:
for (Subscriber subscriber: subscribers) {
subscriber.notify(value);
}
and it isn't synchronized, the notifications can arrive out of order.
I'm not saying you can't solve this problem. The point is, it's much trickier than almost all programmers are taught to realize. (This problem is easy to solve if you use event queues instead of multiple threads.)
Shared-state concurrency is harder than you think.
on
An Overview of Parallelism
·
· Score: 5, Insightful
Reliably achieving even simple goals using concurrent threads that share state is extremely difficult. For example, try this task:
Implement the Observer (aka Listener) pattern (specifically the thing called "Subject" on the Wikipedia page). Your object should provide two methods, publish and subscribe. Clients can call subscribe to indicate their interest in being notified. When a client calls publish with a value, your object should pass on that value by calling the notify method on everyone who has previously subscribed for updates.
Sounds simple, right? But wait:
What if one of your subscribers throws an exception? That should not prevent other subscribers from being notified.
What if notifying a subscriber triggers another value to be published? All the subscribers must be kept up to date on the latest published value.
What if notifying a subscriber triggers another subscription? Whether or not the newly added subscriber receives this in-progress notification is up to you, but it must be well defined and predictable.
Oh, and by the way, don't deadlock.
Can you achieve all these things in a multithreaded programming model (e.g. Java)? Try it. Don't feel bad if you can't; it's fiendishly complicated to get right, and i doubt i could do it.
Or, download this paper and start reading from section 3, "The Sequential StatusHolder."
Once you see how hard it is to do something this simple, now think about the complexity of what people regularly try to achieve in multithreaded systems, and that pretty much explains why computer programs freeze up so often.
Security is all about preventing undesirable events.
True — but so is usability. It improves both security and usability to ensure that desirable events do happen and undesirable events don't happen.
Even if we add a wonderful UI to security, it will never be perfect.
Real usability isn't about "adding a wonderful UI" to things. Real usability means changing what the system requires you to know, changing how the system forces you to do things, and changing how the system responds to your actions, so that it does what you're telling it to do. If the computer knows what you're telling it to do, it can set the security parameters appropriately to suit your intent.
Security is about saying "no", ease of use is about saying "yes."
This is a common argument about the conflict between security and usability. I agree with you that it holds today for many systems, because those systems embed the idea that security is an indiscriminate no and usability is an indiscriminate yes. However, i believe it doesn't have to stay true. If we design systems from the ground up that are centered on user intent, good security and good usability both follow.
If you have a few minutes, you might want to look at an article i wrote about this last year.
Slashdot Mirror
Culp says, "When you choose to run a program, you are making a decision to turn over control of your computer to it."
That is a design decision they made, not an immutable law of the universe. Windows is intentionally designed so that when you run a program, it runs with your identity and all your privileges. It is conceivable that one could design a system that handled privileges differently, and of course people have designed such systems. (One of them is the browser you are using right now, if it supports JavaScript.) Therefore, this is not a "law." It's a design flaw. To call it a "law" is to evade responsibility for making that design decision.
I'm not saying operating systems have no bugs. There's a big difference between creating a system that is broken by design, and a system that happens to have a bug in it. The unattainability of perfection is no reason to ignore security altogether. Consider the context here -- Larry is citing this "law" as a reason to ignore threats. In doing so, he is ignoring defense in depth. The operating system should isolate and protect applications, AND applications should be written defensively.
You appear to be saying that it's infeasible to limit the privileges of programs just because it's inconvenient in Vista. I hope you don't expect anyone to take that argument seriously -- "Microsoft did it poorly" is hardly evidence that something isn't possible.
One of the important jobs of any operating system is to isolate and protect applications from one another. To assume the so-called "Immutable Law #1" is to pretend that this responsibility doesn't exist.
I'm sure they've heard of encapsulation, right? Defense in depth? How about the principle of least privilege? The thinking behind Law #1 -- that when a user runs a program, that program automatically gets full rights to pull all the user's privileges out of thin air and exercise them in whatever way it wants -- runs counter to all of these fundamental security concepts.
A revision of the Law that's somewhat closer to the truth would be something like: "If a bad guy can persuade you to run his program on your computer, and your operating system allows that program to damage the system, other programs, or your data, it's not your computer anymore." The operating system does not get a free pass.
No, it's not quite the same. The choices are presented to the voter by a machine rather than on a printed piece of paper. This means the machine can lie to the voter.
In a simple election, the voter might easily detect when the machine lies. But for a U. S. election, which might have dozens of contests, the machine could lie in many ways with a low chance of being noticed (e.g. omit a contest, change the wording of a proposition).
The machine doesn't even have to lie outright. All it has to do is bias the measurement: feature one option somewhat more prominently, be slightly more likely to malfunction for certain voters or choices, etc.
An electronic ballot printer is still a lot better that having no paper ballot at all, but it's not as straightforward to assure fairness as with a hand-marked paper ballot.
Mod parent up.
Thank you for taking the time to refute (yet again) this common suggestion -- it seems to crop up in every voting discussion. We'll have to keep repeating the counterargument for a while to stamp it out.
We don't point guns at people, arrest them, and charge them just for not being "smart enough". Being "not smart enough" is not a crime. She was no threat to anyone. The fault is with the security personnel for the ludicrous misidentification of blinking lights as a bomb and for choosing to respond to this by surrounding her with machine guns.
There were three source code reports released -- for Diebold, Hart, and Sequoia, not just Diebold. All three systems had serious weaknesses, including viral propagation vectors. All of the reports are worth checking out.
This is a duplicate of the (still front-page Slashdot) story posted by CowboyNeal.
Please post a story about the Secretary of State's decision restricting the use of these machines.
I've sliced up the audio of the public hearing and posted it at http://usablesecurity.com/ttbr/. Enjoy, and feel free to pass it on.
I have yet to hear a reasonable argument for electronic voting machines over tried and true optical scan ballots for any criteria
Uh, you just gave one: accessibility.
Electronic voting machines, in general, offer more possibilities for user interfaces beyond paper. This can mean better accessibility, better usability, more languages, or ways of helping voters detect and correct mistakes. That to me seems to be the strongest set of arguments on the "pro" side of the balance.
The arguments on the "con" side you've already mentioned -- lack of transparency, complexity, and greater difficulty assuring security and reliability.
It's entirely reasonable to argue that one side outweighs the other, but I don't think it's fair to completely discount the arguments on either side.
Communities are tended and grown into healthy, fun, productive communities. They are not made that way merely by declaring them so.
This Code of Conduct is being presented as if a central entity is trying to own the process, and that's just not going to fly. Respectfulness is not something that can be owned and branded with a name and a logo.
Quantum physics can be mathematically modelled, just as Newtonian physics can. It may be counterintuitive, but it's not magic.
The argument in favour of message queues instead of shared state isn't just about Java; Java is just an example. I am fairly sure that the Observer problem (and other simple coordination problems) are hard to solve reliably on any platform based on the conventional multithreading paradigm as taught in most computer science departments (threads, mutexes, critical sections, etc.).
Using a queue of outstanding publishes is heading in the right direction: toward event-queue concurrency instead of shared-state concurrency (which is the point i was originally trying to make).
This sounds pretty much like event queueing, similar to the solution proposed by the paper i linked to.
Notice that this is no longer "shared-state" concurrency. If every object is running in its own thread, no threads share state. I think you've helped prove my point (shared-state concurrency is hard and ought to be avoided).
for (Subscriber subscriber: subscribers) {
subscriber.notify(value);
}
and it isn't synchronized, the notifications can arrive out of order.
I'm not saying you can't solve this problem. The point is, it's much trickier than almost all programmers are taught to realize. (This problem is easy to solve if you use event queues instead of multiple threads.)
Implement the Observer (aka Listener) pattern (specifically the thing called "Subject" on the Wikipedia page). Your object should provide two methods, publish and subscribe. Clients can call subscribe to indicate their interest in being notified. When a client calls publish with a value, your object should pass on that value by calling the notify method on everyone who has previously subscribed for updates.
Sounds simple, right? But wait:
- What if one of your subscribers throws an exception? That should not prevent other subscribers from being notified.
- What if notifying a subscriber triggers another value to be published? All the subscribers must be kept up to date on the latest published value.
- What if notifying a subscriber triggers another subscription? Whether or not the newly added subscriber receives this in-progress notification is up to you, but it must be well defined and predictable.
- Oh, and by the way, don't deadlock.
Can you achieve all these things in a multithreaded programming model (e.g. Java)? Try it. Don't feel bad if you can't; it's fiendishly complicated to get right, and i doubt i could do it.Or, download this paper and start reading from section 3, "The Sequential StatusHolder."
Once you see how hard it is to do something this simple, now think about the complexity of what people regularly try to achieve in multithreaded systems, and that pretty much explains why computer programs freeze up so often.
The E language has a very interesting and powerful approach to concurrency that avoids many of the trickiest problems with threads. Have a look at the paper Concurrency Among Strangers: Programming as Plan Coordination by Miller, Tribble, and Shapiro.