Precedent has it that acquiring.evil.mega.corp rewrites the data retention / privacy policy to allow them to do as they please, irrespective of any clauses, promises or contractual arrangement to the contrary.
Almost all such policies have at least some leeway for the site to make (minor) modifications (otherwise even correcting a typo would, theoretically, change the contract); so mega.corp simply argues that its new policy is a permissable change. Then it leaves it to the users it has pissed on/off to bring a class action against them, which it will drag on in court for years, and maybe eventually (albeit unlikely) pay some damages... way after the damage to you has been done.
The short of it is: you can't trust ANY company or person with private information. All you can do is weigh the risk, and decide how much you think you can get back (in damages) if (when) they abuse it.
Keeping your head inside a bag will certainly damage most projects - but this is often a question of the level of development in question.
Software engineering covers everything from requirements down to coding. You can't perform SE in a black box. Too often software development is performed in a business black box: there is no proper interaction with customers to really learn their requirements, what other systems to integrate with, etc. At the opposite end of the spectrum, coding CAN be performed in a black box.
You see, by the time you've established requirements; architectured, designed and exercised the system; and cast your APIs in store; you no longer need to consider what goes on outside your black box.
In reality, this is a dangerous practice. Very few development teams are mature enough to thoroughly design an API that doesn't have side-effects, or even to correctly identify the boundaries of a "black box". So most of the time everyone has to be aware of what's going on around them.
The trick is handling side effects. Modular development says that you don't make account (in your black box) for problems in another box -- unless there is no way to correct that problem (legacy compatibility, operating platform, etc). And when you do make such a fix, you lose a significant amount of modularity for that component.
An engineer was enjoying a cruise in the Caribbean. It was wonderful, the experience of his life... but, it did not last. A Hurricane came up unexpectedly and the ship went down, giving only a few barely enough time to escape.
The man found himself swept up on the shore of an island. There was nothing else anywhere to be seen. No person, no supplies, nothing. Looking around he saw some bananas and coconuts, but that was it. He was desperate, and forlorn, but decided to make the best of it.
So for the next four months he ate bananas, drank coconut milk and stared out to sea waiting for a ship to come to his rescue.
One day, as he was lying on the beach waiting dejectecly for a while, he spotted movement out just beyond the waves... and there from around the corner of the island came a rowboat. In it was the most gorgeous woman he had ever seen: she was tall, tanned, with blond hair flowing in the sea breeze. She spotted him waving and yelling, and rowed her boat towards him.
In disbelief, he asked, "Where did you come from, how did you get here?"
She said, "I rowed from the other side of the island. I landed on this island when my cruise ship sank."
"Amazing," he said, "I didn't know anyone else had survived. How many of you are there? Where, did you get the rowboat? You must have been really lucky to have a rowboat wash-up with you?"
"It is only me," she said, "and the rowboat didn't wash up, I made it."
The engineer's jaw dropped in disbelief.
"I made the rowboat out of raw materials that I found on the island," continued the woman. "The oars were whittled from gum tree branches, I wove the bottom from palm fronds, and the sides and stern came from a Eucalyptus tree."
"But, but," stammered the man, "what about tools and hardware? How did you do that?"
"Oh, no problem," replied the woman, "on the south side of the island there is a very unusual strata of alluvial rock exposed. I found that If I fired it to a certain temperature in my kiln, it melted into forgeable ductile iron. I used that for tools, and used the tools to make the hardware.
"But, enough of that," she said. "Where do you live?"
At this man was forced to confess that he had been sleeping on the beach. "Well, let's row over to my place," she said. So they both got into the rowboat and left for her side of island.
The woman easily rowed them around to a wharf that led to the approach to her place. She tied up the rowboat with a beautifully woven hemp rope. They walked up a stone walk and around a palm tree, there stood an exquisite bungalow painted in blue and white. "It's not much," she said, "but I call it home. Sit down, please; would you like to have a drink?"
"No," said the man, "I just can't take any more coconut milk."
The woman laughed: "Don't worry, I have a still. How about a Pina Colada?" Trying to hide his continued amazement, the man accepted, and they sat down on her couch to talk.
After a while, they had exchanged their stories and the woman asked, "Tell me, have you always had a beard?"
"No," the man replied, "I was clean shaven all of my life, and even on the cruise ship".
"Well, if you would like to shave, there is a razor upstairs in the cabinet in the bathroom." So, the man, no longer questioning anything, went upstairs to the bathroom. There in the cabinet was a razor made from a bone handle, two shells honed to a hollow ground edge were fastened on to its end inside of a swivel mechanism. The man shaved, showered and went back down stairs.
"You look great," said the woman, "I think I will go up and slip into something more comfortable." So she did.
And, the man continued to sip his Pina Colada. After a short time, the woman returned wearing fig leafs strategically positioned and smelling faintly of gardenia.
"Tell me," she said, "we have both been out here for a very long time with no companionship. You know what I mean. Have you been lonely, is there anything that you really miss? Something that all men and woman need...?"
"Actually there is," the man replied, as he moved closer to the woman while fixing a winsome gaze upon her. "Tell me: do you happen to have an Internet connection?"
In Applied Cryptography, Schneier has a lovely explanation of why you can't brute force a 256 bit key. IIRC it comes down to there not being enough quantums (of time) between now and the end of the universe to check every possible key if every atom can perform on calculation per quantum. He also explains why its not physically feasable to brute force a 128 bit keyspace.
So what is comes down to is this: either you find a weakness in the algorithm, or work on quantum computing until it can brute force huge keyspaces outside the normal constraints of physics. Until then, 128 bits is enough (for symmetric crypto).
Actually reading the Meganet site is laughable. They attribute stolen credit card details to poor or broken cryptography (reality: this data isn't kept encrypted on the site host, because the security architecture of most sites sucks).
The algorithm they claim is uncrackable is based on a random "matrix", which is derived from a "file of any size that is available..." on both sending and receiving computers. So there IS secret data that must be transferred (or else that file is public, even worse). According to the code available here, the values aren't even vaguely random - just do lots of XORs using bits from your "secret file".
Meganet tries to justify its claims by pointing to multiple encryption. Big news guys: the size of the keyspace determines security, not the number of times you encrypt with the same key. At best multiple encryption makes it take longer to brute force the keyspace. It doesn't add security. Period.
Apart from that this matrix is used as a lookup table. That means that it has all of the problems of a one time pad, without the benefits. As soon as you use any block of values from the matrix again, you have information that you can use to attack the encryption.
It may be true that noone has broken this algorithm. I've written crypto algorithms that noone has broken... because I've never published them, and noone has had an interest in breaking them. That doesn't make them secure. Cryptographic security is achieved using simple algorithms that can be proven, using mathematical theory, not attested to by supposition and lame tests.
Which is no way keeps backwards compatibility: the syntax change in the for() construct means that you can't compile the source on older compilers, just as for foreach. I'm not the first poster to point this out.
Either syntax can be compiled to a byte code representation that is backwards compatible.
I am in awe of the new for() statement. Java was designed to be logical and readable, but unfortunately for (String s : c) means nothing to most developers.
The JCP is a classic case of committee design: everyone has their own ideas based on their experience, and doesn't really understand the purpose or path of the Java language. Most JCP suggestions are calls for Java to look more like C++ or Python.
And you're missing my point. I never said biometrics can't be subverted, I just said it was the typical answer. That's because it is more difficult to subvert than many other schemes. Quite frankly, if the government wants me, they'll get me, irrespective of the amount of data I think they do or don't have about me. But a proper ID system makes it a hell of a lot more difficult to common criminals to commit ID fraud against me.
A patent pending technology for electronic commerce that [uses a] "variable length key that is encrypted using blowfish algorithm then merged with the image of the stamp using another variable length password" with no peer review of the securtiy of the system? Users can "exhange stamps online and many users can use one internet stamp until it runs out of funds"? A sales site (interstamps.net) with no indication of parent company, physical address, telephone number? A completely anonomous system with a tracking serial number?
This sounds like the worst of horror stories that can be devices by Open Source and Privacy advocates combined, but we're singing its praises because it released some code under the GPL?
So apart from the many pointers that indicate that no self respecting online purchaser should hand over ANY details to this site, what about security and anonomity?
Sites you purchase from clearly can't track your identity across transactions (assuming you use a different stamp). Or can they?
Well, Centipaid or Internetstamps can certainly track all purchases you make, by virtue of the stamp's serial number. While they promise nicely in their Privacy Notice not to "materially change" their privacy policy, they reserve the right to. They also say they won't divulge "account contact or payment information", but that's easy to sidestep in a number of ways (is what your purchased and where you bought it "payment information"?).
Since Centipaid has close ties with the sellers (producer and consumers of the technology, right?), can we be sure that our purchasing trends aren't being syndicated to ALL of the sellers? Or maybe to Doubleclick or a similar organisation. All you're really doing in this system is trusting a third party to behave responsibly... one that doesn't even provide a physical address or indication of incorporation on their website. Ouch.
As for security, well, they're rather scant on details. A quick look over the PHP source code available from the site seems to indicate that you get redirected to a gateway under Centipaid's control - a standard mechanism for payments through Trusted Third Parties. But it would also seem (although I could be mistaken) that the communication between the merchant and Centipaid is not encrypted or authenticated (signed).
Without going into detail, any third party payment system that does not use a PKI and does not have secure communication between pair of parties can be attacked. In this case it is most likely that the merchant could be attacked. Nice for the purchaser, not so nice for the seller.
Besides this is the original claim that users can "exhange stamps online and many users can use one internet stamp until it runs out of funds". So this is really a debit facility (prepaid account) with a gimmick (a pretty picture... oooh, aaah!). Your stamp is no more or less secure than a credit card -- you just have a better ability to limit your losses.
No, I wouldn't trust the security of this system...
It may be interesting to take a read over this Internet draft, written by the guy who appears to own/run Centipaid. The paragraph entitled "Electronic postage support" is especially interesting, as is this notice: "Adonis El Fakih has a patent pending that may relate to AMDP internet draft specifically to the work derived from draft-amdp-00.txt", after which some reference is made to non-discriminatory terms.
Anyone who has solved a problem, or is at least working towards a solution, is in a position to instruct those who are still struggling, or are too blinded by their own arrogance to admit they have a problem.
If someone steals your ATM card and PIN, you get a new one
How? How do you identify yourself to the bank so that they issue you a new card and PIN?
Compare apples and apples. A bank card isn't a means of identification (in general), it is a system-specific identifier that is intended for use in conjunction with authentication (the PIN).
You are right that people have the wrong perception of biometrics -- often very wrong (confusing identification with authentication). I would not support any ID card that didn't have a picture, preferably a fingerprint, AND encoded biometric information. At the least it defeats the object of making the system easily usable -- you would need a machine.
The idea of an identity card is to identfy you, not to authenticate you. You produce the card to prove your claim to your identity; the accept checks the photo and whatever biometrics are required. Authenticating yourself is a different issue, and normally uses a singature (or PIN for electronic purposes). This separation needs to be maintained. If I don't sign a withdrawal slip for $10,000 but just stick my eye on a scanner, I don't know if the teller has withdrawn $20,000.
Gee, here's a bright kneejerk (slashjerk) response. "Identity theft is ridiculously easy even though there is no way to prove your identity". Fucking wonderful.
Why is identity theft not easy in my country? Because we have ID cards (well, books). You need one (by law) to open a bank account, perform transactions with government, and to vote. To get it reissued, you provide a fingerprint. Is it failsafe? No. Does it prevent someone from withdrawing money from my bank because they know my account number and can get my birth certificate from a public registry? Yes. Does it violate my right to privacy? Maybe.
The usual argument goes: if you aren't doing something illegal then there's nothing to worry about. And the counter is: and then they came for me, and there was noone left to speak out.
Well here's my response: when they came for me, "they" were not the police, were not the government, were not some shady quasi-legal state sanctioned organisation. "They" were your average criminals with guns, who give less of a shit about my rights than a civil servant. And the only reason there is any chance that "they" will get caught, is that every adult who wants to participate in the social structure of this country has their fingerprints in a national database.
Don't come with bullshit about fingerprints being useless. I've seen two groups of criminals tracked down before on fingerprints alone, and that's just from crimes that I've suffered. Fingerprints aren't perfect, no. You can't get a conviction based on fingerprints -- but they go to circumstantial evidence. But this is all besides the point.
Every day in the US millions of people produce some form of identification. A driver's license in the most common. But what is your proof of being a US citizen? A passport? Hell no, how do you prove your citizenship when you apply for one? Birth certificate? How does that in any way prove your claim to your identity? Quite simply, data corruption is possible when there is no normalisation. If you don't have an absolute identity list, identity theft is easy.
So what happens when you do have an absolute list? Well the trick is to have a system where you can prove your identity, but no-one else can prove they are you. Biometrics is the typical answer. It has unfortunately side effects - your identity can be discovered without your consent.
Well here's something new for the privacy advocates: in public you don't have privacy. Get it? You do not enjoy the right to privacy when you are in public. Should I rephrase this again? No? Good. The assumption that you CAN identify a person in public is essential to the maintainance of law and order.
So the real problem with ID cards is that they are seen as a first step in the erosion of rights. First you have a card, then you have to produce it, then you have to wear it all the time, then you will have it revoked if your are naughty, and finally it will be tatooed to your forhead and you get your head lopped off if you commit a crime. Bummer... and I always wanted a crime free society.
So come again, what's the problem? Someone may abuse it. Aah, yes. The State may abuse its power and abuse the identity system. Heaven forbid. They could go to war, repress an entire race group, raise taxes, collude with big business, detain us without trial and not tell anyone... but damnit don't let them know who we are.
So get real. Every country has some mechanism for identifying people. Commerce breaks down without it. Crime is unchecked without it. It may be a birth certificate, ID card, driver's license, known family member vouching for you. It doesn't matter - its a means of identification. ID cards simply provide a system which is more difficult to subvert than most. Often, because of the way they are applied, it is more harmful when that system IS subverted... that means we should improve the system, not go to an even more flawed alternative.
Your "MIS punks" make far better software engineers than cocky computer science geeks who don't understand or give a shit about risk management, or delivering the right product, on time, and in budget... which is what software engineering is about.
As with most other posters here, you think software engineering is leet programming skillz. Wake up. It is a serious business discipline that is responsible for the production of quality software.
Quality means what the user wants, in time, on budget, and reliable and maintainable. This means using processes, methodologies and best practices. Rigerous design, clear documentation, source control, configuration management... these are the concerns of a software engineer.
Compiler design, physics, calculus? Specialist knowledge that may be required on certain projects. If so, hire a specialist. Engineering is an applied science. Did you get that? Repeat after me: Engineering is an applied science.
If you need to design algorithms, improve the effectiveness of a compiler, model the universe... get someone with a theoretical degree. That's what computer science is: a theoretical degree. You study THEORY; the only reason you do programming is so that you can get some application of that theory. Maths, physics, computer science; they all have practical application, but a graduate of one of these subjects is skilled in theory, not practice.
Engineers apply the theory developed by theorists. They need a working knowledge of the theory, not a knowledge of deriving the theory. In projects that include system reverse engineering, SCADA/MES, cryptography and high availability services, I have yet to see any engineer or developer in my teams need knowledge of ANY of the areas of theory you have mentioned. They simply aren't important to the discipline that is Software Engineering.
This is what we in the trade call a "designer". In many other trades (s)he would be called a "drafter". And engineer has many other responsibilities, most of which are related to management.
An engineer has to ensure that the project is technically sound, but also that it meets the requirements - that means time and budget as well. (S)he needs to be able to communicate effectively with customers, management and programmers in order to see this done. Quality comes through discipline, not random change, which means that knowing about and adhering to best practices are a huge part of an engineer's job.
Finally a poster who knows that he is talking about!
The hurdle now for SE is to establish itself as a respected profession, where Software Engineers can (and do) stand up to business managers and explain that software is not quick, or easy, or simple to fix.
This involves a change in mindset of managers, software engineers, developers, and consumers. The customer is used to paying more to get less, especially in this industry. Managers are used to making unrealistic promises. Until there are a bunch of engineers in the middle with their reputations and professional recognition on the line... its not going to improve.
There are more than 50 formal methodologies for software development. Your knowledge is clearly limited to development in the narrowest sense (programming), which is the area to which design patterns applies. According to most formal models, getting down and programming should consume somewhere between 20-30% of project time, and that's excluding maintenance time!
SE no more reinvents the wheel than civil engineering does. Ever see two identical bridges? I haven't. They are different widths, different lengths, have different aestetics. But there are a few basic design principles, methods for calculating loads and tolerances and choosing materials, and techniques for putting the bridge in its place.
In software we have blocks of reusable code (components), techniques to combine them (APIs), provable methods for handling classes of processing and storage problems (algorithms and normalised database structures).
The biggest factor that causes the wheel to be reinvented time and time again in software development is ego. Most developers simple can't handle using someone elses code. The second biggest factor is a lack of documentation; which illustrates beautifully how so few "software engineers" actually know anything about the field they claim to be experts in; the third factor is cost, because it takes a SE to explain to a business manager what a programmer won't: buying a third party component for $200 reduces risk and costs less - even in the short term - than assigning a single develop to it for three days.
The software development world is full of hacks, information systems graduates and cocky comp. sci grads who like to think they can call themselves software engineers. If everyone who could pick up a soldering iron called themselves an electronic engineer, I'd also get the wrong impression.
Fortunately there is a REAL discipline called Software Engineering, with REAL processes and time-proven methods for delivering software, as required by the user, on time and on budget. See the Software Engineering Body of Knowledge for more information.
Although it sounds counter-intuitive, what management did is not strictly wrong. It just sounds like the managed it incorrectly. Contemprary constraint theory (I found a brief explaination) suggests that subordinating all processes to the speed of the bottleneck is the best way to improve throughput.
This is very difficult to do in a software development organisation, which is one of the most ego-driven working environments.
In my experience the only way to handle this effectively is to get your best developers/engineers to devote their time to mentoring and prototyping the next phase once they have finished their current deliverables. It is also useful to encourage them to learn new technologies and practices, especially best practices like configuration management.
Sadly most managers don't like this... it seems like a waste of time. Throw away code (prototypes) never go down well, and learning is often something that employees "should do on [their] own time".
This is why it is essential that Software Engineers have management and communication skills, not only downwards, but upwards as well. Managing the knowledge and expectations of business managers is critical in the success of a project -- and of a company!
I prefer: "Applied Software Engineering is a project-related discipline which employs systematic and quantifiable processes and techniques for creating cost-effective solutions to practical problems, with the purpose of optimising the development, delivery and maintenance of software which is reliable and meets user expectations when operating in the real world."
To begin with, I am shocked that only one poster so far has mentioned the SWEBOK. This is the codex for anyone who wants to call themselves a Software Engineer, and in time will become the foundation of an international standard for SE skills.
It is important to realise that the goal of SE is not repeatable and predictable development. It is the creation of quality software (inherent in that meeting user, reliability and maintainability requirements), on time and on budget.
Achieving this goal has (at least) two aspects: a disciplined approach based on sound theory, and managing risk. Together these equate to reliability and predictability (both influencing and being influenced by discipline and risk management), making these a means to an end.
Unfortunately too many engineers lose sight of the real goal and instead target the means to achieve that goal. A perfectly predictable, perfectly reliable project is a failure if it can't delivery what the customer wants, on time and on budget.
So what is SE really? The SWEBOK answers the adequately. It identifies the areas of expertise in which a Software Engineer must be profficient:
Managing resources (budget, time, people / expertise)
Understanding user requirements
Designing a solution using Best Practices
Have the technical knowledge to evaluate possible technologies for the solution
Have technical knowledge of design and implementation principles (algorithms, data structures, methodologies, patterns)
Introducing predictability and risk management into the development process (software process management)
Implementing the solution, or overseeing the implementation
Communicating
Management (including risk management, project management and Best Practices) is a more important skill for an engineer than development.
Why is everyone concentrating on the key length? The method in which they are using DES here is far more relevant.
If you take an entire hard drive and encrypt it sector by sector under a DES key, you've got a problem. There's plenty of plaintext and matching ciphertext available by virtue of known disk structures, and the possibility of constructing a birthday attack is high. Worse, there are parallel attack mechanisms that allow
you to break such a scheme in 2^40 tries instead of 2^56. That's under a day for someone with serious money.
But most HDD encryption schemes don't work like that. At work you use a key variant for every sector -- xor the sector number onto the key, so that you effectively have a different key per sector. This helps to reduce the effectiveness of some attacks (e.g. the parallal attack), but suffers a critical problem: break the key for one sector, and you've got the drive.
A far more secure scheme involves key derivatives: encrypt the sector number with the key to find a derived key, then encrypt the sector with that key. Breaking a single sector still doesn't break the master key. This mostly limits you to a known plaintext attach, and raises the complexity to 2^57 (you have to break two keys, the second being the one you want).
Other schemes include the use of multiple keys over a disk, so that breaking a single key only compromises and area (say 1/4) of the disk.
As for the security of DES; it hasn't been cracked. There are some ways to reduce its strength in particular circumstances (see above), but not generally.
Like it or not the banking world still uses DES (yes, 56 bit keys) and will continue to do so for some time to come. Check out the ANSI financial services standards (which govern interbank electronic standards, like ATM networks). Is this a problem? Not really. Intelligent use of protocols ensures that cracking the key is a waste of time because at best you can recover a single PIN... which is more easily brute forced at 10^5 than a DES key at 2^56.
I don't think it quite went down like that, but it's certainly possible. I have found no indication of Ameritech or the authors encouraging the adoption of the guidelines, per se, but clearly other people in the field at the time felt the guidelines were good.
Also remember that Ameritech has never attempted to enforce the patent. After being acquired by SBC, the latter decided it could capatalize on the patent.
This is the best comment I've seen so far, but it doesn't really prove prior art. The page you refer to is dated 1999. As with many innovations, the presence of an enabling mechanism does not necessarily indicate prior art.
Can you prove that frames were intended for use as contemplated by the patent, i.e. a consistent user interface across a document or site? Not from that article. Remember too that not only frames are at issue here -- a navigation bar using tables or divisions would appear to be covered by the patent as well.
While it is blatently obvious with hindsight that frames can be used in this manner, some Googling around will show that a huge amount of web design material at the time references a document called "Ameritech Web Page User Interface Standards and Design Guidelines" by
Detweiler, M.C. and Omanson, R.C. (1996), on the matter of creating a consistent user interface by using frames. If that doesn't ring a bell, Ameritech was the original holder of the patent, and recently acquired by SBC.
Reading the patent provides some more insight too: they contemplate a document with embedded codes indicating document sections, that conforms to a predefined structure. Read this way, the patent does not partain to HMTL frames, because HTML is a hypertext linked collection of documents, not a single document. A navbar or frame moving the view to named references within a single document, however, would clearly violate the patent.
So is the patent valid? Well, that involves proving prior art; not just that frames existed, but that they were used for the purpose of navigation, both in a single document and between documents. Any evidence of tables to do the same thing would also be useful. Also crutial is having an incontestible source -- printed information is best, a reputable online news source or journal is the next best thing.
The Netscape Navigator 2.0 announcement contains "Frames, a new page presentation capability that enables the display of multiple, independently scrollable panels on a single screen, each with its own distinct Internet address. They also enable a region of the screen to be frozen in place as the user scrolls through information on a page". Tantalising, but it doesn't mention using the frozen region for navigation.
Most promising are the Mozilla 2.0 release notes. Two of the example links are broken, while third doesn't work in my browser, although the pages appear to be there. It clearly demonstrates the use of a navigation frame to select different pages in a site, and view them in a "dynamic" frame. That said, the navigation frame itself is not entirely static (it scrolls, but does not change), and there is no navigation inside a single document from the frame.
There is a lot of effort required to find proper evidence of prior art that will hold up in court. The Wayback Machine would provide great evidence, if only we can find it.
This is completely laughable. Since its first release (as an add-on package, not even part of the JDK) Swing has been one of the most mature and best designed GUI toolkits available. The only three allegations which can be justifiably levelled against Swing are:
Swing has historically had performance problems, and these have not been entirely addressed;
Swing was difficult to develop by virtue of not having GUI builders (but no more difficult than most other non-script toolkits without builders);
Swing presents a GUI model slightly more complex than is typical, and many developers dive in without understand it (this is especially true for X-Windows developers who have less experience with threads and the concept of a separate thread dedicated to the GUI.
Most developers who complain about the difficulty of using Swing are simply missing the point. I have had developers argue for hours about how terrible the table/tree components are, because you have to do "all that useless shit with models", and you can't just say "table.setCellAt(x, y, value)". Similarly there are a dearth of developers (especially those from the MS Windows world) who understand the need for layout components, as opposed to using absolute dimensions and coordinates.
For anyone who disses Swing, make sure you've read the Java Look and Feel Design Guidelines. Better than a Swing manual or introduction, it investigates building real-world applications with Swing, focusing on user experience and usability.
Swing's support for consistent navigation; centralised control over colours, widget L&F and localization; as well as its powerful and extensible widget set (e.g. TreeTables and the SwingSet2 demo) put it years ahead of most other toolkits, even now. Java's native L&F has improved over the years, to the extent that (for win32 at least) you can create Java apps that look native.
But Swing is not a silver bullet. With any cross platform toolkit you will run into problems. Qt, GTk, and Wx all have issues that need to be resolved when porting the app using them to a new platform. Similarly there is some effort to ensure that your Java/Swing application looks and behaves consistently on all its target platforms. In my experience Swing is far more portable than other toolkits, with the possibly exception of Tk. If performance is paramount in your application, then Swing is not for you; but this certainly doesn't make it unsuitable for an average business application.
Why is it that Slashdotters always focus on the duration of Copyright as a whole? Could it be that what they really want is free content, and don't really care about the public domain?
The public domain is NOT greatly enriched by a particular work being available in the public domain. The public domain IS greatly enriched by allowing creators to build on the works of others.
The Star Wars saga is a good example. This is a brilliant series of movies, and the many people and organisations involved deserve to reap the benefits for the creativity, effort and risk they invested. How long should these movies remain under Copyright? They are still popular now, contributing to the economy. That means that hundreds of people are still benefitting from that Copyright. This could still be the case in 100 years... at what point do we stop this economic benefit and say it is in the public interest to make this content free?
The better response is not to answer that question, but to propose an alternative. The is a huge amount of fan fiction surrounding Star Wars, much of it illegal. ONE creation ("A New Hope") sparked off a huge amount of derivative creation, only a tiny amount of which was sanctioned. This is where Copyright really hurts the public domain. Not only does Copyright keep us paying for Star Wars the movie for another 50 years, but it prevents fan fiction from extending and enriching the original idea.
Some degree of control over derivatives is, of course, justified. A creator needs some time in which to produce a derivative of his/her own, in order to best benefit from Copyright. In addition, bad derivatives can harm the popular perception of the original, and thereby harm the creator of the original. On the other hand, good derivatives can drive up the popularity of the original.
So I propose that we stop caring so much about the duration of Copyright as a whole, or Copyright on a particular work, and start caring about the duration of monopoly over derivative works. This way we can see the avalanche effect of one creation leading to many derivatives which enrich society, while still allowing the original creator to benefit.
Couple with this a use-it-or-lose-it rule, where a work, once published, cannot be withdrawn or withheld (it must be available for sale), and we have a situation where ALL work is available (although you will still have to pay for the "original" that started it all for some time), and concepts and ideas are built on far more readily.
There seem to be three sides to the IP debate: big corporations representing huge IP interests, vocal activists representing themselves in the name of the common good, and the man in the street who doesn't really care.
Corporate interest, unfortunately, is focused on complete control. The activists tend to focus on maintaining the status quo as it was a decade ago, or on the abolition of IP rights. And the man in the street still doesn't care, because he still wants the content, and doesn't care about the public domain as it will exist after he is dead.
And everyone is missing the point. Protecting a work for 14 years, 50 years, 70 years or 100 years doesn't damage the public domain much, if at all. This is also within range of the time during which the creator can benefit from the work. Placing arbitrary time limits on the rights a creator enjoys will always be a difficult subject: some works will never do well, others are popular for many decades, and yet others are "ahead of their time" and may only realise their value decades after they are created.
What damages the public domain is the growth of Copyright to cover derivative works, and the right to withhold licensing after first publication. Preventing derivatives is the most destructive, preventing creators from building on the work of others. Withholding licensing means that a work can be published initially, then withdrawn (usually because it is not profitable) and never seen for the next 70+ years.
If we adjust Copyright law to allow the creation of derivative works after a short time (say 5 years), and force a use-it-or-lose-it scenario (where creators are forced to license published works no longer under publication to third parties on reasonable terms), we can claim back a lot of the benefit that Copyright offers to the public domain, without completely trampling over the rights of creators to the specific content that they created.
Is it just me, or did you completely lose the point of my comment?
Usenet exists in a hierarchy, and there are rules for adding groups (forums). There is no support for user accounts or for collaborative filtering ("moderation" as found on Slashdot). Posts are stored on a central server, and worse are lost over time; as opposed to being published by their author onto private "forum space" where (s)he can claim copyright and take responsibilitity, addressing the legal issues involved.
No matter how low the single to noise ratio can get on Slashdot, it doesn't come close to usenet.
Slashdot Mirror
Precedent has it that acquiring.evil.mega.corp rewrites the data retention / privacy policy to allow them to do as they please, irrespective of any clauses, promises or contractual arrangement to the contrary.
Almost all such policies have at least some leeway for the site to make (minor) modifications (otherwise even correcting a typo would, theoretically, change the contract); so mega.corp simply argues that its new policy is a permissable change. Then it leaves it to the users it has pissed on/off to bring a class action against them, which it will drag on in court for years, and maybe eventually (albeit unlikely) pay some damages ... way after the damage to you has been done.
The short of it is: you can't trust ANY company or person with private information. All you can do is weigh the risk, and decide how much you think you can get back (in damages) if (when) they abuse it.
Keeping your head inside a bag will certainly damage most projects - but this is often a question of the level of development in question.
Software engineering covers everything from requirements down to coding. You can't perform SE in a black box. Too often software development is performed in a business black box: there is no proper interaction with customers to really learn their requirements, what other systems to integrate with, etc. At the opposite end of the spectrum, coding CAN be performed in a black box.
You see, by the time you've established requirements; architectured, designed and exercised the system; and cast your APIs in store; you no longer need to consider what goes on outside your black box.
In reality, this is a dangerous practice. Very few development teams are mature enough to thoroughly design an API that doesn't have side-effects, or even to correctly identify the boundaries of a "black box". So most of the time everyone has to be aware of what's going on around them.
The trick is handling side effects. Modular development says that you don't make account (in your black box) for problems in another box -- unless there is no way to correct that problem (legacy compatibility, operating platform, etc). And when you do make such a fix, you lose a significant amount of modularity for that component.
An engineer was enjoying a cruise in the Caribbean. It was wonderful, the experience of his life ... but, it did not last. A Hurricane came up unexpectedly and the ship went down, giving only a few barely enough time to escape.
... and there from around the corner of the island came a rowboat. In it was the most gorgeous woman he had ever seen: she was tall, tanned, with blond hair flowing in the sea breeze. She spotted him waving and yelling, and rowed her boat towards him.
The man found himself swept up on the shore of an island. There was nothing else anywhere to be seen. No person, no supplies, nothing. Looking around he saw some bananas and coconuts, but that was it. He was desperate, and forlorn, but decided to make the best of it.
So for the next four months he ate bananas, drank coconut milk and stared out to sea waiting for a ship to come to his rescue.
One day, as he was lying on the beach waiting dejectecly for a while, he spotted movement out just beyond the waves
In disbelief, he asked, "Where did you come from, how did you get here?"
She said, "I rowed from the other side of the island. I landed on this island when my cruise ship sank."
"Amazing," he said, "I didn't know anyone else had survived. How many of you are there? Where, did you get the rowboat? You must have been really lucky to have a rowboat wash-up with you?"
"It is only me," she said, "and the rowboat didn't wash up, I made it."
The engineer's jaw dropped in disbelief.
"I made the rowboat out of raw materials that I found on the island," continued the woman. "The oars were whittled from gum tree branches, I wove the bottom from palm fronds, and the sides and stern came from a Eucalyptus tree."
"But, but," stammered the man, "what about tools and hardware? How did you do that?"
"Oh, no problem," replied the woman, "on the south side of the island there is a very unusual strata of alluvial rock exposed. I found that If I fired it to a certain temperature in my kiln, it melted into forgeable ductile iron. I used that for tools, and used the tools to make the hardware.
"But, enough of that," she said. "Where do you live?"
At this man was forced to confess that he had been sleeping on the beach. "Well, let's row over to my place," she said. So they both got into the rowboat and left for her side of island.
The woman easily rowed them around to a wharf that led to the approach to her place. She tied up the rowboat with a beautifully woven hemp rope. They walked up a stone walk and around a palm tree, there stood an exquisite bungalow painted in blue and white. "It's not much," she said, "but I call it home. Sit down, please; would you like to have a drink?"
"No," said the man, "I just can't take any more coconut milk."
The woman laughed: "Don't worry, I have a still. How about a Pina Colada?" Trying to hide his continued amazement, the man accepted, and they sat down on her couch to talk.
After a while, they had exchanged their stories and the woman asked, "Tell me, have you always had a beard?"
"No," the man replied, "I was clean shaven all of my life, and even on the cruise ship".
"Well, if you would like to shave, there is a razor upstairs in the cabinet in the bathroom." So, the man, no longer questioning anything, went upstairs to the bathroom. There in the cabinet was a razor made from a bone handle, two shells honed to a hollow ground edge were fastened on to its end inside of a swivel mechanism. The man shaved, showered and went back down stairs.
"You look great," said the woman, "I think I will go up and slip into something more comfortable." So she did.
And, the man continued to sip his Pina Colada. After a short time, the woman returned wearing fig leafs strategically positioned and smelling faintly of gardenia.
"Tell me," she said, "we have both been out here for a very long time with no companionship. You know what I mean. Have you been lonely, is there anything that you really miss? Something that all men and woman need...?"
"Actually there is," the man replied, as he moved closer to the woman while fixing a winsome gaze upon her. "Tell me: do you happen to have an Internet connection?"
In Applied Cryptography, Schneier has a lovely explanation of why you can't brute force a 256 bit key. IIRC it comes down to there not being enough quantums (of time) between now and the end of the universe to check every possible key if every atom can perform on calculation per quantum. He also explains why its not physically feasable to brute force a 128 bit keyspace.
So what is comes down to is this: either you find a weakness in the algorithm, or work on quantum computing until it can brute force huge keyspaces outside the normal constraints of physics. Until then, 128 bits is enough (for symmetric crypto).
Actually reading the Meganet site is laughable. They attribute stolen credit card details to poor or broken cryptography (reality: this data isn't kept encrypted on the site host, because the security architecture of most sites sucks).
The algorithm they claim is uncrackable is based on a random "matrix", which is derived from a "file of any size that is available ..." on both sending and receiving computers. So there IS secret data that must be transferred (or else that file is public, even worse). According to the code available here, the values aren't even vaguely random - just do lots of XORs using bits from your "secret file".
Meganet tries to justify its claims by pointing to multiple encryption. Big news guys: the size of the keyspace determines security, not the number of times you encrypt with the same key. At best multiple encryption makes it take longer to brute force the keyspace. It doesn't add security. Period.
Apart from that this matrix is used as a lookup table. That means that it has all of the problems of a one time pad, without the benefits. As soon as you use any block of values from the matrix again, you have information that you can use to attack the encryption.
It may be true that noone has broken this algorithm. I've written crypto algorithms that noone has broken ... because I've never published them, and noone has had an interest in breaking them. That doesn't make them secure. Cryptographic security is achieved using simple algorithms that can be proven, using mathematical theory, not attested to by supposition and lame tests.
Which is no way keeps backwards compatibility: the syntax change in the for() construct means that you can't compile the source on older compilers, just as for foreach. I'm not the first poster to point this out.
Either syntax can be compiled to a byte code representation that is backwards compatible.
I am in awe of the new for() statement. Java was designed to be logical and readable, but unfortunately for (String s : c) means nothing to most developers.
The JCP is a classic case of committee design: everyone has their own ideas based on their experience, and doesn't really understand the purpose or path of the Java language. Most JCP suggestions are calls for Java to look more like C++ or Python.
And you're missing my point. I never said biometrics can't be subverted, I just said it was the typical answer. That's because it is more difficult to subvert than many other schemes. Quite frankly, if the government wants me, they'll get me, irrespective of the amount of data I think they do or don't have about me. But a proper ID system makes it a hell of a lot more difficult to common criminals to commit ID fraud against me.
A patent pending technology for electronic commerce that [uses a] "variable length key that is encrypted using blowfish algorithm then merged with the image of the stamp using another variable length password" with no peer review of the securtiy of the system? Users can "exhange stamps online and many users can use one internet stamp until it runs out of funds"? A sales site (interstamps.net) with no indication of parent company, physical address, telephone number? A completely anonomous system with a tracking serial number?
This sounds like the worst of horror stories that can be devices by Open Source and Privacy advocates combined, but we're singing its praises because it released some code under the GPL?
So apart from the many pointers that indicate that no self respecting online purchaser should hand over ANY details to this site, what about security and anonomity?
Sites you purchase from clearly can't track your identity across transactions (assuming you use a different stamp). Or can they?
Well, Centipaid or Internetstamps can certainly track all purchases you make, by virtue of the stamp's serial number. While they promise nicely in their Privacy Notice not to "materially change" their privacy policy, they reserve the right to. They also say they won't divulge "account contact or payment information", but that's easy to sidestep in a number of ways (is what your purchased and where you bought it "payment information"?).
Since Centipaid has close ties with the sellers (producer and consumers of the technology, right?), can we be sure that our purchasing trends aren't being syndicated to ALL of the sellers? Or maybe to Doubleclick or a similar organisation. All you're really doing in this system is trusting a third party to behave responsibly ... one that doesn't even provide a physical address or indication of incorporation on their website. Ouch.
As for security, well, they're rather scant on details. A quick look over the PHP source code available from the site seems to indicate that you get redirected to a gateway under Centipaid's control - a standard mechanism for payments through Trusted Third Parties. But it would also seem (although I could be mistaken) that the communication between the merchant and Centipaid is not encrypted or authenticated (signed).
Without going into detail, any third party payment system that does not use a PKI and does not have secure communication between pair of parties can be attacked. In this case it is most likely that the merchant could be attacked. Nice for the purchaser, not so nice for the seller.
Besides this is the original claim that users can "exhange stamps online and many users can use one internet stamp until it runs out of funds". So this is really a debit facility (prepaid account) with a gimmick (a pretty picture ... oooh, aaah!). Your stamp is no more or less secure than a credit card -- you just have a better ability to limit your losses.
No, I wouldn't trust the security of this system...
It may be interesting to take a read over this Internet draft, written by the guy who appears to own/run Centipaid. The paragraph entitled "Electronic postage support" is especially interesting, as is this notice: "Adonis El Fakih has a patent pending that may relate to AMDP internet draft specifically to the work derived from draft-amdp-00.txt", after which some reference is made to non-discriminatory terms.
I'll let you draw your own conclusions...
Anyone who has solved a problem, or is at least working towards a solution, is in a position to instruct those who are still struggling, or are too blinded by their own arrogance to admit they have a problem.
How? How do you identify yourself to the bank so that they issue you a new card and PIN?
Compare apples and apples. A bank card isn't a means of identification (in general), it is a system-specific identifier that is intended for use in conjunction with authentication (the PIN).
You are right that people have the wrong perception of biometrics -- often very wrong (confusing identification with authentication). I would not support any ID card that didn't have a picture, preferably a fingerprint, AND encoded biometric information. At the least it defeats the object of making the system easily usable -- you would need a machine.
The idea of an identity card is to identfy you, not to authenticate you. You produce the card to prove your claim to your identity; the accept checks the photo and whatever biometrics are required. Authenticating yourself is a different issue, and normally uses a singature (or PIN for electronic purposes). This separation needs to be maintained. If I don't sign a withdrawal slip for $10,000 but just stick my eye on a scanner, I don't know if the teller has withdrawn $20,000.
Gee, here's a bright kneejerk (slashjerk) response. "Identity theft is ridiculously easy even though there is no way to prove your identity". Fucking wonderful.
Why is identity theft not easy in my country? Because we have ID cards (well, books). You need one (by law) to open a bank account, perform transactions with government, and to vote. To get it reissued, you provide a fingerprint. Is it failsafe? No. Does it prevent someone from withdrawing money from my bank because they know my account number and can get my birth certificate from a public registry? Yes. Does it violate my right to privacy? Maybe.
The usual argument goes: if you aren't doing something illegal then there's nothing to worry about. And the counter is: and then they came for me, and there was noone left to speak out.
Well here's my response: when they came for me, "they" were not the police, were not the government, were not some shady quasi-legal state sanctioned organisation. "They" were your average criminals with guns, who give less of a shit about my rights than a civil servant. And the only reason there is any chance that "they" will get caught, is that every adult who wants to participate in the social structure of this country has their fingerprints in a national database.
Don't come with bullshit about fingerprints being useless. I've seen two groups of criminals tracked down before on fingerprints alone, and that's just from crimes that I've suffered. Fingerprints aren't perfect, no. You can't get a conviction based on fingerprints -- but they go to circumstantial evidence. But this is all besides the point.
Every day in the US millions of people produce some form of identification. A driver's license in the most common. But what is your proof of being a US citizen? A passport? Hell no, how do you prove your citizenship when you apply for one? Birth certificate? How does that in any way prove your claim to your identity? Quite simply, data corruption is possible when there is no normalisation. If you don't have an absolute identity list, identity theft is easy.
So what happens when you do have an absolute list? Well the trick is to have a system where you can prove your identity, but no-one else can prove they are you. Biometrics is the typical answer. It has unfortunately side effects - your identity can be discovered without your consent.
Well here's something new for the privacy advocates: in public you don't have privacy. Get it? You do not enjoy the right to privacy when you are in public. Should I rephrase this again? No? Good. The assumption that you CAN identify a person in public is essential to the maintainance of law and order.
So the real problem with ID cards is that they are seen as a first step in the erosion of rights. First you have a card, then you have to produce it, then you have to wear it all the time, then you will have it revoked if your are naughty, and finally it will be tatooed to your forhead and you get your head lopped off if you commit a crime. Bummer ... and I always wanted a crime free society.
So come again, what's the problem? Someone may abuse it. Aah, yes. The State may abuse its power and abuse the identity system. Heaven forbid. They could go to war, repress an entire race group, raise taxes, collude with big business, detain us without trial and not tell anyone ... but damnit don't let them know who we are.
So get real. Every country has some mechanism for identifying people. Commerce breaks down without it. Crime is unchecked without it. It may be a birth certificate, ID card, driver's license, known family member vouching for you. It doesn't matter - its a means of identification. ID cards simply provide a system which is more difficult to subvert than most. Often, because of the way they are applied, it is more harmful when that system IS subverted ... that means we should improve the system, not go to an even more flawed alternative.
Your "MIS punks" make far better software engineers than cocky computer science geeks who don't understand or give a shit about risk management, or delivering the right product, on time, and in budget ... which is what software engineering is about.
As with most other posters here, you think software engineering is leet programming skillz. Wake up. It is a serious business discipline that is responsible for the production of quality software.
Quality means what the user wants, in time, on budget, and reliable and maintainable. This means using processes, methodologies and best practices. Rigerous design, clear documentation, source control, configuration management ... these are the concerns of a software engineer.
Compiler design, physics, calculus? Specialist knowledge that may be required on certain projects. If so, hire a specialist. Engineering is an applied science. Did you get that? Repeat after me: Engineering is an applied science.
If you need to design algorithms, improve the effectiveness of a compiler, model the universe ... get someone with a theoretical degree. That's what computer science is: a theoretical degree. You study THEORY; the only reason you do programming is so that you can get some application of that theory. Maths, physics, computer science; they all have practical application, but a graduate of one of these subjects is skilled in theory, not practice.
Engineers apply the theory developed by theorists. They need a working knowledge of the theory, not a knowledge of deriving the theory. In projects that include system reverse engineering, SCADA/MES, cryptography and high availability services, I have yet to see any engineer or developer in my teams need knowledge of ANY of the areas of theory you have mentioned. They simply aren't important to the discipline that is Software Engineering.
This is what we in the trade call a "designer". In many other trades (s)he would be called a "drafter". And engineer has many other responsibilities, most of which are related to management.
An engineer has to ensure that the project is technically sound, but also that it meets the requirements - that means time and budget as well. (S)he needs to be able to communicate effectively with customers, management and programmers in order to see this done. Quality comes through discipline, not random change, which means that knowing about and adhering to best practices are a huge part of an engineer's job.
Finally a poster who knows that he is talking about!
The hurdle now for SE is to establish itself as a respected profession, where Software Engineers can (and do) stand up to business managers and explain that software is not quick, or easy, or simple to fix.
This involves a change in mindset of managers, software engineers, developers, and consumers. The customer is used to paying more to get less, especially in this industry. Managers are used to making unrealistic promises. Until there are a bunch of engineers in the middle with their reputations and professional recognition on the line ... its not going to improve.
There are more than 50 formal methodologies for software development. Your knowledge is clearly limited to development in the narrowest sense (programming), which is the area to which design patterns applies. According to most formal models, getting down and programming should consume somewhere between 20-30% of project time, and that's excluding maintenance time!
SE no more reinvents the wheel than civil engineering does. Ever see two identical bridges? I haven't. They are different widths, different lengths, have different aestetics. But there are a few basic design principles, methods for calculating loads and tolerances and choosing materials, and techniques for putting the bridge in its place.
In software we have blocks of reusable code (components), techniques to combine them (APIs), provable methods for handling classes of processing and storage problems (algorithms and normalised database structures).
The biggest factor that causes the wheel to be reinvented time and time again in software development is ego. Most developers simple can't handle using someone elses code. The second biggest factor is a lack of documentation; which illustrates beautifully how so few "software engineers" actually know anything about the field they claim to be experts in; the third factor is cost, because it takes a SE to explain to a business manager what a programmer won't: buying a third party component for $200 reduces risk and costs less - even in the short term - than assigning a single develop to it for three days.
The software development world is full of hacks, information systems graduates and cocky comp. sci grads who like to think they can call themselves software engineers. If everyone who could pick up a soldering iron called themselves an electronic engineer, I'd also get the wrong impression.
Fortunately there is a REAL discipline called Software Engineering, with REAL processes and time-proven methods for delivering software, as required by the user, on time and on budget. See the Software Engineering Body of Knowledge for more information.
Although it sounds counter-intuitive, what management did is not strictly wrong. It just sounds like the managed it incorrectly. Contemprary constraint theory (I found a brief explaination) suggests that subordinating all processes to the speed of the bottleneck is the best way to improve throughput.
This is very difficult to do in a software development organisation, which is one of the most ego-driven working environments.
In my experience the only way to handle this effectively is to get your best developers/engineers to devote their time to mentoring and prototyping the next phase once they have finished their current deliverables. It is also useful to encourage them to learn new technologies and practices, especially best practices like configuration management.
Sadly most managers don't like this ... it seems like a waste of time. Throw away code (prototypes) never go down well, and learning is often something that employees "should do on [their] own time".
This is why it is essential that Software Engineers have management and communication skills, not only downwards, but upwards as well. Managing the knowledge and expectations of business managers is critical in the success of a project -- and of a company!
Please read the Software Engineering Body of Knowledge and stop calling yourself a Software Engineer.
I prefer: "Applied Software Engineering is a project-related discipline which employs systematic and quantifiable processes and techniques for creating cost-effective solutions to practical problems, with the purpose of optimising the development, delivery and maintenance of software which is reliable and meets user expectations when operating in the real world."
This is a synthesis of definitions from professional SE groups and organisations around the world, including the Software Engineering Institute at CMU and the Software Engineering Body of Knowledge (SWEBOK), that embodies the goals, responsibilities and practices of SE.
To begin with, I am shocked that only one poster so far has mentioned the SWEBOK. This is the codex for anyone who wants to call themselves a Software Engineer, and in time will become the foundation of an international standard for SE skills.
It is important to realise that the goal of SE is not repeatable and predictable development. It is the creation of quality software (inherent in that meeting user, reliability and maintainability requirements), on time and on budget.
Achieving this goal has (at least) two aspects: a disciplined approach based on sound theory, and managing risk. Together these equate to reliability and predictability (both influencing and being influenced by discipline and risk management), making these a means to an end.
Unfortunately too many engineers lose sight of the real goal and instead target the means to achieve that goal. A perfectly predictable, perfectly reliable project is a failure if it can't delivery what the customer wants, on time and on budget.
So what is SE really? The SWEBOK answers the adequately. It identifies the areas of expertise in which a Software Engineer must be profficient:
Management (including risk management, project management and Best Practices) is a more important skill for an engineer than development.
Why is everyone concentrating on the key length? The method in which they are using DES here is far more relevant.
If you take an entire hard drive and encrypt it sector by sector under a DES key, you've got a problem. There's plenty of plaintext and matching ciphertext available by virtue of known disk structures, and the possibility of constructing a birthday attack is high. Worse, there are parallel attack mechanisms that allow you to break such a scheme in 2^40 tries instead of 2^56. That's under a day for someone with serious money.
But most HDD encryption schemes don't work like that. At work you use a key variant for every sector -- xor the sector number onto the key, so that you effectively have a different key per sector. This helps to reduce the effectiveness of some attacks (e.g. the parallal attack), but suffers a critical problem: break the key for one sector, and you've got the drive.
A far more secure scheme involves key derivatives: encrypt the sector number with the key to find a derived key, then encrypt the sector with that key. Breaking a single sector still doesn't break the master key. This mostly limits you to a known plaintext attach, and raises the complexity to 2^57 (you have to break two keys, the second being the one you want).
Other schemes include the use of multiple keys over a disk, so that breaking a single key only compromises and area (say 1/4) of the disk.
As for the security of DES; it hasn't been cracked. There are some ways to reduce its strength in particular circumstances (see above), but not generally.
Like it or not the banking world still uses DES (yes, 56 bit keys) and will continue to do so for some time to come. Check out the ANSI financial services standards (which govern interbank electronic standards, like ATM networks). Is this a problem? Not really. Intelligent use of protocols ensures that cracking the key is a waste of time because at best you can recover a single PIN ... which is more easily brute forced at 10^5 than a DES key at 2^56.
I don't think it quite went down like that, but it's certainly possible. I have found no indication of Ameritech or the authors encouraging the adoption of the guidelines, per se, but clearly other people in the field at the time felt the guidelines were good.
Also remember that Ameritech has never attempted to enforce the patent. After being acquired by SBC, the latter decided it could capatalize on the patent.
This is the best comment I've seen so far, but it doesn't really prove prior art. The page you refer to is dated 1999. As with many innovations, the presence of an enabling mechanism does not necessarily indicate prior art.
Can you prove that frames were intended for use as contemplated by the patent, i.e. a consistent user interface across a document or site? Not from that article. Remember too that not only frames are at issue here -- a navigation bar using tables or divisions would appear to be covered by the patent as well.
While it is blatently obvious with hindsight that frames can be used in this manner, some Googling around will show that a huge amount of web design material at the time references a document called "Ameritech Web Page User Interface Standards and Design Guidelines" by Detweiler, M.C. and Omanson, R.C. (1996), on the matter of creating a consistent user interface by using frames. If that doesn't ring a bell, Ameritech was the original holder of the patent, and recently acquired by SBC.
Reading the patent provides some more insight too: they contemplate a document with embedded codes indicating document sections, that conforms to a predefined structure. Read this way, the patent does not partain to HMTL frames, because HTML is a hypertext linked collection of documents, not a single document. A navbar or frame moving the view to named references within a single document, however, would clearly violate the patent.
So is the patent valid? Well, that involves proving prior art; not just that frames existed, but that they were used for the purpose of navigation, both in a single document and between documents. Any evidence of tables to do the same thing would also be useful. Also crutial is having an incontestible source -- printed information is best, a reputable online news source or journal is the next best thing.
w3.org records Edelstein's Sep 1995 proposal to include frames in the HTML specification, but the example page he sites is no longer available.
The Netscape Navigator 2.0 announcement contains "Frames, a new page presentation capability that enables the display of multiple, independently scrollable panels on a single screen, each with its own distinct Internet address. They also enable a region of the screen to be frozen in place as the user scrolls through information on a page". Tantalising, but it doesn't mention using the frozen region for navigation.
Most promising are the Mozilla 2.0 release notes. Two of the example links are broken, while third doesn't work in my browser, although the pages appear to be there. It clearly demonstrates the use of a navigation frame to select different pages in a site, and view them in a "dynamic" frame. That said, the navigation frame itself is not entirely static (it scrolls, but does not change), and there is no navigation inside a single document from the frame.
There is a lot of effort required to find proper evidence of prior art that will hold up in court. The Wayback Machine would provide great evidence, if only we can find it.
This is completely laughable. Since its first release (as an add-on package, not even part of the JDK) Swing has been one of the most mature and best designed GUI toolkits available. The only three allegations which can be justifiably levelled against Swing are:
Most developers who complain about the difficulty of using Swing are simply missing the point. I have had developers argue for hours about how terrible the table/tree components are, because you have to do "all that useless shit with models", and you can't just say "table.setCellAt(x, y, value)". Similarly there are a dearth of developers (especially those from the MS Windows world) who understand the need for layout components, as opposed to using absolute dimensions and coordinates.
For anyone who disses Swing, make sure you've read the Java Look and Feel Design Guidelines. Better than a Swing manual or introduction, it investigates building real-world applications with Swing, focusing on user experience and usability.
Swing's support for consistent navigation; centralised control over colours, widget L&F and localization; as well as its powerful and extensible widget set (e.g. TreeTables and the SwingSet2 demo) put it years ahead of most other toolkits, even now. Java's native L&F has improved over the years, to the extent that (for win32 at least) you can create Java apps that look native.
But Swing is not a silver bullet. With any cross platform toolkit you will run into problems. Qt, GTk, and Wx all have issues that need to be resolved when porting the app using them to a new platform. Similarly there is some effort to ensure that your Java/Swing application looks and behaves consistently on all its target platforms. In my experience Swing is far more portable than other toolkits, with the possibly exception of Tk. If performance is paramount in your application, then Swing is not for you; but this certainly doesn't make it unsuitable for an average business application.
Why is it that Slashdotters always focus on the duration of Copyright as a whole? Could it be that what they really want is free content, and don't really care about the public domain?
The public domain is NOT greatly enriched by a particular work being available in the public domain. The public domain IS greatly enriched by allowing creators to build on the works of others.
The Star Wars saga is a good example. This is a brilliant series of movies, and the many people and organisations involved deserve to reap the benefits for the creativity, effort and risk they invested. How long should these movies remain under Copyright? They are still popular now, contributing to the economy. That means that hundreds of people are still benefitting from that Copyright. This could still be the case in 100 years ... at what point do we stop this economic benefit and say it is in the public interest to make this content free?
The better response is not to answer that question, but to propose an alternative. The is a huge amount of fan fiction surrounding Star Wars, much of it illegal. ONE creation ("A New Hope") sparked off a huge amount of derivative creation, only a tiny amount of which was sanctioned. This is where Copyright really hurts the public domain. Not only does Copyright keep us paying for Star Wars the movie for another 50 years, but it prevents fan fiction from extending and enriching the original idea.
Some degree of control over derivatives is, of course, justified. A creator needs some time in which to produce a derivative of his/her own, in order to best benefit from Copyright. In addition, bad derivatives can harm the popular perception of the original, and thereby harm the creator of the original. On the other hand, good derivatives can drive up the popularity of the original.
So I propose that we stop caring so much about the duration of Copyright as a whole, or Copyright on a particular work, and start caring about the duration of monopoly over derivative works. This way we can see the avalanche effect of one creation leading to many derivatives which enrich society, while still allowing the original creator to benefit.
Couple with this a use-it-or-lose-it rule, where a work, once published, cannot be withdrawn or withheld (it must be available for sale), and we have a situation where ALL work is available (although you will still have to pay for the "original" that started it all for some time), and concepts and ideas are built on far more readily.
There seem to be three sides to the IP debate: big corporations representing huge IP interests, vocal activists representing themselves in the name of the common good, and the man in the street who doesn't really care.
Corporate interest, unfortunately, is focused on complete control. The activists tend to focus on maintaining the status quo as it was a decade ago, or on the abolition of IP rights. And the man in the street still doesn't care, because he still wants the content, and doesn't care about the public domain as it will exist after he is dead.
And everyone is missing the point. Protecting a work for 14 years, 50 years, 70 years or 100 years doesn't damage the public domain much, if at all. This is also within range of the time during which the creator can benefit from the work. Placing arbitrary time limits on the rights a creator enjoys will always be a difficult subject: some works will never do well, others are popular for many decades, and yet others are "ahead of their time" and may only realise their value decades after they are created.
What damages the public domain is the growth of Copyright to cover derivative works, and the right to withhold licensing after first publication. Preventing derivatives is the most destructive, preventing creators from building on the work of others. Withholding licensing means that a work can be published initially, then withdrawn (usually because it is not profitable) and never seen for the next 70+ years.
If we adjust Copyright law to allow the creation of derivative works after a short time (say 5 years), and force a use-it-or-lose-it scenario (where creators are forced to license published works no longer under publication to third parties on reasonable terms), we can claim back a lot of the benefit that Copyright offers to the public domain, without completely trampling over the rights of creators to the specific content that they created.
Is it just me, or did you completely lose the point of my comment?
Usenet exists in a hierarchy, and there are rules for adding groups (forums). There is no support for user accounts or for collaborative filtering ("moderation" as found on Slashdot). Posts are stored on a central server, and worse are lost over time; as opposed to being published by their author onto private "forum space" where (s)he can claim copyright and take responsibilitity, addressing the legal issues involved.
No matter how low the single to noise ratio can get on Slashdot, it doesn't come close to usenet.