> Seems to me putting a lawyer in a position where s/he can make laws is a conflict of interest.
Setting precedent with this sort of case is a once-in-a-lifetime dream for many lawyers. And "precedent" is a critical part of modern court proceedings: so it's critical.
> Perl. Perl all the way through, and nothing but Perl.
Python has been suffering from module dependencies lately, where the "pip install" tool for installing 3rd-party modules deploys a rats' nest of potentially incompatible latest releases of all the dependencies from python.pi.org. This is similar to what happened with CPAN over time, except that CPAN for perl was much, much worse about individual modules introducing incompatible upgrades, and other modules being long unmaintained so they would never be upgraded for compatibility. I'm afraid I encountered this at least once a year for 10 years after the "mod_perl" update debacle.
> A real programmer does not care about languages.
A real programmer certainly _does_ care. The available modules, version dependencies, and API's can vary tremendously. Even simple features like "regexp" have subtly different syntax with different tools, string parsing and processing functions differ fundamentally in the handling of "end-of-line" characters, and even whether a "true" value is "0" or a positive number can differ profoundly and affect binary logic.
To say "a real programmer does not care" is similar to saying that a real musician does not care what instrument they play.
They were paying tuition for their _classes_. The internships were not part of their course work, and they did not receive grades. It was still very helpful on their transcripts, and good experience in the field.
> If the co-op was done for free, it's exploitative.
Not necessarily. I've worked with unpaid interns whose job prospects and contacts in the field were vastly enhanced by direct experience. The interns were _in addition_ to their schoolwork, so benefits to the school were indirect: they weren't collecting tuition for the kids' work with us.
> Instead, I sleep in on BF, wake up later in the day and check Craigslist, where the thugs are selling their bounty. I
Unwelcome or duplicate presents are why I'll check the "refurbished" or "opened" sales items at my local electronics store, a few weeks after Christmas. I've gotten some very nice personal electronics that way, including laptops and high end video cards.
Computer "cracking" can only occasionally be traced this way, when the crack is specific. There are _so many_ potential sources of this crack that it's not likely to be fruitful. They range from competent, targeted attacks on that specific vendor's products to gain advance knowledge of specific police departments, to NSA or other international intelligence agency style, to "Anonymous" or the older "Legion of Doom" style crackers counting coup on police security systems, to drug dealers with a gifted member or able to pay a competent cracker to plant ubiquitous monitoring on their local police department this way.
There are too many potential candidates to isolate any of them.
> Defending against these attacks is not the responsibility of the participants in this exercise,
I agree. The rules test certain types of defined attack vectors. But the concept that "No. An actual enemy would not jam your WiFi because they would not be on your local network" is not a well founded one, and it's what I meant to object to. Many attackers can, and will, gain access to your local network. Many successful or partially successful attackers can, and will brag about or exchange details on exactly how to enter your local network once it's penetrated, so it's very, very poor security policy to say claim an attacker would never be on your local network. And "attackers on your local network" was exactly what the exercise was designed to test.
> To find a rootkitted laptop, you would walk around disabling wifi on each laptop until you found the offender.
You first have to be able to detect whether it is, or is not, misbehaving on your network to be able to tell when it's turned off. If you can do that, you can probably already identify its MAC address and tie it to a particular access point. That's useful if you have such control, but most security attacks involving local network access are less blatant and detectable. Those kinds of attack seem to be what these "capture the flag" exercises involve.
> No. An actual enemy would not jam your WiFi because they would not be on your local network
Except when they've rootkitted a laptop near you, or used an antenna or a locally planted repeater to access your network from slightly offsite, or planted a wifi gateway inside your network. This is the difficulty of setting up defenses based what you think an "actual enemy" would do, rather than based on what real attackers do. Real attackers use the cheaper, simpler attack methods because they work, but they also try sophisticated techniques when simple methods _don't_ work or even because they happen to have them available.
> You can't determine their strategy with insults.
"Terrorism", meaning intimidation of the civilian population through unpredictable attacks against people not directly involved in the conflict, is a useful description of the strategy. It can also be very effective: look at the history of Ireland, or of the resistance fighters in Poland during World War II.
From personal and professional experience, I'd suggest that you treat Windows 8 much like the market treated WinME, and simply jump straight to Windows 10. It does have issues, but it's avoided the user interface errors that Windows 8 insisted on, and it's much better supported than Windows 8 is now.
> Well, that'd be the case if there was a great deal of skill involved, r
Skill at outright cheating at the computer level by sculpting the payouts in your personal favor, or skill at getting insider information and getting players to throw games with the right coercion, like more traditional sports betting. I'm afraid I've been watching the resurgence of sports betting by taking this particular form.
The large vulnerability is not in the encryption of the stored fingerprint information. It's in the very poor tools for measuring and reporting valid fingerprints, which allow matching with even vaguely similar fingerprint images. The original infamous study on the problem is at http://web.mit.edu/6.857/OldSt..., and there was even a MythBusters episode demonstrating the essential vulnerability of the system to casually sampled, stored, and replicated fingerprints at https://www.youtube.com/watch?... .
It was especially impressive that Mythbusters used a printed copy of a fingerprint, licked it, put it on the commercial biometric scanner, and were able to defeat the security scanner. These devices are security theater at its worst.
Excuse me? What field are you in where "working doing products" mean working in IT? I've never seen that usage for IT work in decades in the field. The more I think about it, the less it's clear what it _does_ mean. I can find no evidence that it's a standard term of art in manufacturing, software, or sales.
"Doing products" does not typically mean "work in IT". If your current workplace is using the words that way, then please be more clear about language: they're not the standard definitions.
> The client isn't a client of the open source developer though.
Quite true. But note what I was responding to, from a previous poster:
>> I've never had a team come to me and say "we need this bug fixed in the next day or two".
It's a common request for me and my colleagues. It's especially intense when finely scheduled Gant charts of billable time, with specific hours with specific tasks, are written with "2 hours to fix ticket CORP-999" allocated early in the project, work is blocked by it, but the work can't be started until 3 hours before the manager who reported the bug knows nothing about it, and the programmer can't be spared to describe the bug. That was a quite common occurrence with one manager until they were helped to find a new role with another company.
> Big difference between "We need to resolve this issue now" and "We need that third party developer with whom we have no commercial relationship to fix a bug now".
The client may not know, and often does not care. It's unusual, but not that unusual, for the client to complain bitterly about any delay, even for an unpaid third party source code repository.
> Big difference between "We need to resolve this issue now" and "We need that third party developer with whom we have no commercial relationship to fix a bug now".
Good for you and for the rest of us. I'm afraid I also find some that are old bugs for which I've submitted patches or workarounds previously. Most of the free software and open source authors are good about reviewing and accepting small, legible patches in a timely fashion, and the growth of git for open code and alternative software repositories has been very useful. I've been delighted with its effects on the ability to patch code, and submit pull requests, without having to share write access to the primary source repository.
> I've never had a team come to me and say "we need this bug fixed in the next day or two".
Then you clearly don't work in IT. Problems with system capacity, critical hardware, authenticated access, and network connectivity all need to be fixed _now_. And not having the resources in place to deal with the shortages leads to people losing their jobs, and can cause the whole company to fail.
For older, more fragile paper, such as non-acid-free paper that's been sitting out in sunlight at all, or well-thumbed technical manuals, the paper feed will shred them.
I must admit that I'm also not thoroughly convinced about the amounts of matter they need to find. The cosmology of the expanding universe is _extremely_ vulnerable to small measurement errors. Even numbers like the Hubble Constant are still being refined, and the gravitational analyses and behavioral analyses of galaxies billions of years old and billions of lightyears distant is vulnerable to many distortions and misanalyses. There comes a point in the deduction of extraordinary solutions, such as the speculative forms of "dark matter", that you need to pause, apply Occam's Razor, and ask "Did I measure this right in the first place? Or is my instrument mistuned?".
> Okay, while it's theoretically possible to configure a home server to be less secure than a "cloud" solution you would almost have to go out of your way to do so.
Or just think you're smarter than the folks doing real security. I can no longer count the number of "professionals" with passphrase free SSH keys on accessable network drives, or who insist on putting passphrase free SSH keys with root access on all their servers "so they can do backups". Couple this with people who run private tunnels to, and from their laptops into the internal network and you have a quite common and quite disturbing security problem.
Slashdot Mirror
> Seems to me putting a lawyer in a position where s/he can make laws is a conflict of interest.
Setting precedent with this sort of case is a once-in-a-lifetime dream for many lawyers. And "precedent" is a critical part of modern court proceedings: so it's critical.
> Perl. Perl all the way through, and nothing but Perl.
Python has been suffering from module dependencies lately, where the "pip install" tool for installing 3rd-party modules deploys a rats' nest of potentially incompatible latest releases of all the dependencies from python.pi.org. This is similar to what happened with CPAN over time, except that CPAN for perl was much, much worse about individual modules introducing incompatible upgrades, and other modules being long unmaintained so they would never be upgraded for compatibility. I'm afraid I encountered this at least once a year for 10 years after the "mod_perl" update debacle.
> A real programmer does not care about languages.
A real programmer certainly _does_ care. The available modules, version dependencies, and API's can vary tremendously. Even simple features like "regexp" have subtly different syntax with different tools, string parsing and processing functions differ fundamentally in the handling of "end-of-line" characters, and even whether a "true" value is "0" or a positive number can differ profoundly and affect binary logic.
To say "a real programmer does not care" is similar to saying that a real musician does not care what instrument they play.
The link you mentioned does list some cases. The interns I worked with were _not_ abused this way.
They were paying tuition for their _classes_. The internships were not part of their course work, and they did not receive grades. It was still very helpful on their transcripts, and good experience in the field.
> If the co-op was done for free, it's exploitative.
Not necessarily. I've worked with unpaid interns whose job prospects and contacts in the field were vastly enhanced by direct experience. The interns were _in addition_ to their schoolwork, so benefits to the school were indirect: they weren't collecting tuition for the kids' work with us.
> What sort of entry level employer ever gave a shit where you went to high school?
The same employers who care about your last 3 employers. It provides a chance to check references, and make sure you weren't expelled with cause.
> Instead, I sleep in on BF, wake up later in the day and check Craigslist, where the thugs are selling their bounty. I
Unwelcome or duplicate presents are why I'll check the "refurbished" or "opened" sales items at my local electronics store, a few weeks after Christmas. I've gotten some very nice personal electronics that way, including laptops and high end video cards.
> but who benefits from a hack on body cameras?
Computer "cracking" can only occasionally be traced this way, when the crack is specific. There are _so many_ potential sources of this crack that it's not likely to be fruitful. They range from competent, targeted attacks on that specific vendor's products to gain advance knowledge of specific police departments, to NSA or other international intelligence agency style, to "Anonymous" or the older "Legion of Doom" style crackers counting coup on police security systems, to drug dealers with a gifted member or able to pay a competent cracker to plant ubiquitous monitoring on their local police department this way.
There are too many potential candidates to isolate any of them.
> Defending against these attacks is not the responsibility of the participants in this exercise,
I agree. The rules test certain types of defined attack vectors. But the concept that "No. An actual enemy would not jam your WiFi because they would not be on your local network" is not a well founded one, and it's what I meant to object to. Many attackers can, and will, gain access to your local network. Many successful or partially successful attackers can, and will brag about or exchange details on exactly how to enter your local network once it's penetrated, so it's very, very poor security policy to say claim an attacker would never be on your local network. And "attackers on your local network" was exactly what the exercise was designed to test.
> To find a rootkitted laptop, you would walk around disabling wifi on each laptop until you found the offender.
You first have to be able to detect whether it is, or is not, misbehaving on your network to be able to tell when it's turned off. If you can do that, you can probably already identify its MAC address and tie it to a particular access point. That's useful if you have such control, but most security attacks involving local network access are less blatant and detectable. Those kinds of attack seem to be what these "capture the flag" exercises involve.
> No. An actual enemy would not jam your WiFi because they would not be on your local network
Except when they've rootkitted a laptop near you, or used an antenna or a locally planted repeater to access your network from slightly offsite, or planted a wifi gateway inside your network. This is the difficulty of setting up defenses based what you think an "actual enemy" would do, rather than based on what real attackers do. Real attackers use the cheaper, simpler attack methods because they work, but they also try sophisticated techniques when simple methods _don't_ work or even because they happen to have them available.
> You can't determine their strategy with insults.
"Terrorism", meaning intimidation of the civilian population through unpredictable attacks against people not directly involved in the conflict, is a useful description of the strategy. It can also be very effective: look at the history of Ireland, or of the resistance fighters in Poland during World War II.
It's very nice to see such a relevant post.
From personal and professional experience, I'd suggest that you treat Windows 8 much like the market treated WinME, and simply jump straight to Windows 10. It does have issues, but it's avoided the user interface errors that Windows 8 insisted on, and it's much better supported than Windows 8 is now.
> If the DNA information is just collected and stored anonymously, with no record of WHOSE DNA it is,
In which case it would be useless for most of the most valuable and, yes, profitable research and would not be funded.
Unlike, say, insulin?
> http://heritage.utoronto.ca/in...
The patent was apparently first patented in England and Ireland in 1922, though the original research was done in Canadaa.
> Well, that'd be the case if there was a great deal of skill involved, r
Skill at outright cheating at the computer level by sculpting the payouts in your personal favor, or skill at getting insider information and getting players to throw games with the right coercion, like more traditional sports betting. I'm afraid I've been watching the resurgence of sports betting by taking this particular form.
The large vulnerability is not in the encryption of the stored fingerprint information. It's in the very poor tools for measuring and reporting valid fingerprints, which allow matching with even vaguely similar fingerprint images. The original infamous study on the problem is at http://web.mit.edu/6.857/OldSt..., and there was even a MythBusters episode demonstrating the essential vulnerability of the system to casually sampled, stored, and replicated fingerprints at https://www.youtube.com/watch?... .
It was especially impressive that Mythbusters used a printed copy of a fingerprint, licked it, put it on the commercial biometric scanner, and were able to defeat the security scanner. These devices are security theater at its worst.
Excuse me? What field are you in where "working doing products" mean working in IT? I've never seen that usage for IT work in decades in the field. The more I think about it, the less it's clear what it _does_ mean. I can find no evidence that it's a standard term of art in manufacturing, software, or sales.
"Doing products" does not typically mean "work in IT". If your current workplace is using the words that way, then please be more clear about language: they're not the standard definitions.
> The client isn't a client of the open source developer though.
Quite true. But note what I was responding to, from a previous poster:
>> I've never had a team come to me and say "we need this bug fixed in the next day or two".
It's a common request for me and my colleagues. It's especially intense when finely scheduled Gant charts of billable time, with specific hours with specific tasks, are written with "2 hours to fix ticket CORP-999" allocated early in the project, work is blocked by it, but the work can't be started until 3 hours before the manager who reported the bug knows nothing about it, and the programmer can't be spared to describe the bug. That was a quite common occurrence with one manager until they were helped to find a new role with another company.
> Big difference between "We need to resolve this issue now" and "We need that third party developer with whom we have no commercial relationship to fix a bug now".
The client may not know, and often does not care. It's unusual, but not that unusual, for the client to complain bitterly about any delay, even for an unpaid third party source code repository.
> Big difference between "We need to resolve this issue now" and "We need that third party developer with whom we have no commercial relationship to fix a bug now".
Good for you and for the rest of us. I'm afraid I also find some that are old bugs for which I've submitted patches or workarounds previously. Most of the free software and open source authors are good about reviewing and accepting small, legible patches in a timely fashion, and the growth of git for open code and alternative software repositories has been very useful. I've been delighted with its effects on the ability to patch code, and submit pull requests, without having to share write access to the primary source repository.
> I've never had a team come to me and say "we need this bug fixed in the next day or two".
Then you clearly don't work in IT. Problems with system capacity, critical hardware, authenticated access, and network connectivity all need to be fixed _now_. And not having the resources in place to deal with the shortages leads to people losing their jobs, and can cause the whole company to fail.
For older, more fragile paper, such as non-acid-free paper that's been sitting out in sunlight at all, or well-thumbed technical manuals, the paper feed will shred them.
> MACHO didn't find anything like enough matter
I must admit that I'm also not thoroughly convinced about the amounts of matter they need to find. The cosmology of the expanding universe is _extremely_ vulnerable to small measurement errors. Even numbers like the Hubble Constant are still being refined, and the gravitational analyses and behavioral analyses of galaxies billions of years old and billions of lightyears distant is vulnerable to many distortions and misanalyses. There comes a point in the deduction of extraordinary solutions, such as the speculative forms of "dark matter", that you need to pause, apply Occam's Razor, and ask "Did I measure this right in the first place? Or is my instrument mistuned?".
> Okay, while it's theoretically possible to configure a home server to be less secure than a "cloud" solution you would almost have to go out of your way to do so.
Or just think you're smarter than the folks doing real security. I can no longer count the number of "professionals" with passphrase free SSH keys on accessable network drives, or who insist on putting passphrase free SSH keys with root access on all their servers "so they can do backups". Couple this with people who run private tunnels to, and from their laptops into the internal network and you have a quite common and quite disturbing security problem.