|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 28
Messages: 28
Messages: 28
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ted Neward on Java Security
Ted Neward has written a scathing rebuttal of the recent Java Developer's Journal article on Java Security. He walks through the points made, and tells us in his own special way, what he thinks it totally incorrect :)
IntroductionRecently (Volume 9 Issue 4: April 2004) Java Developer's Journal ran an article on Java security that I just found myself virulently (and violently--I had to spackel over the slight divot in the wall that the magazine corner made when hurled against the wall with great force) disagreeing with. Naturally I now foist my arguments upon you, my faithful blogaudience....
The basic upshot is simple: I sincerely believe these three authors were more interested in showing off how smart they were than in genuinely helping Java code authors. Otherwise, how can you explain an article on Java security that never once mentions the AccessController/SecurityManager, JAAS, Permissions, or policy? Read Really Bad JDJ security article: rebutted
|
|
|
Message #119520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
amazing!!!
I also thought the article was a waste of time and space. I am glad someone stood up and said so!
Bruce
|
|
|
Message #119547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
blogaudience
Shouldn't the term be coined as:
Term = blogdience
Pronunciation = blog dee ence
Definition:
1) Avid reader of a blog. 2) Intended reader of a blog.
|
|
|
Message #119549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ted Neward on Java Security
Quite a few "security experts" must be logic impaired.
The fact that we have an access specifier called "private" has absolutely NOTHING to do with security. Yet everyone is talking about how important it is to secure instance data by making fields private. What nonsense is that?
Choosing the proper access specifier is an OO encaptulation issue, not a security issue. Three lines of reflection code is what it takes to get "private" data anyway...
Cheezus.
|
|
|
Message #119573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ted Neward on Java Security
Ted has pointed out regarding one article on so called Security.
However this also reflects a larger problem with JDJ.
The quality (& content) of articles in JDJ has been on the downhill for a while now. For a magazine like JDJ that charges for its content, it is pretty weird to adopt the policy "writing is the reward by itself".
Consequently JDJ has become a magazine with articles "by newbies, for newbies and of newbies" (with exceptions once in a while). Nothing wrong with that.
Even first timers have great ideas and articles. But there is something called filtering the content to maintain the standard of the magazine.
For whatever reason, there are two categories of articles that appear in JDJ these days.
1)Articles such as "Java basics", "OO and Polymorphism". This forms the majority. (Come on. Java has grown up. We need something more serious than this.)
2)Product promotions veiled as articles
It's time JDJ catches up or risk oblivion.
Cheers.
|
|
|
Message #119578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ted Neward on Java Security
For whatever reason, there are two categories of articles that appear in JDJ these days.
1)Articles such as "Java basics", "OO and Polymorphism". This forms the majority. (Come on. Java has grown up. We need something more serious than this.)
2)Product promotions veiled as articles
It's time JDJ catches up or risk oblivion.Cheers. +1
|
|
|
Message #119590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ted Neward on Java Security
Plus they act just like spammers do - I tried to "unsubscribe" from their "JDJ Industry Newsletter" not long time ago with no apparent success.
|
|
|
Message #119597
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I generally agree, with some issues....
I agree with Ted, the article truly sucked. Without covering such things as JAAS, JSSE and classloading it misses the main and perhaps easiest ways to make a Java application secure.
I will go out on a limb and take issue with some of his rant however. He says some things that I think are a bit odd and I think he's missing something.
"3. Make your classes noncloneable. Cloning isn't turned on unless you implement the Cloneable interface anyway, last time I checked...."
Check again: I can make a class cloneable simply by overriding the clone() method of Object. Cloneable is a marker interface. Making a method non-cloneable means to explicitly through a CloneNotSupportedException if this method is called. This also guards against a superclass that IS cloneable, but one that you don't have the source to. Of course you don't need to do this if you do want your class to be cloneable, for some architecturally significant or design reason.
"Make your classes nonserializable. Serializability is an issue all its own, best addressed by Joshua Bloch's Effective Java. Simply saying "make them nonserializable" is nonsense, particularly since you have to opt-in by implementing Serializable in the first place. Moreover, they completely ignore that an attacker can always look at the internal state of any object, serializable or not, using Reflection, assuming he has code that's executing with the proper permissions."
Uhm, kinda the same as the Cloneable argument above, Check again: Once again a marker interface that can be implemented by a superclass that you have no source to. Guard against it the same way you do Cloneable - explicitly implement the readObject() and writeObject() methods of Object and have them throw an exception.
"5.Do not depend on package scope. You would almost think from their article that Sun just sort of let package scope "happen" by accident. And what about protected scope, which permits access by the package as well? That's OK, but package-level isn't? "An attacker can simple add another class to your package and then access package-private fields that were supposed to be hidden." Yep, and if the attacker can simply add another class to your package, chances are he can replace your code of the same name in that package. You guys are looking for attack vectors that simply don't exist.... Look, this, and #2 and #3 and #4 are all essentially worthless, under the principle that "if the attacker can inject code into your system, you're done anyway...."
There are lots of ways and reasons to inject a class into a package to obtain the package scope variables without replacing the original - like say eavsdropping on an applet in your local VM? Anyway, perhaps I'm an old C++ guy, but I have never seen the utility of package scope so I never use it anyway. And just because Ted can't think of a reason to do this, doesn't mean someone else hasn't. Those are attacks that can be used to gather information when you don't have the source code.
I still think these are very good coding practices and should be encouraged and not ridiculed by someone of Ted Neward's noteriety. Whether by mistake or by design, this diatribe seems to indicate you don't have to do any of this or the other stuff (making classes and methods final, avoiding returning internal references, keeping stuff private etc) and you can still have secure code. I think that's just about as bad as saying that's ALL you need to do (as does the JDJ article in question).
Of course you should do all that stuff. Not just a few, ALL of it. Don't make it easy for a would-be attacker. And, like Ted says, it won't matter much if the your code does not take advantage of SecurityManagers, policy files, permissions, obfuscation, sealed jars, preferred classes lists, JSSE and crypto to add security. Do it all. Make it so difficult to "hack" your code, that the "bad guys" will move on to somebody elses code.
Now. by the looks of the other comments here I'm gonna be flammed big for this but I don't care. Ted may not see the danger in some of these recomendations, but I think that kind of defensive coding will only strengthen your code. And who know's, it may prevent an attack no one has everthought of.
|
|
|
Message #119622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I generally agree, with some issues....
As long as you want shallow (memeberwise) cloning, then Ted's statement is 100% correct.
And you can't make an object cloneable by just overriding the Object.clone() method; you have to call super.clone() from the overriding method. And guess what happens if you're not implementing Cloneable? That's right, it will bomb with a CloneNotSupportedException.
If you don't implement Cloneable, and consequently can't call super.clone(), then the only way to clone the object is by calling a constructor with new. But if a client extends your class, it will get the wrong class type when it calls super.clone(). That's why Object.clone() is native, because it creates a copy of current object without using a constructor.
The Cloneable marker interface is just bad design because its tightly coupled with the semantics of a protected method in the superclass. So from a client's perspective, it's useless.
|
|
|
Message #119678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks for that.....
Joseph,
It's good to see someone who puts aside professional hurbris and admit they made a mistake. I think some folks at TSS should learn from this and drop the condescending, holier-than-thou zealotry I've been reading here for 4 years.
(Yes, I have been posting here for about 4 years, despite my 'new' status. I stopped posting in disgust after the Petstore debacle and, of course, lost my old ID....)
Anyway, sorry for the rant and thanks again.
Mike
|
|
|
Message #119687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My response to Ted's article
Hi, guys. I posted a public reply on http://epesh.blog-city.com/ - Ted's pretty much right about that particular item. Sorry about that. Joseph thinks that the security article is a "mea culpa" and otherwise things are okay at JDJ. I strongly disagree. I think the problem is bigger as I pointed out in an earlier posting here.
I am one of the Server Side commenters on JDJ that you pointed to be saying "this is the kind of crap JDJ prints now". Those were not the exact words. But anyway you summarized it well.
My comment about JDJ articles of being "OO and Polymorphism" are sometime back. I have stopped reading JDJ since then.
I just pulled up Issue 3 and Issue 4 of JDJ before writing this feedback. I see articles with no depth - just skimming the surface - and a whole lot of them. Let us take an example.
JAXB for Enterprise Applications. It looks to be one of the feature articles in this issue (Issue 4). Yet it is a page or two. It goes like: Here is the API. Here is how you use it. alright Bye bye.
Any decent developer can figure it out by reading Sun's tutorial. You dont need an article on that. Sun's tutorial is does that job.
If I wrote a article, it would be something like this:
The problem: XML to Object conversion
Forces: Configuration needs it, Web Services need it, other places needed
Solutions available: Castor, JAXB, Digester
Compare and contrast each of them.
Describe each of them.
Describe several scenarios and which one is suitable in each scenario. What are the shortcomings of each. Showstoppers in each.
And each of the above categories in detail.
As you can see writing an article like this requires a lot of research, a lot of homework from the author's part and not just some scribble over lunch time.
When the readers read such an article, they will read it with interest. There will be a sense of contentment after reading it.
So, here is my suggestion: Instead of running pointless interview with the manager of a product team or a dozen articles scratching the surface,
just concentrate on getting two or three articles of the fashion I pointed out and see for yourself how the developer perception changes.
In the changing world and maturing Java, I feel JDJ needs to change. JDJ cannot be everything to everybody. Yet this is how I think it should be and lot of people will agree with me.
PS: This is extracted from my feedback at Joseph's blog
|
|
|
Message #119691
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My response to Ted's article
I responded on my blog, as well, but let's clarify a few things.
You said I thought "everything was okay at JDJ." I'm not sure where you got that - maybe by the implication that I think things are better at JDJ than you do.
I'll stand by that, sure. But not that "everything is okay at JDJ." I don't think there'll ever be a condition where stasis is acceptable. In fact, I'd say the article indicated a few internal things, and the JDJ editors are certainly actively talking about it, trying to find a constructive solution. I'm not sure what it'll be yet, but we'll get there, I think, because optimism is hard to kill.
I appreciated the feedback, and pointed it out internally (like I said). I welcome any commentary, positive or not, and I'm not afraid to be honest about things.
For the future, though, please refrain from making my conclusions for me - especially when the conclusions you make for me are wrong. :)
|
|
|
Message #119693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My response to Ted's article
Joseph,
"Everything is okay at JDJ" was a wrong choice of words from my part that significantly altered the meaning and is misnterpreted. I apologize.
What I meant to say is :
You implied other articles at JDJ are OKAY except for this one. This is evident from the following statement in your blog - "This article got skimmed by me..."
They may be technically OKAY - like the example I gave earlier.
That article did not have technical glitches.
But the question is: How useful are those articles?
If they aren't useful are they OKAY?
That is what I meant to convey.
However I did NOT draw conclusions for you. Neither would I want to.
I am sorry if my comments made you feel so. But those comments were my 2 cents based on genuine interest to help improve JDJ.
BTW, I appreciate you voluntarily taking out time to go through countless articles that are slammed on you. I VERY WELL know being EiC is an endurance test :)
I dont have much to say since you feel breadth is more important than depth for the magazine. Let us agree to disagree on this issue :)
As for your suggestion for me to make an attempt to write an article like that: I have news for you. I wrote the first cut of that article last year. It is part of my forthcoming book. Also having written a couple of articles myself (which I think were depth oriented. It is for others to judge), I very well know how difficult it is to write an article with such depth. It took me more than a month to write the above mentioned stuff!!!
That's why I said: Publish two to three articles with depth. But hey! we are already on diagreement on that one.
|
|
|
Message #119695
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My response to Ted's article
Whoa, there!
Again, be very careful. I appreciate your apology - no offense intended, none taken - but I'm neutral about whether JDJ is depth-first or breadth-first. I personally prefer depth, but changing a magazine's core format is not an exercise for the uncommitted.
That said, I'm willing to do it if - and only if - it has meaningful reward. I'm afraid I don't have a lot of experience in publishing, so for me, such moves are made very cautiously.
There are a lot of issues to address. I'm trying to address them. Because of the structure of JDJ, we get a lot of breadth-first articles, which obviously limits the number of depth-oriented articles we get. I'm certainly not averse to authors writing things that fit, as I've said before (on my blog and on Javalobby).
I still think this article is a secondary symptom (and yes, that means I think things are far from "okay" at JDJ - but I also don't think the sky is going to fall.) Reading it in print, my thought was, and I quote, "Oh, crap." That, in itself, isn't a big deal - but the fact that it got through is.
|
|
|
Message #119700
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My response to Ted's article
I personally prefer depth, but changing a magazine's core format is not an exercise for the uncommitted.That said, I'm willing to do it if - and only if - it has meaningful reward. I'm afraid I don't have a lot of experience in publishing, so for me, such moves are made very cautiously.There are a lot of issues to address. I'm trying to address them. Because of the structure of JDJ, we get a lot of breadth-first articles, which obviously limits the number of depth-oriented articles we get. I am no editor and I dont know how it works. But I have a suggestion for an experiment you can try out without too much risk. You can do this if an established image isnt important to your magazine.
1. Lets say you select an issue in the future (say Oct 2004) and earmark it for depth first articles.
2. Invite articles from authors by setting pre-requisites - content type, no of words. conent quality, depth etc. (The number of words itself will be a deterrent to folks not serious about writing)
3. Set aside a few pages towards the end of the magazine for intro articles on emerging technologies (those are always needed to introduce the reader to a new technology on the horizon)
4. Thereafter continue your issues in the normal fashion as they are now.
5. In the meanwhile extensively gather reader's survey on the changed format
Obviously I am not qualified to even estimate the behind the scenes logistics of this experiment. So, take it or leave it.
Another added benefit is that It will save you from having to filter through countless "me-too" articles.
|
|
|
Message #119712
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks for that.....
Joseph,It's good to see someone who puts aside professional hurbris and admit they made a mistake. I think some folks at TSS should learn from this and drop the condescending, holier-than-thou zealotry I've been reading here for 4 years.(Yes, I have been posting here for about 4 years, despite my 'new' status. I stopped posting in disgust after the Petstore debacle and, of course, lost my old ID....)Anyway, sorry for the rant and thanks again.Mike By the way, Mike, I posted a reply at http://www.neward.net/ted/weblog/index.jsp?date=20040427#1083085266555 .
|
|
|
Message #119729
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles
Hi Joseph,
I'm currently a subscriber to JDJ, but after this subscription expires I'm not likely to renew. The main reason is that I miss in-depth articles that teach me things I don't get elsewhere.
Back in 1988, when I was seriously learning C and Windows, my main magazines were C Gazette (still one of my favorites), Microsoft Developers Journal, Dr. Dobbs and the magazine Jeff Dunteman published (sorry, the name escapes me).
Now it's the late 90's and I'm mostly doing management and very little coding. 2002 and management positions are more scarce. I decide to retrain and learn Java and server-side development.
Not unsurprisingly, the landscape of magazines has changed a bit - and in my opinion not for the better. Old classics like Dr. Dobbs seem to cover less in-depth than before. The magazines are much lighter than I remember and I'm not getting what I'd hoped for.
Forums and blogs now compete with established magazines. Discussion forums help validate the points discussed in articles so it's easy to know what to avoid.
I don't envy your position. If your desire is to cater to the new developer, then I wouldn't change a thing. For myself, I'm looking for information I can't get anywhere else.
Thanks for listening,
Chris
|
|
|
Message #119791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Good Reply
Ted,
Very good reply. I accept all of your points. I was just trying to point out in my rebuttal that it certainly doesn't hurt to do all those things in order to have as much "security" at every level as you can. I did get the impression that you were discouraging the practices mentioned, even though now I know that was unintentional. I just want to make sure that some of the less experienced among us realize that code security involves those things mentioned in the JDJ article in conjunction with policy files, class loader security, JAAS etc.
And I just want to be clear that my " condescending, holier-than-thou zealotry" was not aimed at you in any way. You actually put up some good arguments, I replied to clarify, you rebutted to clarify even further. That's the way these forums are supposed to work. As I indicated I haven't been on here in a while and in getting caught up in the last few weeks, I have noticed a lot of 'ra-ra my way is the best way, you other guys suck' type of responses in a great many threads. And I find that disturbing, since the TSS used to be the place for sensible debate and exchange of information, where that kind of behaviour was usually relgated to Rolf Tollerund ( ;-) ). Now it seems to be more common, almost like TSS is turning into Slashdot or something.
Anyway, keep up the good work. Perhaps the next step, instead of a rebuttal, is for one of us to write a 'real' Java Security paper to post here or send to the JDJ for publication. One that covers the right stuff. I'll have flip through Scott Oaks book and some of my code and see what I can do....
Mike
|
|
|
Message #119805
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Good Reply
Perhaps the next step, instead of a rebuttal, is for one of us to write a 'real' Java Security paper to post here or send to the JDJ for publication. One that covers the right stuff. I'll have flip through Scott Oaks book and some of my code and see what I can do....Mike I'd be game for that.
|
|
|
Message #119853
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Plagarized article?
Hi Joseph,
As a person who has had to deal with plagiarism of my own articles, I found the similarities between the first part of this article and the guidelines given by the authors of the book Securing Java in chapter 7 section 1 to be eerily close. Fortunately, this book is freely available on the net and I will leave you to make a decisive judgement on whether the first part of this article is plagiarized to a heavy degree or not. (Note that the authors give a link to the book in the list of references. However, that does not allow them to plagiarize its contents.)
The original book contents:
http://www.securingjava.com/chapter-seven/chapter-seven-1.html
All rules, except for rule 6, have been lifted straight out of this book. Further, the article authors have gone ahead and lifted the text describing the rules as well out of this book. Listed below are only some of the sample areas where the plagiarism is seriously obvious.
1. Consider part of rule 3 in the offending article:
"Java's object cloning mechanism can allow an attacker to manufacture new instances of classes that you define, without executing any of the class's constructors. Even if your class is not cloneable, the attacker can define a subclass of your class, make the subclass implement java.lang.Cloneable, then create new instances of your class by copying the memory images of existing objects. By defining the above clone method, you'll prevent such attacks."
and the same rule description in the original book (rule 8)
"Java's object-cloning mechanism can allow an attacker to manufacture new instances of classes you define, without executing any of your constructors. If your class is not cloneable, the attacker can define a subclass of your class, and make the subclass implement java.lang.Cloneable. This allows the attacker to make new instances of your class. The new instances are made by copying the memory images of existing objects; although this is sometimes an acceptable way to make a new object, it often is not."
2. Consider rule 7 in the offending article:
"If a class, method, or variable is not private, hackers could use it as a potential entry point. If there is a good reason why a method, field, or class should not be private, it does not need to be private, but that reason should be clearly documented."
and the same rule in the online version of the book (rule 2):
"Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something non-private only if there is a good reason, and document that reason."
3. Finally, consider rule 4 in the offending article:
“This rule requires that if you want to prevent access to the internal state of your objects, make your class nonserializable. If you don't, your objects can be serialized into readable byte arrays. As a result, hackers can view the objects' full internal state, including private fields and the internal states of referenced objects.”
And the same in the book:
“Serialization is dangerous because it allows adversaries to get their hands on the internal state of your objects. An adversary can serialize one of your objects into a byte array that can be read. This allows the adversary to inspect the full internal state of your object, including any fields you marked private as well as the internal state of any objects you reference.”
I will leave you to compare the rest of the article and the book's contents.
Regards,
Vikram Goyal
|
|
|
Message #119858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles
Woo Hoo....
Vikram - You have given another (legal) angle to this article.
Now this is getting interesting.
Shall we say "reuse taken to next dimension" ...
|
|
|
Message #119863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Plagarized article?
OMG, this is a scandal! These guys are shameless! Anyone who took English 101 at school would know this is illegal plagiarism.
I think the author of the book should be notified and JDJ should immediately publish a retraction of the article.
|
|
|
Message #119921
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
I strongly agree. Over the last year, JDJ's focus has become less hardcore. Veteran or mid-level developers are not going to find it as attractive as it used to be. What a pity.
Regarding another post here about the JAXB article, those were my feelings exactly too and it is symptomatic about the shift in JDJ's focus. There are a zillion tutorials/articles out there that tell you what JAXB is.
JDJ filled the need earlier for the hardcore Java developer's magazine. Now they have shifted focus so the need is there again. Does TSS want to fill that need? How about TSS coming out with a hardcode Java developer's magazine? I am sure it would sell. Just target the right market (hardcore Java developers) and do not go for mass market. I am sure there are people willing to pay for the right stuff.
|
|
|
Message #120227
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
Lots of issues here. Plagiarism is a serious charge; what ended up happening is that some fairly common "security tips" got published as a core article. It was insufficient on a number of levels, and for a number of reasons.
I don't know about JDJ "retracting" an article. I considered that already, but that's sort of like "unspilling" milk; the article's been printed, and the suggestions, while not always complete or necessarily as valid as I'd have liked, are still fairly accurate.
Regarding in-depth articles, that's been discussed heavily, as well. If TSS would like to enter the print market, well, come on in - it's a highly competitive market, and I wish all of our competitors well. We certainly don't want to abandon a market sector - and we're certainly interested in soliciting articles of greater depth. In the absence of a "techie's journal," please feel free to write anything you think others would like to read. We try to publish what is best out of what's been written; if nobody's written something of sufficient depth, well, it won't get printed as something of sufficient depth.
|
|
|
Message #120378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
Lots of issues here. Plagiarism is a serious charge; what ended up happening is that some fairly common "security tips" got published as a core article. I find this explanation seriously lacking. To simply claim that "some fairly comment 'security tips' got published as a core article" is to claim that "mistakes were made" and "people were upset". This is a huge embarrassment for any publisher, I understand, but Joseph, those tips read almost word-for-word identical.
I contacted Gary McGraw (someone whom I consider a friend) about this when it was brought to my attention, and he's promised to look into this. Apparently this isn't even the first time this has happened with this material, though I'll leave the details out for now.
Joseph (if I understand correctly that you're involved at JDJ somehow), IMHO you're in danger of losing some serious respectability points, as well as treading on thin legal ice. I am not a lawyer by any stretch, but as an author of both books and white papers, I would be furious if this had happened to me, and would be pursuing this with both barrels blazing, so to speak, particularly in light of the entirely inappropriate response above. As an editor as well, I would be furious that an author or authors had tried to sell me material that wasn't theirs to sell.
As to TSS entering the print market, what on earth made you think TSS has any designs in that direction? We're quite happy remaining an online community. Meanwhile, I think, you have other issues to attend.
Ted Neward
Editor-in-Chief, TheServerSide.NET
|
|
|
Message #120409
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
I find this explanation seriously lacking. To simply claim that "some fairly comment 'security tips' got published as a core article" is to claim that "mistakes were made" and "people were upset". This is a huge embarrassment for any publisher, I understand, but Joseph, those tips read almost word-for-word identical. I'm not debating that. I'm not even saying "Plagiarism is an unjustified charge." Nor am I unconcerned about the issues - technical and otherwise - brought up. At no point am I dismissing what people are bringing up.Joseph (if I understand correctly that you're involved at JDJ somehow), IMHO you're in danger of losing some serious respectability points, as well as treading on thin legal ice. I'm the editor-in-chief of the print edition of JDJ, so yes, I'm "involved" somehow. I'm not sure how my respectability is brought in any further; I'm not dismissing the concerns about the quality of the article, nor am I dismissing charges of plagiarism, but such is not my bailiwick. I'm definitely unhappy, and publicly so, about the whole thing. The article shouldn't have gone to print, for a number of reasons. It did go to print. I publicly discussed it, and continue to do so. Legally, I'm aware of the issues, to be sure. Shaking a big stick in my direction doesn't change that, nor does it change the fact that such charges aren't to be made lightly, dismissed lightly, or even investigated without due care, care which is not my domain. My caution is not to imply that there's nothing wrong here. My caution is indicative of my concern that public cries of plagiarism border on slander for the accused - if it's not plagiarism....I am not a lawyer by any stretch, but as an author of both books and white papers, I would be furious if this had happened to me, and would be pursuing this with both barrels blazing, so to speak, particularly in light of the entirely inappropriate response above. As an editor as well, I would be furious that an author or authors had tried to sell me material that wasn't theirs to sell. Indeed. Which response was inappropriate, Mr. Neward? The one that says "I'd like to be careful here, so that we get it right?"As to TSS entering the print market, what on earth made you think TSS has any designs in that direction? We're quite happy remaining an online community. Meanwhile, I think, you have other issues to attend. I wasn't the one to bring that up. Direct any queries there to the appropriate parties.
Joseph Ottinger, Editor-in-Chief, JDJ
|
|
|
Message #120429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
Regarding TSS wanting to enter the print market, Joseph was merely responding to a comment I made in this thread, as people do on discussion boards. Take it easy. It's a discussion board for Christ's sake, not an exam.
|
|
|
Message #120488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In-depth articles - opportunity to be grabbed
I would ask that anyone participating on this thread hold off on further comment on the plagiarism discussion for a while; I know that Gary has contacted Joseph and they are discussing it in all detail. Joseph and I have talked a bit over private email, and I'm now convinced that he's taking this charge seriously (which was my principal beef with his response), and is looking to do what's best for all parties concerned, which, he reminded me, includes the authors of the article in the event that it's discovered that no such plagiarism occurred. Kudos to him for trying to steer the line of "innocent until proven guilty" on this topic.
The right thing is trying to be done here, and I'd hate for Joseph to take further flak for commenting on something that he really can't comment on (for a variety of reasons, legal and moral/ethical).
I encourage anyone who's interested to email me privately at ted@neward.net.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
