...more to the point, if you own a gun, you leave it lying around loaded, and your cat manages to set it off and kill someone with it, yes, you probably are liable for that.
Of course, this is true only if you are actually capable of editing the source code to fix the bug in a way that you are confident will not harm the program (introducing new security flaws, crashes, data loss, rude emails to your mother, etc.) Some bugs are "I forgot to check that this wasn't 0". Some bugs are subtle conceptual flaws in application design. Some fixes are dangerous.
Is your system administrator really capable of patching the code for every critical application on the system? I don't mean this from a "most sysadmins are dumb" perspective or anything; just that most sysadmins probably do not understand the internal workings of every app they are running well enough to patch them right away, nor are they sufficiently wizardly to read over the source and understand it in an afternoon.
Also--does management really want to take the risk of having them try?
And "binaries are themselves fairly trivial to interpret" is a vast overstatement. There are some things that aren't all that hard to spot in binaries, but there are plenty of things that are pretty damn hard. It's certainly going to be appreciably harder than reading source code.
And of course there are more counterarguments. Sure, having more eyes is nice---but how many people really read the source? Joe OSS user just downloads prebuilt binaries from the internet (or maybe he runs Gentoo, but he still doesn't have to _read_ the source). You still have some advantage, yes, but how much? I honestly don't know if there are any well-researched numbers on how many people seriously look over OSS code they haven't developed, but I suspect it's a lot smaller than the userbase. And you _have_ made it easier for potential attackers to find exploits...so which of those outweighs the other?
I'm by no means claiming that OSS is less secure than closed software (personally I think that the competence of the people designing and administrating the software is far more important the open/closed issue), but I think it's silly to say that OSS is "fundamentally more secure" based on simplistic reasoning like what you mention. There are intuitively appealing arguments on _both_ sides, and it's really a matter for empirical evidence.
"Virtual memory" in the sense of doing address translation was _not_ created for on-demand paging: it was created because trying to do multitasking in a single address space sucks. It is _much_ nicer to let each process/task/address space/whatever perceive its own address space, allowing applications to always get linked where they want without stepping on other apps, easily have contiguous address ranges, etc.
Paging is basically just a freebie after you have virtual addressing working.
Now, the poster obviously was using "Virtual Memory" to mean "pagefile", because that's how Windows uses the term. But if OP misunderstood the usage, then his response was correct, just inapplicable.
Words listed as synonyms in Webster's Thesaurus have similar, not identical, meanings.
Merriam-Webster gives the following definitions:
Strategy:
1 a (1): the science and art of employing the political, economic, psychological, and military forces of a nation or group of nations to afford the maximum support to adopted policies in peace or war (2): the science and art of military command exercised to meet the enemy in combat under advantageous conditions.
Tactics:
1 a: the science and art of disposing and maneuvering forces in combat
The words are different, and their usage in chess corresponds to the dictionary meanings, exactly as OP indicated.
Lots of different reasons, really. It depends on how you split on the issues (it's also worth noting that the two are not perfectly linked, by any means).
From a constitutional point of view, it's really a question of strict/loose construction. From a strict constructionist/conservative point of view, the right to own guns is obvious ("the right of the people to keep and bear arms shall not be infringed"). The purported right to an abortion is much less so. Clearly it appears nowhere as such; it is inferred by a roundabout argument that various amendments create "penumbras" of privacy, which create a medical privacy right covering abortion. From a constitutionally conservative point of view that sounds a lot like "making shit up".
A different divide is the more traditional liberal/conservative one that's probably closer to what's happening in the political parties. Opposition to abortion is typically a religious moral thing. That same morality may well motivate a desire for self-defense and defense of others by owning guns. Also, deeply anti-abortion Christianity in particular is associated with parts of the country (read: rural areas) where gun ownership is more common for purely practical reasons. Conversely, support for abortion is typically found among a more progressive, liberal, urban crowd that has less personal experience with guns (and with living far from public services) and is more willing to rely on the state for protection.
Plus, two party politics creates artificial associations between issues. More to the point, it amplifies existing divides: if most people are pro-life and pro-gun or pro-choice and pro-gun control, naturally the two parties split that way and anybody who feels differently is just left out in the cold.
That seems to be a pretty hasty conclusion. For one thing, as far as the punishing the innocent bit goes, I think you're looking at it wrong. Consider it this way:
Without plea bargains, he gets 25 whether he's innocent or guilty. With plea bargains, he gets 25 if he's innocent, and get gets 15 and the state gets the body if he's innocent. So if he's innocent, the presence or absence of plea bargains is irrelevant. He's not any worse off because of the bargain. Of course if he's guilty, he does better (even than an innocent guy) with plea bargains, but so does the state (since they get the body in return). Whether the particular bargain is a reasonable one is a different question, but doesn't really affect the guilt/innocence issue.
To address the real issue more directly, it's a basic and necessary asumption of the justice system that the rate of incorrect convictions is very low. If it isn't, we're already completely screwed anyway. If it is, then these sorts of calculations need to take that into account. He gets 15 if he's guilty and 25 if he's innocent, but he's probably not innocent.
In this case, I wonder: wasn't Reiser committed wrongfully? Because if finding the body could turn the conviction from first degree to second degree murder it clearly means that first degree murder hasn't been proved beyond reasonable doubt. At least, "beyond reasonable doubt" doesn't seem like something that could be dispelled by examining a body that has been hidden for several years.
I don't think you understand the nature of prosecutorial deals. First degree murder was proved beyond a reasonable doubt, and as a matter of fact the body is not likely to change that (unless there's some overwhelming evidence that e.g. she died of natural causes). The DA is simply contemplating reducing the sentence (effectively, by reducing the charges) in return for Reiser cooperating (by giving them the body, which they'd really like). They don't need the body to prove things one way or the other, they just want to find it (to give the family closure and so on) and are willing to cut deals to get it.
And what if, after examining the body, evidence is found that death could have had a natural cause, or be a suicide? With that reasonable doubt, would the conviction be reversed?
Depending on the circumstances, new evidence could be considered. (Actually, I think that if he knew where the body was the whole time, he might not be permitted to present the new evidence because it was his fault for not disclosing the location at the original trial. Not sure how that would turn out). If he were permitted to present the evidence on appeal, and the court found it established a reasonable doubt, he would be acquitted.
It's an interesting question, to be sure.
In the drunk driving checkpoint case I mentioned, the court upheld the checkpoint because there was another way around; drivers could simply take different roads. Of course that would increase travel time somewhat, but it did not fundamentally remove the ability to drive from point A to point B. Here the government checkpoints cover all substantially similar routes (i.e. air travel), so perhaps the court would consider this a different situation.
Regarding the first question: what if your job required you to go to a government building where you go through a similar search? What if your job requires you to obtain a security clearance and submit to a poly and background check? Private jobs can require all sorts of things—the government isn't per se forcing you to submit to the search. I see your point, but I don't think it really holds up here (in particular because air travel is not mandatory for rather a lot of jobs).
They don't need a warrant if you submit. This is a basic premise of 4th amendment case law; if the goverment asks if they can search you or your property, and you say yes, that's all they need. Works for personal searches, houses, cars (this argument was used to defend certain kinds of drunk driving checkpoints because people were free to drive around them). You are not compelled to enter the secure area and board a plane; the TSA will not detain you if you walk away from the airport and go home. You are submitting willingly to a goverment search so your rights are not violated.
I think you have a misconception about the locking problem we're discussing. Understand that the BKL issue has nothing to do with userland or application programmers; it is a lock used internally in the kernel, and is only visible or relevant to kernel code.
By "real systems", I had real kernels in mind in particular. I'm not a kernel expert (certainly not a Linux kernel expert), but I have written a [small, toy, but functional] UNIX-y flavor kernel for class, so I can claim to know what I'm talking about generally.
Realize that "internal kernel structures" reaches basically everything living anywhere in memory. Realize also that modern operating systems are horifically concurrent. Lots of things are happening at once, and at any moment, someone can (and probably will) pull the rug out from under you. Concurrency is far uglier than in user land—even if a thread in a seperate process totally unrelated to the current thread starts to run, you still have to context switch, and that's still messy.
If you are reading data from hardware (or writing to hardware) you may need to lock things in memory.
If you believe in supporting mulitple threads/processes/runnables in the same memory space, locking the VM can be hilarious.
You certainly need some sort of data structure for understanding the memory layout across processes, which requires locking (god forbid you accidentally give out the same physical frame for two different things, or the same spot on disk, or whatever).
Filesytems live in the kernel, and certainly entail locking (and may combine kernel structures and hardware when you do disk I/O).
Big issue: Even though you don't want to spend much time in the kernel total, you have to go through kernel a lot (every time you take an interrupt). The scheduler should be fast, so shouldn't hold on to resources very long, but it has to run an awful bloody lot, and it certainly brings in locking issues. Any operations which would affect your runqueue (or whatever datastructure keeps track of your runnables) is thus complicated by locking. (This means yield, this means exit, etc). Also, exiting and waiting/jointing/etc., whether for threads or processes, brings their own forms of locking pain. And please don't even thinking about killing a multi-threaded process! (But, of course, you really want to be able to do that).
In sum, the locking issues in a kernel are exceedingly complicated and do not easily produce nice conditions.
This is one approach to deadlocks; it would fall generally under "avoidance".
The problem is that if you have any serious contention over the resources, it is entirely possible that the process will _never_ get the resources (because one of them always gets snatched up before another gets released, so all n resources are never available at once to the requesting process). This leads to starvation and general sadness.
If the system has minimal contention (so the normal case is that all three resources are unclaimed) and resources are held very briefly (so if a resource is taken it is likely to be released before another is taken, anyway) then it may work. In real systems these are hard properties to guarantee.
Also, the scheme requires a process to know in advance which locks it will need. A lot of algorithms may discover this on the fly (e.g. if you are traversing a data structure), which becomes a problem. The best you could hope to do is to lock aggressively--taking everything you might need--but this is ugly, and would tend to violate the conditions above (locking everything will lead to contention, locking everything in advance will lead to holding locks for a long time). Alternatively, if you discover that you need a new lock that you don't yet have, you could give up all the locks you do have and then try to lock again (with the new lock added to the set). This is also ugly and increases the chance of starvation (since now you need to lock a bunch of resources several times). Additionally, since you have to unlock in the middle, the algorithm becomes much more complicated. For example, when you discover you need a new lock, you must put the world in a consistent state before unlocking. And when you re-lock, you must check to make sure that the world hasn't been modified under your feet (which is entirely possible, and may very well cause you to need a still-different lock).
Glancing at the schema, it's clear that the database, while highly interesting from a structural point of view, doesn't actually contain any of the code or anything like that.
I'll bet he was smart enough to get it ok'd and I'll bet Microsoft was fine with it (after all, the paper does conclude that windows is comparable to the open source kernels)
The constitution doesn't limit the right to expression, assembly, and so on, on the condition that it be used to protect national security. It is a well-established principle of constitutional jurisprudence that executive power is strongest and constitutional protections weakest when national security is at stake.
And the principle of national security is that the people will die along with the government, which is a problem.
Also, as sibling notes, this is about censoring things for individuals outside the US, so the Constitution really says nothing.
In my experience (at CMU) that doesn't happen. A lot of people don't buy books because they just aren't necessary (you can get the problems from friends and a lot of times lecture notes + internet are good enough). However, when people actually do need books, they usually buy them. Most people get used copies from the bookstore, upperclassmen, or the internet, though.
As a graduating CMU SCS student, I'll point out that the bit about lots of job opportunities still holds. Recruiters make jokes about secret railroads connecting CMU and [major tech company] campuses. To some extent the highly competitive/demanding environment may hurt (in that you might get a lower GPA at the tougher school) but mostly that comes out in the wash. Being at one of the well respected schools is a huge plus in the job hunt, and I suspect it really does help you get a better grasph of CS.
There are good reasons for going to a liberal arts school, though. Although it's possible to take non-technical classes, it's not as good an opportunity. There's a fair amount of time (at least if you choose to minor in a non-technical field), but frankly a lot of the classes just aren't that good (CMU just can't compare to a good Lib Arts school in a lot fields) and so you may not get much out of it.
I would say it comes down to how your interests are divided. Both a good technical school and a good liberal arts are capable of giving you an education that is resonably strong in CS and also reasonably well rounded. If you have strong interests in the non-technical fields, you will probably be disappointed in the tech school, but if you don't, you will probably be disappointed in the libarts school.
Slashdot Mirror
...more to the point, if you own a gun, you leave it lying around loaded, and your cat manages to set it off and kill someone with it, yes, you probably are liable for that.
Actually most people I know really hate cars that put the controls in the wrong place.
Of course, this is true only if you are actually capable of editing the source code to fix the bug in a way that you are confident will not harm the program (introducing new security flaws, crashes, data loss, rude emails to your mother, etc.) Some bugs are "I forgot to check that this wasn't 0". Some bugs are subtle conceptual flaws in application design. Some fixes are dangerous.
Is your system administrator really capable of patching the code for every critical application on the system? I don't mean this from a "most sysadmins are dumb" perspective or anything; just that most sysadmins probably do not understand the internal workings of every app they are running well enough to patch them right away, nor are they sufficiently wizardly to read over the source and understand it in an afternoon.
Also--does management really want to take the risk of having them try?
And "binaries are themselves fairly trivial to interpret" is a vast overstatement. There are some things that aren't all that hard to spot in binaries, but there are plenty of things that are pretty damn hard. It's certainly going to be appreciably harder than reading source code.
And of course there are more counterarguments. Sure, having more eyes is nice---but how many people really read the source? Joe OSS user just downloads prebuilt binaries from the internet (or maybe he runs Gentoo, but he still doesn't have to _read_ the source). You still have some advantage, yes, but how much? I honestly don't know if there are any well-researched numbers on how many people seriously look over OSS code they haven't developed, but I suspect it's a lot smaller than the userbase. And you _have_ made it easier for potential attackers to find exploits...so which of those outweighs the other?
I'm by no means claiming that OSS is less secure than closed software (personally I think that the competence of the people designing and administrating the software is far more important the open/closed issue), but I think it's silly to say that OSS is "fundamentally more secure" based on simplistic reasoning like what you mention. There are intuitively appealing arguments on _both_ sides, and it's really a matter for empirical evidence.
But the point of the gas tax is that your tax is proportional to your usage of the infrastructure, which is obviously not true in this case.
No, no, he had to pat himself on the back about his degree, and his brilliant laziness. Definitely true CS fashion.
"Virtual memory" in the sense of doing address translation was _not_ created for on-demand paging: it was created because trying to do multitasking in a single address space sucks. It is _much_ nicer to let each process/task/address space/whatever perceive its own address space, allowing applications to always get linked where they want without stepping on other apps, easily have contiguous address ranges, etc.
Paging is basically just a freebie after you have virtual addressing working.
Now, the poster obviously was using "Virtual Memory" to mean "pagefile", because that's how Windows uses the term. But if OP misunderstood the usage, then his response was correct, just inapplicable.
It is definitely used to run native code as well.
You're looking for the truck number.
Words listed as synonyms in Webster's Thesaurus have similar, not identical, meanings. Merriam-Webster gives the following definitions:
Strategy: 1 a (1): the science and art of employing the political, economic, psychological, and military forces of a nation or group of nations to afford the maximum support to adopted policies in peace or war (2): the science and art of military command exercised to meet the enemy in combat under advantageous conditions.
Tactics: 1 a: the science and art of disposing and maneuvering forces in combat
The words are different, and their usage in chess corresponds to the dictionary meanings, exactly as OP indicated.
Lots of different reasons, really. It depends on how you split on the issues (it's also worth noting that the two are not perfectly linked, by any means).
From a constitutional point of view, it's really a question of strict/loose construction. From a strict constructionist/conservative point of view, the right to own guns is obvious ("the right of the people to keep and bear arms shall not be infringed"). The purported right to an abortion is much less so. Clearly it appears nowhere as such; it is inferred by a roundabout argument that various amendments create "penumbras" of privacy, which create a medical privacy right covering abortion. From a constitutionally conservative point of view that sounds a lot like "making shit up".
A different divide is the more traditional liberal/conservative one that's probably closer to what's happening in the political parties. Opposition to abortion is typically a religious moral thing. That same morality may well motivate a desire for self-defense and defense of others by owning guns. Also, deeply anti-abortion Christianity in particular is associated with parts of the country (read: rural areas) where gun ownership is more common for purely practical reasons. Conversely, support for abortion is typically found among a more progressive, liberal, urban crowd that has less personal experience with guns (and with living far from public services) and is more willing to rely on the state for protection.
Plus, two party politics creates artificial associations between issues. More to the point, it amplifies existing divides: if most people are pro-life and pro-gun or pro-choice and pro-gun control, naturally the two parties split that way and anybody who feels differently is just left out in the cold.
That seems to be a pretty hasty conclusion. For one thing, as far as the punishing the innocent bit goes, I think you're looking at it wrong. Consider it this way:
Without plea bargains, he gets 25 whether he's innocent or guilty. With plea bargains, he gets 25 if he's innocent, and get gets 15 and the state gets the body if he's innocent. So if he's innocent, the presence or absence of plea bargains is irrelevant. He's not any worse off because of the bargain. Of course if he's guilty, he does better (even than an innocent guy) with plea bargains, but so does the state (since they get the body in return). Whether the particular bargain is a reasonable one is a different question, but doesn't really affect the guilt/innocence issue.
To address the real issue more directly, it's a basic and necessary asumption of the justice system that the rate of incorrect convictions is very low. If it isn't, we're already completely screwed anyway. If it is, then these sorts of calculations need to take that into account. He gets 15 if he's guilty and 25 if he's innocent, but he's probably not innocent.
In this case, I wonder: wasn't Reiser committed wrongfully? Because if finding the body could turn the conviction from first degree to second degree murder it clearly means that first degree murder hasn't been proved beyond reasonable doubt. At least, "beyond reasonable doubt" doesn't seem like something that could be dispelled by examining a body that has been hidden for several years.
I don't think you understand the nature of prosecutorial deals. First degree murder was proved beyond a reasonable doubt, and as a matter of fact the body is not likely to change that (unless there's some overwhelming evidence that e.g. she died of natural causes). The DA is simply contemplating reducing the sentence (effectively, by reducing the charges) in return for Reiser cooperating (by giving them the body, which they'd really like). They don't need the body to prove things one way or the other, they just want to find it (to give the family closure and so on) and are willing to cut deals to get it.
And what if, after examining the body, evidence is found that death could have had a natural cause, or be a suicide? With that reasonable doubt, would the conviction be reversed?
Depending on the circumstances, new evidence could be considered. (Actually, I think that if he knew where the body was the whole time, he might not be permitted to present the new evidence because it was his fault for not disclosing the location at the original trial. Not sure how that would turn out). If he were permitted to present the evidence on appeal, and the court found it established a reasonable doubt, he would be acquitted.
It's an interesting question, to be sure. In the drunk driving checkpoint case I mentioned, the court upheld the checkpoint because there was another way around; drivers could simply take different roads. Of course that would increase travel time somewhat, but it did not fundamentally remove the ability to drive from point A to point B. Here the government checkpoints cover all substantially similar routes (i.e. air travel), so perhaps the court would consider this a different situation.
Regarding the first question: what if your job required you to go to a government building where you go through a similar search? What if your job requires you to obtain a security clearance and submit to a poly and background check? Private jobs can require all sorts of things—the government isn't per se forcing you to submit to the search. I see your point, but I don't think it really holds up here (in particular because air travel is not mandatory for rather a lot of jobs).
That a government agency is performing the search doesn't change the fact that you are submitting to it. http://yro.slashdot.org/comments.pl?sid=576821&cid=23693651
They don't need a warrant if you submit. This is a basic premise of 4th amendment case law; if the goverment asks if they can search you or your property, and you say yes, that's all they need. Works for personal searches, houses, cars (this argument was used to defend certain kinds of drunk driving checkpoints because people were free to drive around them). You are not compelled to enter the secure area and board a plane; the TSA will not detain you if you walk away from the airport and go home. You are submitting willingly to a goverment search so your rights are not violated.
Yes. Given the quality of slashdot editors, I'm betting the spell checker would beat them up first and make them beg for it.
I think you have a misconception about the locking problem we're discussing. Understand that the BKL issue has nothing to do with userland or application programmers; it is a lock used internally in the kernel, and is only visible or relevant to kernel code.
By "real systems", I had real kernels in mind in particular. I'm not a kernel expert (certainly not a Linux kernel expert), but I have written a [small, toy, but functional] UNIX-y flavor kernel for class, so I can claim to know what I'm talking about generally.
Realize that "internal kernel structures" reaches basically everything living anywhere in memory. Realize also that modern operating systems are horifically concurrent. Lots of things are happening at once, and at any moment, someone can (and probably will) pull the rug out from under you. Concurrency is far uglier than in user land—even if a thread in a seperate process totally unrelated to the current thread starts to run, you still have to context switch, and that's still messy.
If you are reading data from hardware (or writing to hardware) you may need to lock things in memory.
If you believe in supporting mulitple threads/processes/runnables in the same memory space, locking the VM can be hilarious.
You certainly need some sort of data structure for understanding the memory layout across processes, which requires locking (god forbid you accidentally give out the same physical frame for two different things, or the same spot on disk, or whatever).
Filesytems live in the kernel, and certainly entail locking (and may combine kernel structures and hardware when you do disk I/O).
Big issue: Even though you don't want to spend much time in the kernel total, you have to go through kernel a lot (every time you take an interrupt). The scheduler should be fast, so shouldn't hold on to resources very long, but it has to run an awful bloody lot, and it certainly brings in locking issues. Any operations which would affect your runqueue (or whatever datastructure keeps track of your runnables) is thus complicated by locking. (This means yield, this means exit, etc). Also, exiting and waiting/jointing/etc., whether for threads or processes, brings their own forms of locking pain. And please don't even thinking about killing a multi-threaded process! (But, of course, you really want to be able to do that).
In sum, the locking issues in a kernel are exceedingly complicated and do not easily produce nice conditions.
See comment above http://tech.slashdot.org/comments.pl?sid=556184&cid=23448010
This is one approach to deadlocks; it would fall generally under "avoidance".
The problem is that if you have any serious contention over the resources, it is entirely possible that the process will _never_ get the resources (because one of them always gets snatched up before another gets released, so all n resources are never available at once to the requesting process). This leads to starvation and general sadness.
If the system has minimal contention (so the normal case is that all three resources are unclaimed) and resources are held very briefly (so if a resource is taken it is likely to be released before another is taken, anyway) then it may work. In real systems these are hard properties to guarantee.
Also, the scheme requires a process to know in advance which locks it will need. A lot of algorithms may discover this on the fly (e.g. if you are traversing a data structure), which becomes a problem. The best you could hope to do is to lock aggressively--taking everything you might need--but this is ugly, and would tend to violate the conditions above (locking everything will lead to contention, locking everything in advance will lead to holding locks for a long time). Alternatively, if you discover that you need a new lock that you don't yet have, you could give up all the locks you do have and then try to lock again (with the new lock added to the set). This is also ugly and increases the chance of starvation (since now you need to lock a bunch of resources several times). Additionally, since you have to unlock in the middle, the algorithm becomes much more complicated. For example, when you discover you need a new lock, you must put the world in a consistent state before unlocking. And when you re-lock, you must check to make sure that the world hasn't been modified under your feet (which is entirely possible, and may very well cause you to need a still-different lock).
Basically it doesn't work that well.Glancing at the schema, it's clear that the database, while highly interesting from a structural point of view, doesn't actually contain any of the code or anything like that. I'll bet he was smart enough to get it ok'd and I'll bet Microsoft was fine with it (after all, the paper does conclude that windows is comparable to the open source kernels)
In my experience (at CMU) that doesn't happen. A lot of people don't buy books because they just aren't necessary (you can get the problems from friends and a lot of times lecture notes + internet are good enough). However, when people actually do need books, they usually buy them. Most people get used copies from the bookstore, upperclassmen, or the internet, though.
As a graduating CMU SCS student, I'll point out that the bit about lots of job opportunities still holds. Recruiters make jokes about secret railroads connecting CMU and [major tech company] campuses. To some extent the highly competitive/demanding environment may hurt (in that you might get a lower GPA at the tougher school) but mostly that comes out in the wash. Being at one of the well respected schools is a huge plus in the job hunt, and I suspect it really does help you get a better grasph of CS. There are good reasons for going to a liberal arts school, though. Although it's possible to take non-technical classes, it's not as good an opportunity. There's a fair amount of time (at least if you choose to minor in a non-technical field), but frankly a lot of the classes just aren't that good (CMU just can't compare to a good Lib Arts school in a lot fields) and so you may not get much out of it. I would say it comes down to how your interests are divided. Both a good technical school and a good liberal arts are capable of giving you an education that is resonably strong in CS and also reasonably well rounded. If you have strong interests in the non-technical fields, you will probably be disappointed in the tech school, but if you don't, you will probably be disappointed in the libarts school.
Google is to blame for not establishing some type of protocol to guard against this (pretty much inevitable) privacy invasion.