When I create something while on the job, my employer owns all rights to it. If I decide to email it to my brother-in-law because I think he might learn something from it, my employer would be perfectly within their rights to fire me. This is all made extremely clear in a short, easy-to-read employee manual. Apparently, the police in this instance are not subject to such a simple control. They should be. They took the taxpayers' property and used it for their private ends. Totally unacceptable.
Clearly, we as a society do not want to prohibit distribution of photos simply on the basis that they make some people extremely uncomfortable, and I would not have a problem with a passer-by who happened to take a photo of the accident scene selling it. The victim here, even if she were to have survived, clearly had no expectation of privacy since the accident was in a public place.
If I was as rich as the parents in this seem to be, I'd remember that revenge is a dish best served cold, and would not make any more of a public fuss about this. There will be plenty of time to devise a perfectly legal and appropriately devastating response to this, should they decide those responsible need to be reminded of what they have done.
Nevada's legal definition of encryption sucks, and covers just about any technology that obstructs a bad guy's access to data. That includes such cryptographic wonders as, say, passwords or 2-factor auth.
The weaknesses of this law have been pointed out repeatedly -- for example by Schneier in a crypto-gram from probably 2004 (this is from memory), and by various bloggers interested in data breach legislation.
I am sure MA could not do a worse job, but Nevada did an absolutely terrible one.
If you have made an original contribution, and your software merely demonstrates or implements that contribution, then your advisor is acting in an anti-collegial manner by demanding citation.
Clearly, anyone extending your results would be foolish indeed not to cite your paper (and there's already a fine reputation-based system for enforcing this social norm, thank you very much), but it sounds as though your advisor is looking to pad the number of citations he has.
Whether your username was 'aaaaa' or 'zzzzzz' is irrelevant.
You are saying that your password either fell to a dictionary attack or was brute-forced. The odds of the latter succeeding are extremely small when the bad guy cannot do an off-line attack.
If your password lost to an on-line dictionary attack, then you had a really shitty password and should own up to it rather than whining like a baby.
That said, if you were new to the trade, I'd have considered it an object lesson and given you a lecture. If you were an experienced admin who should have known better, I'd have told you it was two strikes and next one you're gone.
From your tone, it seems like you learned nothing from this episode, but instead have taken it to be a reinforcement that "management types" are willing to lie to customers in order to maintain the illusion that data is 100% safe. I think this shows the typical techie dismissive attitude toward both "suits" and "lusers", neither of whom really "gets it".
Let me offer an alternative view -- the customers don't even think about security -- that's YOUR job. They figure a company that is a card processor will understand their trade, and will deploy the appropriate mix of technology and human processes to maintain a reasonably safe environment. Just like they expect a builder to make a decent house, but not one they expect to survive 180MPH winds. One of those reasonable processes is not allowing users to pick dumb-ass passwords. This is a friggin' obvious rule to any sysadmin, and ssh makes it easy to not have to rely on passwords in the first place!
My take on this is that you don't see how you could have done anything better here. You're wrong. They may also have been wrong to can your ass, but there are plenty of things you could have done:
1. Use a passwd program that won't allow dumbass passwords to be picked.
2. Don't use password auth with ssh to begin with.
3. Limit hosts allowed to connect to your unimportant box.
4. Architect your network so that you can monitor from inside the perimeter.
5. Have your ISP(s) set up a monitoring mechanism -- you know that their techies have MRTG running:^).
Now maybe only some of these are in your control (and there are probably 10 more I could think of), but please recognize your role in this. Picking a bad password is something Dilbert's PHB does. It should not be something a sysadmin does.
The final rules require each financial institution and creditor that holds any consumer account, or other account for which there is a reasonably foreseeable risk of identity theft
to do these things. If you sell something to someone for cash, you are not a creditor. If you were a financial institution, and thus covered by GLBA, you'd know it already. Unless you extend credit, you're not a creditor.
Not much to see here, and the fact that this article had its origin in somebody selling a service to help you comply with this may be meaningful.
This system could have been designed not to store travel data, or to store it only for a short time (enough to, say, calculate a reduced fare based on number of segments recently-travelled, etc). The surest way to prevent MI5 from gaining access to these records is to not create the records in the first place.
An identical observation applies to the privacy-destroying US "EZPass" system for highway tolls, of course. Sigh.
Here are some possible situations for you to consider.
1. The file-sharing SW was loaded by someone else (such as a child of the defendant's). 2. The defendant intended to share only those files which he was permitted to, but misconfigured his filesharing software?
Finally, consider this. If intending to share files illegally and actually doing so are so close to being the same thing, let THE LEGISLATURE do something about it by reflecting this reality in law. Under the Constitution, that's what they are there for.
The article touts Barford, but it looks as though this is one example of similar work that various researchers have been pursuing for years. Folks at CAIDA, Arbor, and Team Cymru have been talking about darknet design, construction, and use for a long time. This project seems to fit into that space quite nicely, but TFA is a damn press release, so naturally it is useless and devoid of context.
A waiting man would need two hands, or at least a heartbeat, to understand what sort of red trio of indiscipline could allow such elephant talk. One time, EMI were walking on air, but now they can only get their easy money from this slaughter of the innocents. Peace -- A theme ladies of the road to Asbury Park might tell as a Sailor's Tale to this moonchild -- will now have its cadence and cascade replaced by B'boom. THRAK!
Naturally, I haven't RTFA, but what is this research Bruce conducted? He's pretty well-read in subjects outside his formal training and bearing upon infosec (such as economics, cogsci, experimental psychology), but other than crypto, I am unaware of any original research he's conducted.
Note: I do not consider reading papers produced by Ross Anderson and his students to be "research".
I may be wrong, but from the descriptions it sounds as though Comcast is simply forging TCP RST packets. From the articles, it seems as though the traffic type (at least in the Lotus Notes case) is determined solely by destination port. If this is the case, application-level encryption would not be an effective countermeasure.
"People talk on the phone about the most private and illegal things"
Yeah, I've heard that people will even be so crazy as admit to committing felonies, like listening in on others' phone conversations. Can you believe it??
494 out of 5,000 responded. I wonder if the 9% who did are at all unlike the 91% who did not? Could it be, ya think??
It's called non-response bias.
They admit right up front that the results (even if there were no non-response bias) don't generalize to IT in general, since their members are not drawn from IT in general.
Because that row just became $10 less valuable to the credit bureaus if they have to actually do any work to unlock it before selling access to it. As a matter of law, they OWN that info, so naturally they are going to object to anything that interferes with their right to use their own property. So would you.
Whether they *should* have a property right in personal financial information about others is an entirely separate question. My answer is "no";^).
Slashdot Mirror
When I create something while on the job, my employer owns all rights to it. If I decide to email it to my brother-in-law because I think he might learn something from it, my employer would be perfectly within their rights to fire me. This is all made extremely clear in a short, easy-to-read employee manual. Apparently, the police in this instance are not subject to such a simple control. They should be. They took the taxpayers' property and used it for their private ends. Totally unacceptable.
Clearly, we as a society do not want to prohibit distribution of photos simply on the basis that they make some people extremely uncomfortable, and I would not have a problem with a passer-by who happened to take a photo of the accident scene selling it. The victim here, even if she were to have survived, clearly had no expectation of privacy since the accident was in a public place.
If I was as rich as the parents in this seem to be, I'd remember that revenge is a dish best served cold, and would not make any more of a public fuss about this. There will be plenty of time to devise a perfectly legal and appropriately devastating response to this, should they decide those responsible need to be reminded of what they have done.
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
I have T-Shirts older than this punk.
At least when Bill Joy tells Dennis Ritchie that C is bad, he has some street cred. I think Payne needs to pay some dues before lecturing the planet.
Nevada's legal definition of encryption sucks, and covers just about any technology that obstructs a bad guy's access to data. That includes such cryptographic wonders as, say, passwords or 2-factor auth.
The weaknesses of this law have been pointed out repeatedly -- for example by Schneier in a crypto-gram from probably 2004 (this is from memory), and by various bloggers interested in data breach legislation.
I am sure MA could not do a worse job, but Nevada did an absolutely terrible one.
If you have made an original contribution, and your software merely demonstrates or implements that contribution, then your advisor is acting in an anti-collegial manner by demanding citation.
Clearly, anyone extending your results would be foolish indeed not to cite your paper (and there's already a fine reputation-based system for enforcing this social norm, thank you very much), but it sounds as though your advisor is looking to pad the number of citations he has.
Tell us, does your advisor have tenure?
Whether your username was 'aaaaa' or 'zzzzzz' is irrelevant.
You are saying that your password either fell to a dictionary attack or was brute-forced. The odds of the latter succeeding are extremely small when the bad guy cannot do an off-line attack.
If your password lost to an on-line dictionary attack, then you had a really shitty password and should own up to it rather than whining like a baby.
That said, if you were new to the trade, I'd have considered it an object lesson and given you a lecture. If you were an experienced admin who should have known better, I'd have told you it was two strikes and next one you're gone.
From your tone, it seems like you learned nothing from this episode, but instead have taken it to be a reinforcement that "management types" are willing to lie to customers in order to maintain the illusion that data is 100% safe. I think this shows the typical techie dismissive attitude toward both "suits" and "lusers", neither of whom really "gets it".
Let me offer an alternative view -- the customers don't even think about security -- that's YOUR job. They figure a company that is a card processor will understand their trade, and will deploy the appropriate mix of technology and human processes to maintain a reasonably safe environment. Just like they expect a builder to make a decent house, but not one they expect to survive 180MPH winds. One of those reasonable processes is not allowing users to pick dumb-ass passwords. This is a friggin' obvious rule to any sysadmin, and ssh makes it easy to not have to rely on passwords in the first place!
My take on this is that you don't see how you could have done anything better here. You're wrong. They may also have been wrong to can your ass, but there are plenty of things you could have done:
1. Use a passwd program that won't allow dumbass passwords to be picked.
2. Don't use password auth with ssh to begin with.
3. Limit hosts allowed to connect to your unimportant box.
4. Architect your network so that you can monitor from inside the perimeter.
5. Have your ISP(s) set up a monitoring mechanism -- you know that their techies have MRTG running :^).
Now maybe only some of these are in your control (and there are probably 10 more I could think of), but please recognize your role in this. Picking a bad password is something Dilbert's PHB does. It should not be something a sysadmin does.
I read this book when Simson Garfinkel wrote it eight years ago, as Database Nation
Tell HR to ask Legal.
If you do not already know the answer, you are the wrong person to turn to.
This answer is not meant to be disparaging.
This system could have been designed not to store travel data, or to store it only for a short time (enough to, say, calculate a reduced fare based on number of segments recently-travelled, etc). The surest way to prevent MI5 from gaining access to these records is to not create the records in the first place.
An identical observation applies to the privacy-destroying US "EZPass" system for highway tolls, of course. Sigh.
Here are some possible situations for you to consider.
1. The file-sharing SW was loaded by someone else (such as a child of the defendant's).
2. The defendant intended to share only those files which he was permitted to, but misconfigured his filesharing software?
Finally, consider this. If intending to share files illegally and actually doing so are so close to being the same thing, let THE LEGISLATURE do something about it by reflecting this reality in law. Under the Constitution, that's what they are there for.
THANK YOU! It's math, people. You don't get to change the rules if the result is not to your liking.
:^))
(Personally, I'd prefer that the non-dictatorship requirement be relaxed. For a suitable definition of dictator, naturally
The article touts Barford, but it looks as though this is one example of similar work that various researchers have been pursuing for years. Folks at CAIDA, Arbor, and Team Cymru have been talking about darknet design, construction, and use for a long time. This project seems to fit into that space quite nicely, but TFA is a damn press release, so naturally it is useless and devoid of context.
A waiting man would need two hands, or at least a heartbeat, to understand what sort of red trio of indiscipline could allow such elephant talk. One time, EMI were walking on air, but now they can only get their easy money from this slaughter of the innocents. Peace -- A theme ladies of the road to Asbury Park might tell as a Sailor's Tale to this moonchild -- will now have its cadence and cascade replaced by B'boom. THRAK!
Naturally, I haven't RTFA, but what is this research Bruce conducted? He's pretty well-read in subjects outside his formal training and bearing upon infosec (such as economics, cogsci, experimental psychology), but other than crypto, I am unaware of any original research he's conducted.
Note: I do not consider reading papers produced by Ross Anderson and his students to be "research".
I may be wrong, but from the descriptions it sounds as though Comcast is simply forging TCP RST packets. From the articles, it seems as though the traffic type (at least in the Lotus Notes case) is determined solely by destination port. If this is the case, application-level encryption would not be an effective countermeasure.
"People talk on the phone about the most private and illegal things"
Yeah, I've heard that people will even be so crazy as admit to committing felonies, like listening in on others' phone conversations. Can you believe it??
Libraries can count on the doctrine of first sale. At the current time, they have nothing to worry about.
What is the endianness of your filesystem? :^)
494 out of 5,000 responded. I wonder if the 9% who did are at all unlike the 91% who did not? Could it be, ya think??
It's called non-response bias.
They admit right up front that the results (even if there were no non-response bias) don't generalize to IT in general, since their members are not drawn from IT in general.
Yeah. I was bummed that the paper didn't discuss mixed strategy equilibria, too.
Because 'tortious' and 'tortuous' are different words.
Because that row just became $10 less valuable to the credit bureaus if they have to actually do any work to unlock it before selling access to it. As a matter of law, they OWN that info, so naturally they are going to object to anything that interferes with their right to use their own property. So would you.
;^).
Whether they *should* have a property right in personal financial information about others is an entirely separate question. My answer is "no"
He used some wicked-ass crypto to turn binary into Roman numerals, in 7337-speak. Don't be hatin!
THANK YOU!
(I thought I was the only one under whose skin that got)