No, this was someone who'd been caught, repeatedly, doing marginally illegel or marginally legal bulk downloads of paid websites. Aaron's abuse of the PACER resources should have correctly led prosecutors that he'd pulled this sort of thing before and would continue doing so without an actual conviction.
> I do not understand the rationale for universities and researchers more particularly wanting to have their research locked behind pay-walled services such as JSTOR
It's well indexed and cross referenced, reliably available, and has become the "one-stop" resource for research documents. That is _invaluable_ when looking for obscure documents or tying together research among multiple fields. JSTOR is getting paid, and not an outrageous amount, for that work. Some fool replicating their entire index and layout, as Aaron Swartz was clearly attempting, means that their income to continue the organization of the material dries up and will not be continued. And JSTOR subscriptions have been much more cost effective than Google searching or library searching for research documents.
It's the same reason newspapers or magazines put up paywalls: one has to pay the writers and editors, or in this case the indexers and the maintainers of the quite robust and effective back end. Good backups and failover facilities are not free, and JSTOR has been a reliable and invaluable resource. Aaron was threatening that by overwhelming and crashing the services. The documents are kept available much longer, and much more reliably, than a community driven or freeware service could hope to manage. JSTOR see themselves as librarians of knowledge, not as vendors of knowledge, and I applaud their efforts.
In his office at Harvard. He had legitimate JSTOR access there. The difficulty is that he needed _bandwidth_, and ideally to avoid detection on the routine network maps managed by IT staff, and to avoid the typical monitoring and proxy configurations found on most competently administered public wi-fi access points.
No, he was an asshole. The *scale and intensity* of his attempt to download and replicate *all* of JSTOR, including the indexing, was not only illegal in itself. Because of the amount of bandwidth he was using, he repeatedly crashed parts of JSTOR. That means that researchers and scholars woldwide lost access to a vital research tool. And as a response, and to protect the rest of the world's access, they finally had to cut off MIT's access. He was screwing with people doing medical research. People *die* because cutting edge research gets held back for bonehead reasons.
If Swartz had taken the single step of cutting the bandwidth he used by 75%, JSTOR wouldn't have kept crashing and had to punt MIT. And if he'd done it from his office at Harvard, *which had similar access to JSTOR*, there probably wouldn't have been a way to charge him, and it would be his employer's problem. Swartz was allowed on the MIT campus because of his Harvard ID, and his screw up has cast that whole reciprocal agreement between MIT and Harvard for library and campus access in doubt.
What Swartz did was not directly stealing from the authors of the research, it was making their research inaccessible while in progress. It screwed with the thesis writing of friends of mine, and interfered with research projects throughout MIT. Frankly, MIT should have been *much* more eager to help slap cuffs on this twit, but they're traditionally very, very slow to act against "cracking" because it's *embarrassing*, and the prosecutors inevitably fuck it up. Look into the David Lamacchia case about 10 years ago for an example
> These aren't tech support jobs they're design and engineering teams
That certainly does not mean they are employees, and not contractors. I've often helped train such contractors, and helped them get their development concerns verified by an outside agency so that they're taken more seriously and actually addressed rather than lost in the "not invented here" distaste from headquarters based teams in their own company.
May I say that we all miss Groklaw's insightful analysis, and very open access to, the core documents and analyses of these cases? If anyone on Slashdot knows PJ personally and can encourage her to accept the problem of email monitoring and return to her legal soapbox, she'd be welcomed. Groklaw's analyses of these cases, and PJ's careful attention to detail were welcome and instructive.
> Also it isn't entirely true that there isn't any authority available for ssh. You could make use of RFC 4255 or RFC 6187.
Neither were part of the original RFC specifications, and neither work in most production SSH clients. I'm afraid that I've not seen anyone actually use the DNS published signatures for SSH keys in the 8 years since RFC 4255 was published, and most clients have no capability for it. RFC 6187 seems to have been roundly rejected by the OpenSSH developers, who came up with their own signature technology that no other SSH client seems compatible with and is not easily backported to previous OpenSSH releases. And again, I've seen no corporate, educational, or private institutions even trying either technology.
I agree that it's problematic: secure handling of credentials is a very, very sore point in many IT organizations, and many groups ignore good practices because they "trust the people they work with" and "if they're on our network, we have much worse problems". Or they sign extensive security policies and then simply ignore them.
> There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks.
Nonsense. Ownership of the host private keys, stolen from the target SSH server, allows quite effective MITM: see http://www.gremwell.com/ssh-mi... and http://www.snailbook.com/docs/.... Moreover, there is no reliable ownership or timestamp on SSH private keys. And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler. And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.
This is, effectively, no different than enabling SSL keys without any signature whatsoever, which is the state of SSL in most environments because many private and public institutions do not bother to purchase signatures for their SSL keys.
And the "man in the middle" is often actually at one end, on the local router or on the local network switch, with simple packet snifing in place. It's not rare, it is _ubiquitous_ in many educational and corporate environments.
> What other extreme "+1 Interesting" edge cases can you think of for why all of the normal options just couldn't work?
Source code, or source code used to compile working version, is gone. That means a complete rebuild _of the source tree_, and with older projects a complete rebuild of the toolchain used to compile the source. This is often very, very expensive, but vital for software upgrades to run on modern operating systems.
Sir or madam, I am impressed at your swift pursuit and analysis of this issue. I wish far, far more engineers would actually _find_ the problem, rather than discuss the political implications. If you're involved in any major software or hardware projects, I would be delighted to see if my colleagues or I would have uses for them. And I hope your current workplace realizes the kind of engineer they have on their hands and are paying you enough.
> Jokes aside, I never understood why people live in KNOWN dangerous places.
Because it's only one factor. Farmers value the fertile land where floods deposit soil, and it's rarely feasible to live very far from the farm. Traders value the shipping made easier by river or ocean traffic near river heads, but those are likely flood areas. Damming and irrigation and dikes can actually _change_ the shape of the flood plain, making formerly safe areas profoundly more dangerous. Industries rely on the river water or hydro-electric power, and long commutes to work are a subtle tax on every worker's time every day.
Would you pay double the price of your current home, or apartment, to live in a safer place further from your work? Could you afford it?
It an also be difficult to measure.. The intensity of a mania can make one feel like one is very, very productive in many ways, but the productivity can be complete gibberish. This is visible professionally among coders who do binge programming sessions of exciting work that creates reams of exciting new ideas paradigms. But on review, the ideas are old, poorly implemented, and worse, entirely undocumented. This is followed by the attitude of "just read the code" and "it's so simple, it doesn't need testing".
Yes, I've seen work done by bi-polar colleagues before they were diagnosed or were off their meds. It may be less inventive, but it's far better quality code when they're medicated.
Because navigating byzantine bureaucracies is an invaluable work skill. I'm blessed with colleagues, and managers, who are very good at navigating these, and getting our technical personnel paid for the time burned in this arena. If you cannot navigate these pitfalls yourself, your managers will have to spend far more time doing it for you. They will also _own_ you, since you'll have no way to defend against decisions that eliminate your project or that take unearned credit for your work.
Thinking more for this anonymous reader: the combination of Java experience and VMware experience is intriguing. There are other virtualization technologies, and newer "container" technologies, that could benefit from streamlining and integration. Doing some open source development with tools like Tomcat or JBoss, and the "maven" or "ant" toolkits to build Java components, might provide good leads to workplaces that would benefit from your experience.
> My other advice is that Linux sysadmin (especially contract) pays more than dev.
My experience is that admins tend to make _less_ per hour than developers with the same amount of experience, but the work is much more stable. _Architects_ make more. Systems admins tend to be generalists. Showing a variety of skills, and being able to apply lessons from one to lessons in another environment are invaluable. So your VMware experience can be tied to systems integration work, monitoring, cloud computing deployment, software optimization, security, and resource planning.
Also, learn to cook. You say that your girlfriend is supporting you for a while? Then she deserves her dinner on the stove with clean plates and a cool drink when she comes home from work. It will save you both a lot of money on eating out, and it will keep you from spending all your time glued to a monitor reading Slashdot. At the interview, if you mention it, it also shows "this person cares about the people around them", especially if you can demonstrate it by arriving at a job interview with a plate of good home baked cookies or brownies. Applicants like that are _remembered_ by HR personnel and interviewers.
Again, that's applying technology, after the fact, to fix the _workflow_ problem that introduced mixed coding standards. Cleaning up the existing code base, especially for collaborative projects and groups that have distinct standards and refuse to follow each other's layout practices, makes this a very expensive proposition to enforce.
> Easy, they can still check out old files, revision history remains intact, everything is good in the world.
As soon as you do "svn blame" or "git blame" or extract "diff" outputs from revisions before and after the white space synchronization, you've a change tracking difficulty. I'm not saying this is impossible to do, I'm pointing out that it's expensive. It also _breaks_ many revision analysis tools.
> Like others have posted, the open source community is going to have to look at the released code very very carefully. The public has to assume that the NSA will include backdoors or obscure weaknesses if at all possible.
And look for licensing violations. Various "open source" license models allow modifying and republishing software without publishing your modifications. But if they inserted back doors into, for example, GPL licensed software without publishing the back doors, they'd be violating the software licenses.
> You won't find ANY military aircraft in ANY country on the planet that didn't have similar issues in its development, at least not since WWII.
Not this late in their development.
The F35 has directly competing design goals, ranging from their supersonic stealth capabilities to their short take-off/landing requirements, which is precisely _why_ the tires cost $1500 and wear out so quickly. The belief that throwing more billions of design to resolve what are fundamentally incompatible needs for power, speed, stealth, aircraft carrier landing, and three different military departments' military needs are what we who do contracting would call a "money trough". The competing design requirements ensure that no design will _ever_ work well enough and it will _always_ require expensive revamping of the entire architecture to serve the conflicting clients' needs.
Please read the contract. From work with email systems, I've often needed access to the mail queues in order to verify operation or delivery of email, and the relevant agreements have been very clear that I had the access to do so.
I've been asked to do monitoring on more than one occasion. I was once asked to to replicate all email for a particular user to a manager's mailbox, for a company I was collaborating with, while their core IT administrator was on another project. I carefully did the work, documented the procedures in their IT wiki, and notified the company's technical contact with us of the billable work and the completed documentation on the specific project. Since the targeted user was the technical contact with us, and the person who signed checks for my company's work, this fulfilled the letter of our agreements and let the target of the monitoring know what was going on and how to detect it in the future.
The technical contact was in the process of leaving the company: this let them know that they were also getting their corporate email monitored and they should be _very_ cautious about what they said to current contacts. We had some fascinating discussions in private about their reasons for leaving.
Do read the rental agreement. Many in the US,and overseas, do include clauses to address precisely this sort of thing, and a clearly written contract can help prevent many confusing "edge" cases.
Yes, what you've mentioned is true. But it does not address a single one of the problems _I_ had mentioned, which have to do with workflow and different coding standards from different groups, "Disallowing tabs" can be a reasonable internal coding policy, but the migration to it is likely to be filled with pitfalls, especially if any of your group's code involves older projects or third party code that has to be kept in sync and patch compatible with outside code.
Slashdot Mirror
No, this was someone who'd been caught, repeatedly, doing marginally illegel or marginally legal bulk downloads of paid websites. Aaron's abuse of the PACER resources should have correctly led prosecutors that he'd pulled this sort of thing before and would continue doing so without an actual conviction.
> I do not understand the rationale for universities and researchers more particularly wanting to have their research locked behind pay-walled services such as JSTOR
It's well indexed and cross referenced, reliably available, and has become the "one-stop" resource for research documents. That is _invaluable_ when looking for obscure documents or tying together research among multiple fields. JSTOR is getting paid, and not an outrageous amount, for that work. Some fool replicating their entire index and layout, as Aaron Swartz was clearly attempting, means that their income to continue the organization of the material dries up and will not be continued. And JSTOR subscriptions have been much more cost effective than Google searching or library searching for research documents.
It's the same reason newspapers or magazines put up paywalls: one has to pay the writers and editors, or in this case the indexers and the maintainers of the quite robust and effective back end. Good backups and failover facilities are not free, and JSTOR has been a reliable and invaluable resource. Aaron was threatening that by overwhelming and crashing the services. The documents are kept available much longer, and much more reliably, than a community driven or freeware service could hope to manage. JSTOR see themselves as librarians of knowledge, not as vendors of knowledge, and I applaud their efforts.
In his office at Harvard. He had legitimate JSTOR access there. The difficulty is that he needed _bandwidth_, and ideally to avoid detection on the routine network maps managed by IT staff, and to avoid the typical monitoring and proxy configurations found on most competently administered public wi-fi access points.
> Swartz was not an asshole,
No, he was an asshole. The *scale and intensity* of his attempt to download and replicate *all* of JSTOR, including the indexing, was not only illegal in itself. Because of the amount of bandwidth he was using, he repeatedly crashed parts of JSTOR. That means that researchers and scholars woldwide lost access to a vital research tool. And as a response, and to protect the rest of the world's access, they finally had to cut off MIT's access. He was screwing with people doing medical research. People *die* because cutting edge research gets held back for bonehead reasons.
If Swartz had taken the single step of cutting the bandwidth he used by 75%, JSTOR wouldn't have kept crashing and had to punt MIT. And if he'd done it from his office at Harvard, *which had similar access to JSTOR*, there probably wouldn't have been a way to charge him, and it would be his employer's problem. Swartz was allowed on the MIT campus because of his Harvard ID, and his screw up has cast that whole reciprocal agreement between MIT and Harvard for library and campus access in doubt.
What Swartz did was not directly stealing from the authors of the research, it was making their research inaccessible while in progress. It screwed with the thesis writing of friends of mine, and interfered with research projects throughout MIT. Frankly, MIT should have been *much* more eager to help slap cuffs on this twit, but they're traditionally very, very slow to act against "cracking" because it's *embarrassing*, and the prosecutors inevitably fuck it up. Look into the David Lamacchia case about 10 years ago for an example
> These aren't tech support jobs they're design and engineering teams
That certainly does not mean they are employees, and not contractors. I've often helped train such contractors, and helped them get their development concerns verified by an outside agency so that they're taken more seriously and actually addressed rather than lost in the "not invented here" distaste from headquarters based teams in their own company.
May I say that we all miss Groklaw's insightful analysis, and very open access to, the core documents and analyses of these cases? If anyone on Slashdot knows PJ personally and can encourage her to accept the problem of email monitoring and return to her legal soapbox, she'd be welcomed. Groklaw's analyses of these cases, and PJ's careful attention to detail were welcome and instructive.
> Also it isn't entirely true that there isn't any authority available for ssh. You could make use of RFC 4255 or RFC 6187.
Neither were part of the original RFC specifications, and neither work in most production SSH clients. I'm afraid that I've not seen anyone actually use the DNS published signatures for SSH keys in the 8 years since RFC 4255 was published, and most clients have no capability for it. RFC 6187 seems to have been roundly rejected by the OpenSSH developers, who came up with their own signature technology that no other SSH client seems compatible with and is not easily backported to previous OpenSSH releases. And again, I've seen no corporate, educational, or private institutions even trying either technology.
I agree that it's problematic: secure handling of credentials is a very, very sore point in many IT organizations, and many groups ignore good practices because they "trust the people they work with" and "if they're on our network, we have much worse problems". Or they sign extensive security policies and then simply ignore them.
> There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks.
Nonsense. Ownership of the host private keys, stolen from the target SSH server, allows quite effective MITM: see http://www.gremwell.com/ssh-mi... and http://www.snailbook.com/docs/.... Moreover, there is no reliable ownership or timestamp on SSH private keys. And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler. And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.
This is, effectively, no different than enabling SSL keys without any signature whatsoever, which is the state of SSL in most environments because many private and public institutions do not bother to purchase signatures for their SSL keys.
And the "man in the middle" is often actually at one end, on the local router or on the local network switch, with simple packet snifing in place. It's not rare, it is _ubiquitous_ in many educational and corporate environments.
> What other extreme "+1 Interesting" edge cases can you think of for why all of the normal options just couldn't work?
Source code, or source code used to compile working version, is gone. That means a complete rebuild _of the source tree_, and with older projects a complete rebuild of the toolchain used to compile the source. This is often very, very expensive, but vital for software upgrades to run on modern operating systems.
Sir or madam, I am impressed at your swift pursuit and analysis of this issue. I wish far, far more engineers would actually _find_ the problem, rather than discuss the political implications. If you're involved in any major software or hardware projects, I would be delighted to see if my colleagues or I would have uses for them. And I hope your current workplace realizes the kind of engineer they have on their hands and are paying you enough.
> Jokes aside, I never understood why people live in KNOWN dangerous places.
Because it's only one factor. Farmers value the fertile land where floods deposit soil, and it's rarely feasible to live very far from the farm. Traders value the shipping made easier by river or ocean traffic near river heads, but those are likely flood areas. Damming and irrigation and dikes can actually _change_ the shape of the flood plain, making formerly safe areas profoundly more dangerous. Industries rely on the river water or hydro-electric power, and long commutes to work are a subtle tax on every worker's time every day.
Would you pay double the price of your current home, or apartment, to live in a safer place further from your work? Could you afford it?
Or they had the grace to _shush_ when the driver was dealing with a crazy intersection.
It's also been reasonably verified in medical studies, such as http://bjp.rcpsych.org/content....
It an also be difficult to measure.. The intensity of a mania can make one feel like one is very, very productive in many ways, but the productivity can be complete gibberish. This is visible professionally among coders who do binge programming sessions of exciting work that creates reams of exciting new ideas paradigms. But on review, the ideas are old, poorly implemented, and worse, entirely undocumented. This is followed by the attitude of "just read the code" and "it's so simple, it doesn't need testing".
Yes, I've seen work done by bi-polar colleagues before they were diagnosed or were off their meds. It may be less inventive, but it's far better quality code when they're medicated.
Because navigating byzantine bureaucracies is an invaluable work skill. I'm blessed with colleagues, and managers, who are very good at navigating these, and getting our technical personnel paid for the time burned in this arena. If you cannot navigate these pitfalls yourself, your managers will have to spend far more time doing it for you. They will also _own_ you, since you'll have no way to defend against decisions that eliminate your project or that take unearned credit for your work.
Thinking more for this anonymous reader: the combination of Java experience and VMware experience is intriguing. There are other virtualization technologies, and newer "container" technologies, that could benefit from streamlining and integration. Doing some open source development with tools like Tomcat or JBoss, and the "maven" or "ant" toolkits to build Java components, might provide good leads to workplaces that would benefit from your experience.
> My other advice is that Linux sysadmin (especially contract) pays more than dev.
My experience is that admins tend to make _less_ per hour than developers with the same amount of experience, but the work is much more stable. _Architects_ make more. Systems admins tend to be generalists. Showing a variety of skills, and being able to apply lessons from one to lessons in another environment are invaluable. So your VMware experience can be tied to systems integration work, monitoring, cloud computing deployment, software optimization, security, and resource planning.
Also, learn to cook. You say that your girlfriend is supporting you for a while? Then she deserves her dinner on the stove with clean plates and a cool drink when she comes home from work. It will save you both a lot of money on eating out, and it will keep you from spending all your time glued to a monitor reading Slashdot. At the interview, if you mention it, it also shows "this person cares about the people around them", especially if you can demonstrate it by arriving at a job interview with a plate of good home baked cookies or brownies. Applicants like that are _remembered_ by HR personnel and interviewers.
Again, that's applying technology, after the fact, to fix the _workflow_ problem that introduced mixed coding standards. Cleaning up the existing code base, especially for collaborative projects and groups that have distinct standards and refuse to follow each other's layout practices, makes this a very expensive proposition to enforce.
> Easy, they can still check out old files, revision history remains intact, everything is good in the world.
As soon as you do "svn blame" or "git blame" or extract "diff" outputs from revisions before and after the white space synchronization, you've a change tracking difficulty. I'm not saying this is impossible to do, I'm pointing out that it's expensive. It also _breaks_ many revision analysis tools.
This is infeasible. Network tools like "tripwire" have powerful, legitimate uses.
> Like others have posted, the open source community is going to have to look at the released code very very carefully. The public has to assume that the NSA will include backdoors or obscure weaknesses if at all possible.
And look for licensing violations. Various "open source" license models allow modifying and republishing software without publishing your modifications. But if they inserted back doors into, for example, GPL licensed software without publishing the back doors, they'd be violating the software licenses.
Especially to train drone pilots.
> You won't find ANY military aircraft in ANY country on the planet that didn't have similar issues in its development, at least not since WWII.
Not this late in their development.
The F35 has directly competing design goals, ranging from their supersonic stealth capabilities to their short take-off/landing requirements, which is precisely _why_ the tires cost $1500 and wear out so quickly. The belief that throwing more billions of design to resolve what are fundamentally incompatible needs for power, speed, stealth, aircraft carrier landing, and three different military departments' military needs are what we who do contracting would call a "money trough". The competing design requirements ensure that no design will _ever_ work well enough and it will _always_ require expensive revamping of the entire architecture to serve the conflicting clients' needs.
> But the F35 is more or less combat ready in its basic form
As long as you don't try to land it in cloudy weather.
http://www.alternet.org/fail-4...
Or on an aircraft carrier:
http://theaviationist.com/2012...
Or landing on the $1500/each tires twice in a row:
http://www.bloomberg.com/news/...
Oh, and if the landing gear fails and the pilot has to eject, they can't safely eject over water. (See the first article.)
If we needed to build supersonic "launch-only" aircraft, we could have done so _much_ more cheaply.
Please read the contract. From work with email systems, I've often needed access to the mail queues in order to verify operation or delivery of email, and the relevant agreements have been very clear that I had the access to do so.
I've been asked to do monitoring on more than one occasion. I was once asked to to replicate all email for a particular user to a manager's mailbox, for a company I was collaborating with, while their core IT administrator was on another project. I carefully did the work, documented the procedures in their IT wiki, and notified the company's technical contact with us of the billable work and the completed documentation on the specific project. Since the targeted user was the technical contact with us, and the person who signed checks for my company's work, this fulfilled the letter of our agreements and let the target of the monitoring know what was going on and how to detect it in the future.
The technical contact was in the process of leaving the company: this let them know that they were also getting their corporate email monitored and they should be _very_ cautious about what they said to current contacts. We had some fascinating discussions in private about their reasons for leaving.
Do read the rental agreement. Many in the US,and overseas, do include clauses to address precisely this sort of thing, and a clearly written contract can help prevent many confusing "edge" cases.
Yes, what you've mentioned is true. But it does not address a single one of the problems _I_ had mentioned, which have to do with workflow and different coding standards from different groups, "Disallowing tabs" can be a reasonable internal coding policy, but the migration to it is likely to be filled with pitfalls, especially if any of your group's code involves older projects or third party code that has to be kept in sync and patch compatible with outside code.