On the other hand, Sun's AnswerBook far outstrips all Linux documentation for ease of use and completeness. Linux needs to take a leaf from Sun and Microsoft's books of usability when it comes to providing documentation (both for developers and end users).
You may want to read up on EMV. It is a cooperative initiative between Visa, Mastercard and Europay, and is set to roll out (region dependant) by 2005. Credit cards will be phased out soon after (by the aforementioned companies refusing to accept liability to fraud on non-EMV transactions).
EMV provides for online and offline transaction approval, mostly based on the size of the transaction and the running size of offline transactions since the last online one.
I agree that 19 years of monopoly is unreasonable, hence my assertion that patents should be allowed, but the duration should be much shorter.
Unfortunately patent law operates on an all-or-nothing principle: a major technological advancement that cost $1 billion and 15 years to achieve receives the same protection as a minor competitive edge which cost $10000 and 3 months.
As for it being obvious... creative research is like being on the wrong side of a trap door. Its really hard to go through, but anyone on the other side can easily work out the trick. Innovation is often about doing something which is blindingly obvious, but no-one thought of it before.
Often just knowing the result and the fact that it can be accomplished makes it easier to reproduce. Chemistry is a good example: a theoretical compound can be proposed and its potential properties suggested, but determing how to manufacture the compound can be a tough problem. A couple of experts look at it and tell you it simply can't be done. Then someone announces they have create it, and cheaply. The experts reevaluate, knowing they must have missed something: it is possible, with current technology, and inexpensive - given those hints they are a lot closer to a solution.
So, what SHOULD be patentable? Algorithms? RSA is quite obvious to anyone skilled in mathematics... once they've seen the algorithm. Should the internal combustion engine have been patentable? It was a major technological advancement, it has been the bastion of private transport for the better part of a centuary, but it is arguably just a derivative of a steam piston. Obvious to anyone skilled in mechanics.
I would like to see OSS obtain some patents and fight fire with fire. But it won't happen. No-one in the OSS world is prepared to put development effort into a product which involves patented technology, because of the stigma the community has attached to patents.
There is a tendency, especially in the OSS/FSF world, to under-estimate the significance of innovations in software. While I am largely against the current patent system, my dislikes for it revolve around the duration of patents, and the inability of clerks to apply or monitor the requirements for innovation.
You consider "tabbed palettes" ludicrous. With the benefit of hindsight, I can hardly disagree... but were they innovative at the time, before world + dog started using them?
Maybe a better example (unpatented, fortunately): toolbars. Would those be patentable? Are they (were they) innovative? We managed to get through over 20 years of GUI use without the widespread use of toolbars. Anyone know when they first appeared?
Assuming a windowed environment, the use of a title bar with some system buttons can be considered obvious: that has been around since the beginning. But the idioms by which we further break down interfaces and make them accessible are developed over time. Which necessarily implies that there is room for innovation: doing something which is NEW, and not just a variation of what has been done before. And that is patentable.
So we're left with two questions: should such innovation be patentable; and are tabbed palettes new or a variation?
I assert that GUI innovations SHOULD be patentable (although I'd like to see a much shorter duration on all software-related patents). There are individuals and companies which spend a lot of time, effort and money researching GUI concepts, improving ease of use, and generally developing idioms which gives their software an edge... but then have that idea reused by others in less than a couple of months, because the development cycle is shorter than the research cycle.
From Adobe's site:
Q11: Tabbed palettes are fairly common throughout software applications and operating systems -- what makes Adobe's palettes special and patentable?
A: Like Velcro® and Post-It® notes, the very best inventions become so familiar that they are taken for granted. The fact that tabbed palettes seem so natural and common now is a testimony to the Adobe development effort that went into the invention. Adobe's patent describes a unique method that allows tabs within palettes to be customized, separated and reorganized by users. This invention was a significant leap forward for customers' productivity and personalization of the interface.
As for tabbed palettes... this is a more difficult one. But first you need to understand the patent. This is not just about a tool dialog with a tab panel in it! The patent is available from Adobe's site, and a set of animations illustrate the infringment.
As you can see... this patent is about multiple tool dialogs (palettes) which dock together to form tabbed panels within a single dialog. Suddenly the idea is not so obvious anymore. Dockable components which overlap to save space...? That's not a universal GUI concept; showing and hiding tool windows or popping up dialogs in a stack is a traditional means to handle this problem. Arguably Adobe DID innovate in this instance.
OMG! I just committed a heinous crime! I skipped tracks 1 and 2 on a CD (which I bought) to listen to my favourite (track 3).
Re:FYI: SOAP is not transport/port specific
on
Web Services
·
· Score: 2
...and this goes to show just how serious the security issues of SOAP are. SOAP is meant to be a data format which is transport indenendant, and is also intended to activate services.
So, if you want a decent firewall protecting your network, you must now use a stateful firewall which is capable of checking for SOAP messages in every know (and unknown!) SOAP transport... otherwise some complete arb can RPC to services on your internal network (possibly with the assistance of another complete morons inside the firewall wanting to expose services for reasons that don't serve the company).
Let's review:
Stage 1: dedicated protocols and ports for all applications; block off the port and you're happy.
Stage 2: some services start sharing common protocols and ports; you can't block the port anymore, but must rely on filtering provided by the service(s) in question. Security risks increase. Can you say "portmapper"?
Stage 3: some services start adding arbitrary execution services, like CGI and mail handlers. People without security understanding or expertise can develop these services, and create HUGE security holes. Firewalls must now redirect requests through a filter which can guess at what should be denied, because it looks like an execution request.
Stage 4: nasty administrators block off port 80 (and others) completely because of the shit you are causing by having executable services which they can't filter out reliably. Clever employee/hacker moves services off the default port, to some other permitted port (http on port 25, for example). Stateful firewalls are added to ensure that the protocol allowed through an open port is the correct one.
Stage 5: Major corporations band together to fuck the network administrators by creating a standand for executable services which can run over any protocol (more or less), successfully bypassing most stateful firewalls and existing filters. Administrators are powerless to lock down the network because they would have to deny ALL incoming and outgoing connections (you could always be providing a SOAP-over-POP3 service with SMTP for replies). Centralised security goes for a ball of chalk, and every individual computer must be secured to prevent a compromise of network security.
Stage 6 (the future): Stateful firewalls with protocol plugins deny EVERYTHING except what they explicitly recognise as a SOAP request for an approved method of an approved object. Finally we can, once more, control who is doing what with our networks.
Stage 7 (the concern): Because SOAP is now a ubiquotous way of communicating, we end up with one encoding for communication. We also only need one protocol, say BEEP, because the original functions of all other transports are defunct. All "firewalling" is concerned with filtering SOAP messages according to their target object and method; so "firewalls" must redirect all communication (in and out) via SOAP proxies. The routing and channel handling built into SOAP and BEEP are used in preference to underlying mechanisms (like TCP/IP), and a network built on RPC on top of heavyweight, redundant protocols emerges.
Stage 8 (the hope): The network becomes self aware, realises it is butt ugly and (a) commits suicide; or (b) redevelops itself with a binary protocol with the minimum possible overhead.
Maybe this is a good thing. Everyone gets to communicate. Instead of hackers creating their own, limited distribution backdoor protocols, there is now one global standard backdoor protocol - at least the security experts can set their sights on a specific target!
Re:CORBA is too heavy & EJB is too RMI/IIOP de
on
Web Services
·
· Score: 2
I'm in agreement on your synopsis of XML. I have an article [my ISP] on why XML doesn't meet its stated goals and, in general, sucks. But its too long to post here.
The problems with HTTP as a transport are: 1. it is heavy; 2. it isn't stateful (as you point out); and 3. its INTENDED as a security backdoor. SOAP stemmed from work on XML-RPC, and both explicitly point out that the use of HTTP gave them an easy way to circumvent firewalls.
Heavy? Yes. There are several overhead fields on requests, and typically even more on responses (since server's don't tend to be terse just because you're asking for a web service). 20 'int's encoded as strings have an insignificant overhead compared to one or two lines of HTTP header information. And we won't even get into SOAP packets...
Compression (of which some have glibly spoken) is not an acceptable solution. Accepting or responding to a compressed SOAP message involves a series of filters or parsers: http, gzip, xml, soap, field encoding. The processing overhead is tremendous - even on an otherwise idle system with a Gb ethernet, SOAP cannot get near the performance of traditional (binary encoded) RPC mechanisms (on slower networks). Not to mention that you STILL have the HTTP header overhead, because those are not compressed.
The first question people should probably be asking is: Why not ASN.1 ? Its also standard, it has a ridiculously longer history than XML, and is in widespread use. It is a terse and efficient binary encoding. And that's its perceived downfall: somewhere, someone decided (with little technical knowhow or forethrough, I might add) that human-readable protocols were a good idea for data communication between machines.
Why are companies jumping on the bandwagon? Because either they stand to make a lot of money out of developing new technology, or the stand to make money out of selling new technology, or out of converting customer applications to use or support new technology, or they are customers who have their suppliers (and internal MSCD intelligencia) telling them how wonderful and great and cool and really important it is that they break their fully working existing systems and reimplement them with a new protocol. Just because.
In talking about a 'plug-in' architecture, from what viewpoint or for what purpose are you looking at the problem?
The first possibility I forsee is that you are developing an application which requires extensibility via third-party modules. In such a case that only design I am aware of (or rather, than I can think of at the moment) is to specify one or more APIs which the plug-in must implement, and then have the facility in your main application to register binary libraries. The application queries the libraries for the API(s) supported, and slots it in somewhere for use at the appropriate point.
The second possibility is that you are developing a plug-in architecture for a language, for others to use in a generic fashion. Your best bet is to study the way this is done in existing languages, and (as many other posters have said) don't do another plug-in architecture for a language that has one.
I had a third possibility in mind, but it seems to have been taken by a pigeon;)
I think your examples show quite capably that there is little danger in having fingerprints in a central database. I can also understand why some people are cautious about such a system, but I think that is primarily related to culture: in the US it is not normal for arbitrary citizens to be fingerprinted. In a country where this has been the norm for years there is no feeling that you are being "singled out" or treated as a criminal; it is seen as a necessary preventative measure (or rather, tracability for the criminals).
Like any system, there is potential for abuse. But if the government REALLY want to follow you around, they can lift your fingerprints from many places.
Humans are far more fallable than systems in such an instance. All a human has to go on is a passport photograph -- most are notoriously bad. "Watch for these criminals" notices don't help, because disguises are cheap and effective.
I also think your assumption of a "reprogramming" service is questionable. Such a system would require public key crpyography for security, so a reprogramming service would need the governments private key... not something that is going to be easy to achieve, or go unnoticed if it is managed!
I also can't see the human factor totally removed. Most airports have roving security or customs officers who can randomly interrogate you (ask for proof of ID, reason for entering the country, where you are staying, etc). I would also imagine that anything the ingress system finds suspicious (a borderline fingerprint match, for example) will be brought to the attention of supervisors.
Of course I could be wrong - HK may go the completely electronic route, no humans involved; but I still contend that this is more secure than existing systems. You problems are likely to arise when the system WON'T let you in.
The problem with 1984 in applicatation to the Western world is our economic system. Business controls more of your life than government does. Maybe, depending on how the ID system works, government could revoke your identity. There's nothing stopping them from doing that already. But government can't force business to freeze the bank accounts of all political opponents, can't make all private security companies turn a blind eye, etc. Only if government has complete control of all aspects of life, can it impose a 1984-like control on you.
The scariest part, for me, is that HK is setting a precedent. And it won't take long for other countries to jump on the bandwagon
Oh! Mortifying! They're going to check your identity at customs!
I am from South Africa. I have travelled to the UK, Italy, and the USA. ONLY in the USA was the magnetic stripe on my Passport swiped. ONLY in the USA were my details entered into a computer system while I passed through customs. ONLY in the USA was I forced to provide contact number for my employer, place of residence, etc to enter on a business VISA.
In all other countries my passport is checked, the VISA checked, and I am given a cursory glance to ensure I match the photo. No record of my comings and going is taken.
Umm... "standardized 'smart'-chip cards" !? Okay, a standard smartcard has a chip, which has ROM and RAM. Onto this standard smartcard you load your program, into ROM. The program is application specific. There is no 'standard' for a "bank smart card", or an "identity smart card", or any other sort of smart card.
There are some standards for application interfaces, such as the new standard which will replace credit cards. And no matter how easily it could be hacked, its a heck of a lot harder than reading a credit card number off the front of a card.
Its called "asymmetric cryptography". Its the digital equivalent of that nifty watermarked paper they print money on. More or less. Only more difficult to forge.
In South Africa we have a national identity book. It it your proof of citizenship and contains ID number, photo, name, date of birth, drivers' license (although we now have a separate card for that), gun licenses, and voting record (as in it and you are stamped when you vote, nothing the fact that you voted, but nothing about the vote).
This identity is the basis of identity validation for most significant accounts and policies, including banks, insurance, etc. It is also a cornerstone in the prevention of fraud.
There are a large number of authors who have mostly debunked the privacy argument as fantasy. Their argument is very good, and I think a number of parallels can be drawn between the approaches to (logic behind) the no-identity-cards stance and the DRM stance.
If "information wants to be free", as so many proponents on/. argue, then how can your identity be excluded from this freedom?
The primary argument about DRM is that there are valid uses that DRM will limit, and that recourse to law is and should be the correct way to deal with Copyright transgressions. Copyright is a right permitted by the public and there must be restrictions to prevent its abuse by Copyright holders.
So too privacy is a right permitted by the public. When you walk into the street, someone can identify you, and tell whoever they want. You cannot prevent them from doing that. The correct way to handle this is not to restrict information, to have rights management on your identity; it is to have proper safeguards in place against identity abuse.
Once the first card reader is compromised, or even if someone just reverse-engineers the chip, the whole system is compromised
This is unlikely to be true. The simplest of systems will have all data readable but signed by a government certificate. Compromising the system will involve cracking the government key.
how long will it be before someone builds a remote reader that can pull info just by walking within a few feet of one
You should probably do some reading into smartcard security. Smartcards are not easy to crack, which is why they are so useful in secure transactions. It is possible to be sneaky and get (say) a DES implementation to leak a few bits in laboratory conditions, enough to weaken the cipher but not crack it totally. You are also likely to render the Smartcard data useless in the process.
Honestly I don't see the point of making the data hard to retrieve. The whole point is to have your details available for verification: here, this is me, and I have a government signed card which contains my photo, fingerprints, etc to prove my identity.
My biggest worry about these cards (since South Africa is also considering jumping on the bandwagon) is that big business will start using them for authentication in addition to validation... at which point the system goes to hell. I need to identify myself with this card, but authenticate myself using some secret which can't be physically taken from me.
Now add photo and the state has a current image of almost every citizen which could then be plugged into cctv systems at political demonstrations and immediately identify people opposed to the current government.
I don't know about America, but most countries I have been to have either an ID document with a photo, or a drivers' license with a photo. Anyone with a passport has their photo on a government database.
Fingerprints. The government doesn't have my fingerprints and I hope never will. Imagine you were at the scene of a crime, if the state already has your fingerprints they can match anyone who was there against their database, not just against known criminals.
What happens when the criminal is NOT known? If your fingerprints are coincidentally at a crime scene, you will be identified as a person present. You will almost certainly be visited and questioned. Maybe you were a witness, but didn't realise what you saw (the crime happened after you left, but you could identify some other people present). Fingerprints alone are not enough to convict -- EVEN IF they are the only prints present! These has been a case along these lines in the US courts in the late 80s.
Banking - going for a loan? Any genetic defects and they'll increase the interest rate you're paying and demand cover in case you die before its repaid.
Most loan houses insist on insurance cover - its prudent business practice. And if you are really in a first world country then you'll find that discrimination on such an arbitrary basis is unconstitutional. You'll get the loan, at the same interest rate as everyone else, but you may have to pay more for insurance.
Which is CORRECT unless you have a socialist viewpoint, because you are a higher risk customer. (Disclaimer: I happen to be sufficiently socialist to think this is wrong, but in strict capatalism it isn't. Also, if you hide your actual risk, you damage the entire industry, including other policy holders, because the fund cannot adequately assess its risk).
Insurance - any genetic abnormalities and then try getting insurance. Even worse if diseases such as HIV/AIDs were included in your information.
I don't know how the US treats this sort of thing. In South Africa medical aid and medical insurance are vastly different animals. The med. aid industry is carefully regulated, and all policy holders cross-subsidised, so there is no loading of premiums based on your personal medical information. BUT you HAVE to fully disclose ALL information to the medical aid, or they can refuse to pay. Medical aids can even force you to go for tests on joining in order to determine your health, but the results cannot affect your ability to join, or affect your premiums. This is to ensure that the entire industry can correctly assess its risk.
Medical insurance is unregulated, and policies can be loaded against the holder according to his/her risk profile. Again, in a capatalist society why should you pay the same as me for insurance when you are a much higher risk (for example).
Finally the worst part Identity theft. Government ID card is supposed to prove beyond all reasonable doubt that you are who you say you are.
How do you prove your identity at the moment? "I am me"? Do you have a drivers' license, an ID document, what? And how do they prove that you are who you claim to be.
The only way to be certain is to have a birth certificate lodged with the government containing your name, a genetic fingerprint, and references to your parent's identities. And such a system is susceptible to an interal attack.
Unless the government claim the system is unhackable, there is still the opportunity to claim identity theft. As long as that option is open, this system is preferable to one where forging identification documents is limited to overcoming physical security.
On the other hand, lack of ID cards can be another problem altogether.
In South Africa, for example, all banks are required by law to verify your identity during "management" transactions; that means opening and closing accounts, and any non-cash instructions which are not protected by electronic passwords (your PIN).
Many other countries have similar laws, or at least practices in order to protect businesses. Often they have to rely on identification documents which are not meant for that purpose. The problem of SSNs and drivers' licenses in the US has already been cited.
Although I value my privacy, I am more secure in the knowledge that there is additional (albeit not perfect) protection against someone giving instructions on my accounts. At the very least, a digital signature is harder to fake than an ID document!
I have been in programming for 15 years, with 5 years of commercial experience in development and software engineering. I work extensively on Windows and Solaris on a daily basis. And this is my 2c.
you're looking to maximize developer and end-user productivity
You have made a massive assumption in this statement and your recommendations regarding it: that developers are familiar and proficient with the "Unix" way of doing things. This is far from a foregone conclusion. Most developers I work with have no familiarity with Unix systems. Often their areas of expertise are not in coding (as the case of the poster of this article), but they use coding to achieve their real job function. In such cases, the easiest tool is often the best tool.
IDE with color syntax highlighting
Of benefit because it makes reading source code easier while you are editting it. As you rightly point out, such editors exist for Unix too.
Online manuals for function calls and syntax elements at a button-press ... which is arguably easier than switching to another window and running man, which is also not hypertext enabled, so it takes longer to go back and forth to find exactly what you are looking for. You have also ignored between this point and the last the existing of syntax completing editors, which will pop up a list of available functions complete with parameters, etc, which often avoid the need to get help at all.
Ability to arrange a GUI framework, and generate code for same, by dragging some things about in a GUI fashion
You're either a GUI guru, or you never do GUI work. I have worked with people who are dedicated to GUI coding, using Java, MFC, Gtk or one of many other toolkits. To make a stable, usable interface for even a minimal program can easily take a week. Or you can use C++ Builder (since Borland's tools are the best in this regard) and do it in an afternoon.
The proof of the pudding is in the eating: until very recently we have not seen many attractive, easy to use applications on Unix. They are simply too difficult to implement.
GUI development is often no recognised for the art/science that it is. Most developers don't even KNOW about tab order, accelerator keys, and the psychological principles of layout and choice. While GUI tools can't help you with all of these, they do make most much easier to access and manipulate.
Now let's look at what Unix tools offer.
Pipeline-capable tools
To an "everyday" developer, what benefit does this really offer? In an edit-compile-test-debug environment, where do pipes assist you?
automate project regeneration, recompilation of course of arbitrary nature (make, GNU Make) ...which requires a lot of knowledge to set up. Or you can (right-click) Add files to project, and they automatically compile, link and work. If you really need a more complex build process, you can specify custom build settings in a scripting language (not as powerful as 'sh', but you can call external programs... say perl for win32).
programatically generate parsers and lexers (lex/flex, yacc/bison)
More questionable benefit. I have worked on one project which required a parser/lexer, mostly because it was involved in source code analysis. Your average user application, including databases, accounting packages, scientific number crunching, etc, does not require a parser. Besides which, all of these tools have win32 ports, and there are good many win32-specific parser generating tools which allow interactive visual specification of the parser rules, which makes yacc grammar files look like tumbleweed on steroids.
Check syntax/portability semantics (lint)
Lint is an exceptionally useful tool... but the most reffered to implementation is PCLint, which runs on win32.
Pretty-print source code in various languages ...or you get this built into your editor on win32. Why an external tool?
Find and print patterns (grep)
Both Visual Studio and Borland's IDEs support regular expression find/replace on all files in your project(s). Not many people know or use this functionality, because its simply too complex to learn unless it will make your life more efficient on a regular basis. And for most people, it doesn't.
One of the biggest problems is that REs are hamstrung when dealing with program code because code is a context-free grammar not a non-deterministic finite automaton. Find/replace across multiple files (which is a lot easier with a dialog than with sed) is often sufficiently powerful.
Extract strings from binaries (strings)
So...? How many userland developers seriously use this sort of tool?
Create function libraries (of static/dynamically loaded nature, as supported by host OS) (ar, etc)
Nothing that you can't do with any C/C++ compiler on win32. If you really want, you can use cl.exe and do it from the command line.
High quality online documentation in the form of manpages, GNU texinfo/info documents, as well as any vendor-specific documentation in various formats.
We apparently have different definitions of "high quality". To me, "high quality" means accessible, readable, and understandable. It should include examples, and cross reference related documentation. It should be easy to navigate, indexed, searchable and categorised.
Now I'm sure man provides most of those things, in your opinion. But in the opinion of most developers (as discovered from emperical research for an Honours project) it sucks.
In case you weren't aware, Emacs, GCC and GDB are all available on win32, with or without Cygwin. In addition, you should probably be informed that GCC with maximum optimisations is likely to give you an application about 25% slower than VC (emperical observation based on a server-side non-database processing application with multiple clients, under load).
There are many alternatives for developing with free (as in beer) tools on Win32.
Cygwin/GCC (www.cygwin.com): Cygwin is a Posix-on-win32 emulation layer, and associated Unix-like environment. GPLed, and you can't redistribute your program under any other license for that reason. Good choice if you like a Unix-like environment.
Mingw32 (www.mingw.org): Unix tools and GCC compiler on Win32 without an emulation layer. Not as easy as Cygwin (IMHO) but your software is free of restrictions and doesn't require extra runtime DLLs (only win32 platform DLLs).
Java (java.sun.com): I think this has been largely underrated in the discussion so far. Java is a great language for writing applications and saves you from a lot of the tricks and traps of C/C++. OTOH if you're familiar with C/C++ and not with Java, or if you are aiming at CLI or scientific (number crunching) applications, Java isn't such a great choice.
more Java: There are a number of decent IDEs available, including Netbeans (www.netbeans.org) and Borland's JBuilder (www.borland.com, personal edition is free for non-commercial use).
Perl: Get it as part of Cygwin, or download ActiveState's Perl (www.activestate.com) which has a win32 GUI installer, better docs and better win32 support. Perl's GUI support can be a bit cryptic (IMHO) compared to other languages. As a scripting language you probably don't want to use this if you need to distribute binaries.
Tcl/Tk (www.scriptics.com): Excellent for GUI applications and prototypes, not so great for processing. Tcl/Tk is a glue language that interfaces well with a LOT of other languages. Brilliant GUI support, but can look a bit kludgy. Easy to use once you've got the hang of it, but as with Perl its a scripting language and you don't want to distribute it (although Scriptics does offer commercial tools to compile Tcl to binary code).
Python, Ruby, Basic, Fortran, Cobol,... they all have free compilers and runtimes for win32, and may be what you are looking for.
A point that is often missed is that DRM and the DMCA are about protection, not security. Protection aims to take reasonable steps to prevent damage, and to introduce means to control damage.
The DMCA is a backup for DRM. It does go too far, though. But the DMCA has been passed because it is clear that, in the light of the failure of existing DRM techniques, industry has been unable to resort to existing laws for damage control.
Copyright is an asset and as such needs protection. I disagree with the term of copyright and repreated extensions, but the rationale for having it in the first place is sound.
DRM is a first line of protection of copyright, and should prevent casual tresspass or theft. A successful DRM does not completely prevent duplication; it prevents casual duplication and should present a barrier for illegal mass duplication.
It is widely acknowledged (even within the record industry, although not publically) that DRM cannot provide security -- it cannot prevent determined (or even eager) crackers from getting around the protections. It doesn't need to. Once the number of transgressions is limited, it is possible to resort to legal action in those cases. DRM is intended to reduce the number of transgressions to an acceptable, and managable, level.
Yes. But you can't simply check that the certificate is there. The certificate has to be used in order to make the content work. Another way to put this is: the certificate in the hardware device is a private key; the content is encrypted under the public key.
Even this is far from foolproof - given such a device on its own, you can stick in the encrypted version and retrieve the decrypted version.
At the furthest end of the chain the content has to be "rendered" in some form... its always possible to catch it there;)
The only system known that MAY get around this is watermarking, in which it shouldn't matter WHERE you capture it in the chain, you can't make it input to any other DRM device because it will recognise the watermark and prevent you from using the content.
This is an excellent example of the Final Assault on DRM. It is inconceivable for a law to be passed which requires rights management on all digital works; but it IS conceivable to have all devices enforce the rights of managed works. In other words you can't prevent a performer from giving his works away.
So the final assault is to record the output of the amazingly high quality work from your amazingly high quality hi-fi, MP3/OGG the result, and you're away.
This is of course where watermarking comes in - theoretically a watermark should prove that it is a managed work. But we have yet to see a scheme which actually make watermarks work, either in technology or in practice. After all, how do you tie a watermark to a person... especially if your mass producing DVDs?
I don't see Christians running around murdering people
Really? I don't suppose Burning Times is an issue here? No, witches aren't people, are they? And Jack the Ripper wouldn't count, then? Neither would a significant number of American soldiers... oh wait, that's not murder, the US declared war first which makes it all okay. Not to mention British and Spanish colonists, and its well known that nobody expects the inquisition.
In the last year in this country we have had ten priests (not just believers) up on rape charges. One recently took his life to avoid the consequences.
No, I think you're right... let's blame the Muslims. I mean who in their right mind would complain about an occupying force from a democratic superpower, or having pieces of their country carved up and handed to some other religious zealots who were picked on by some europeans.
On the other hand, what is "sexually explicit"? Does this include sex education material, scary pictures of STDs, guides for better relationships? Pornography has an accepted definition in courts, but sexually explicit is far broader.
When considering other things to censor, why should violence be censored? It is shown that REAL violence (as opposed to media violence) has an impact on children that makes them less likely to engage in violence (oh, there is the trauma side effect, but its part of the growing experience *wg* ; not to mention that kids are equally traumatised by depictions of sex). What's wrong with gun catalogues? I mean, you can look but you can't buy, right?
And what constitutes a "religious cult"? Anything with socially unacceptable teaching which screws up your mind? Can you say Christianity? One of the side effects of freedom of religion is a guarantee of access to information like this.
Slashdot Mirror
On the other hand, Sun's AnswerBook far outstrips all Linux documentation for ease of use and completeness. Linux needs to take a leaf from Sun and Microsoft's books of usability when it comes to providing documentation (both for developers and end users).
You may want to read up on EMV. It is a cooperative initiative between Visa, Mastercard and Europay, and is set to roll out (region dependant) by 2005. Credit cards will be phased out soon after (by the aforementioned companies refusing to accept liability to fraud on non-EMV transactions).
EMV provides for online and offline transaction approval, mostly based on the size of the transaction and the running size of offline transactions since the last online one.
I agree that 19 years of monopoly is unreasonable, hence my assertion that patents should be allowed, but the duration should be much shorter.
Unfortunately patent law operates on an all-or-nothing principle: a major technological advancement that cost $1 billion and 15 years to achieve receives the same protection as a minor competitive edge which cost $10000 and 3 months.
As for it being obvious ... creative research is like being on the wrong side of a trap door. Its really hard to go through, but anyone on the other side can easily work out the trick. Innovation is often about doing something which is blindingly obvious, but no-one thought of it before.
Often just knowing the result and the fact that it can be accomplished makes it easier to reproduce. Chemistry is a good example: a theoretical compound can be proposed and its potential properties suggested, but determing how to manufacture the compound can be a tough problem. A couple of experts look at it and tell you it simply can't be done. Then someone announces they have create it, and cheaply. The experts reevaluate, knowing they must have missed something: it is possible, with current technology, and inexpensive - given those hints they are a lot closer to a solution.
So, what SHOULD be patentable? Algorithms? RSA is quite obvious to anyone skilled in mathematics ... once they've seen the algorithm. Should the internal combustion engine have been patentable? It was a major technological advancement, it has been the bastion of private transport for the better part of a centuary, but it is arguably just a derivative of a steam piston. Obvious to anyone skilled in mechanics.
I would like to see OSS obtain some patents and fight fire with fire. But it won't happen. No-one in the OSS world is prepared to put development effort into a product which involves patented technology, because of the stigma the community has attached to patents.
There is a tendency, especially in the OSS/FSF world, to under-estimate the significance of innovations in software. While I am largely against the current patent system, my dislikes for it revolve around the duration of patents, and the inability of clerks to apply or monitor the requirements for innovation.
You consider "tabbed palettes" ludicrous. With the benefit of hindsight, I can hardly disagree ... but were they innovative at the time, before world + dog started using them?
Maybe a better example (unpatented, fortunately): toolbars. Would those be patentable? Are they (were they) innovative? We managed to get through over 20 years of GUI use without the widespread use of toolbars. Anyone know when they first appeared?
Assuming a windowed environment, the use of a title bar with some system buttons can be considered obvious: that has been around since the beginning. But the idioms by which we further break down interfaces and make them accessible are developed over time. Which necessarily implies that there is room for innovation: doing something which is NEW, and not just a variation of what has been done before. And that is patentable.
So we're left with two questions: should such innovation be patentable; and are tabbed palettes new or a variation?
I assert that GUI innovations SHOULD be patentable (although I'd like to see a much shorter duration on all software-related patents). There are individuals and companies which spend a lot of time, effort and money researching GUI concepts, improving ease of use, and generally developing idioms which gives their software an edge ... but then have that idea reused by others in less than a couple of months, because the development cycle is shorter than the research cycle.
From Adobe's site:
As for tabbed palettes ... this is a more difficult one. But first you need to understand the patent. This is not just about a tool dialog with a tab panel in it! The patent is available from Adobe's site, and a set of animations illustrate the infringment.
As you can see ... this patent is about multiple tool dialogs (palettes) which dock together to form tabbed panels within a single dialog. Suddenly the idea is not so obvious anymore. Dockable components which overlap to save space ...? That's not a universal GUI concept; showing and hiding tool windows or popping up dialogs in a stack is a traditional means to handle this problem. Arguably Adobe DID innovate in this instance.
OMG! I just committed a heinous crime! I skipped tracks 1 and 2 on a CD (which I bought) to listen to my favourite (track 3).
...and this goes to show just how serious the security issues of SOAP are. SOAP is meant to be a data format which is transport indenendant, and is also intended to activate services.
So, if you want a decent firewall protecting your network, you must now use a stateful firewall which is capable of checking for SOAP messages in every know (and unknown!) SOAP transport ... otherwise some complete arb can RPC to services on your internal network (possibly with the assistance of another complete morons inside the firewall wanting to expose services for reasons that don't serve the company).
Let's review:
Maybe this is a good thing. Everyone gets to communicate. Instead of hackers creating their own, limited distribution backdoor protocols, there is now one global standard backdoor protocol - at least the security experts can set their sights on a specific target!
I'm in agreement on your synopsis of XML. I have an article [my ISP] on why XML doesn't meet its stated goals and, in general, sucks. But its too long to post here.
The problems with HTTP as a transport are: 1. it is heavy; 2. it isn't stateful (as you point out); and 3. its INTENDED as a security backdoor. SOAP stemmed from work on XML-RPC, and both explicitly point out that the use of HTTP gave them an easy way to circumvent firewalls.
Heavy? Yes. There are several overhead fields on requests, and typically even more on responses (since server's don't tend to be terse just because you're asking for a web service). 20 'int's encoded as strings have an insignificant overhead compared to one or two lines of HTTP header information. And we won't even get into SOAP packets...
Compression (of which some have glibly spoken) is not an acceptable solution. Accepting or responding to a compressed SOAP message involves a series of filters or parsers: http, gzip, xml, soap, field encoding. The processing overhead is tremendous - even on an otherwise idle system with a Gb ethernet, SOAP cannot get near the performance of traditional (binary encoded) RPC mechanisms (on slower networks). Not to mention that you STILL have the HTTP header overhead, because those are not compressed.
The first question people should probably be asking is: Why not ASN.1 ? Its also standard, it has a ridiculously longer history than XML, and is in widespread use. It is a terse and efficient binary encoding. And that's its perceived downfall: somewhere, someone decided (with little technical knowhow or forethrough, I might add) that human-readable protocols were a good idea for data communication between machines.
Why are companies jumping on the bandwagon? Because either they stand to make a lot of money out of developing new technology, or the stand to make money out of selling new technology, or out of converting customer applications to use or support new technology, or they are customers who have their suppliers (and internal MSCD intelligencia) telling them how wonderful and great and cool and really important it is that they break their fully working existing systems and reimplement them with a new protocol. Just because.
In talking about a 'plug-in' architecture, from what viewpoint or for what purpose are you looking at the problem?
The first possibility I forsee is that you are developing an application which requires extensibility via third-party modules. In such a case that only design I am aware of (or rather, than I can think of at the moment) is to specify one or more APIs which the plug-in must implement, and then have the facility in your main application to register binary libraries. The application queries the libraries for the API(s) supported, and slots it in somewhere for use at the appropriate point.
The second possibility is that you are developing a plug-in architecture for a language, for others to use in a generic fashion. Your best bet is to study the way this is done in existing languages, and (as many other posters have said) don't do another plug-in architecture for a language that has one.
I had a third possibility in mind, but it seems to have been taken by a pigeon ;)
I think your examples show quite capably that there is little danger in having fingerprints in a central database. I can also understand why some people are cautious about such a system, but I think that is primarily related to culture: in the US it is not normal for arbitrary citizens to be fingerprinted. In a country where this has been the norm for years there is no feeling that you are being "singled out" or treated as a criminal; it is seen as a necessary preventative measure (or rather, tracability for the criminals).
Like any system, there is potential for abuse. But if the government REALLY want to follow you around, they can lift your fingerprints from many places.
Humans are far more fallable than systems in such an instance. All a human has to go on is a passport photograph -- most are notoriously bad. "Watch for these criminals" notices don't help, because disguises are cheap and effective.
I also think your assumption of a "reprogramming" service is questionable. Such a system would require public key crpyography for security, so a reprogramming service would need the governments private key ... not something that is going to be easy to achieve, or go unnoticed if it is managed!
I also can't see the human factor totally removed. Most airports have roving security or customs officers who can randomly interrogate you (ask for proof of ID, reason for entering the country, where you are staying, etc). I would also imagine that anything the ingress system finds suspicious (a borderline fingerprint match, for example) will be brought to the attention of supervisors.
Of course I could be wrong - HK may go the completely electronic route, no humans involved; but I still contend that this is more secure than existing systems. You problems are likely to arise when the system WON'T let you in.
The problem with 1984 in applicatation to the Western world is our economic system. Business controls more of your life than government does. Maybe, depending on how the ID system works, government could revoke your identity. There's nothing stopping them from doing that already. But government can't force business to freeze the bank accounts of all political opponents, can't make all private security companies turn a blind eye, etc. Only if government has complete control of all aspects of life, can it impose a 1984-like control on you.
Oh! Mortifying! They're going to check your identity at customs!
I am from South Africa. I have travelled to the UK, Italy, and the USA. ONLY in the USA was the magnetic stripe on my Passport swiped. ONLY in the USA were my details entered into a computer system while I passed through customs. ONLY in the USA was I forced to provide contact number for my employer, place of residence, etc to enter on a business VISA.
In all other countries my passport is checked, the VISA checked, and I am given a cursory glance to ensure I match the photo. No record of my comings and going is taken.
And you're scared of HK?!
Umm ... "standardized 'smart'-chip cards" !? Okay, a standard smartcard has a chip, which has ROM and RAM. Onto this standard smartcard you load your program, into ROM. The program is application specific. There is no 'standard' for a "bank smart card", or an "identity smart card", or any other sort of smart card.
There are some standards for application interfaces, such as the new standard which will replace credit cards. And no matter how easily it could be hacked, its a heck of a lot harder than reading a credit card number off the front of a card.
Its called "asymmetric cryptography". Its the digital equivalent of that nifty watermarked paper they print money on. More or less. Only more difficult to forge.
In South Africa we have a national identity book. It it your proof of citizenship and contains ID number, photo, name, date of birth, drivers' license (although we now have a separate card for that), gun licenses, and voting record (as in it and you are stamped when you vote, nothing the fact that you voted, but nothing about the vote).
This identity is the basis of identity validation for most significant accounts and policies, including banks, insurance, etc. It is also a cornerstone in the prevention of fraud.
There are a large number of authors who have mostly debunked the privacy argument as fantasy. Their argument is very good, and I think a number of parallels can be drawn between the approaches to (logic behind) the no-identity-cards stance and the DRM stance.
If "information wants to be free", as so many proponents on /. argue, then how can your identity be excluded from this freedom?
The primary argument about DRM is that there are valid uses that DRM will limit, and that recourse to law is and should be the correct way to deal with Copyright transgressions. Copyright is a right permitted by the public and there must be restrictions to prevent its abuse by Copyright holders.
So too privacy is a right permitted by the public. When you walk into the street, someone can identify you, and tell whoever they want. You cannot prevent them from doing that. The correct way to handle this is not to restrict information, to have rights management on your identity; it is to have proper safeguards in place against identity abuse.
This is unlikely to be true. The simplest of systems will have all data readable but signed by a government certificate. Compromising the system will involve cracking the government key.
You should probably do some reading into smartcard security. Smartcards are not easy to crack, which is why they are so useful in secure transactions. It is possible to be sneaky and get (say) a DES implementation to leak a few bits in laboratory conditions, enough to weaken the cipher but not crack it totally. You are also likely to render the Smartcard data useless in the process.
Honestly I don't see the point of making the data hard to retrieve. The whole point is to have your details available for verification: here, this is me, and I have a government signed card which contains my photo, fingerprints, etc to prove my identity.
My biggest worry about these cards (since South Africa is also considering jumping on the bandwagon) is that big business will start using them for authentication in addition to validation ... at which point the system goes to hell. I need to identify myself with this card, but authenticate myself using some secret which can't be physically taken from me.
I don't know about America, but most countries I have been to have either an ID document with a photo, or a drivers' license with a photo. Anyone with a passport has their photo on a government database.
What happens when the criminal is NOT known? If your fingerprints are coincidentally at a crime scene, you will be identified as a person present. You will almost certainly be visited and questioned. Maybe you were a witness, but didn't realise what you saw (the crime happened after you left, but you could identify some other people present). Fingerprints alone are not enough to convict -- EVEN IF they are the only prints present! These has been a case along these lines in the US courts in the late 80s.
Most loan houses insist on insurance cover - its prudent business practice. And if you are really in a first world country then you'll find that discrimination on such an arbitrary basis is unconstitutional. You'll get the loan, at the same interest rate as everyone else, but you may have to pay more for insurance.
Which is CORRECT unless you have a socialist viewpoint, because you are a higher risk customer. (Disclaimer: I happen to be sufficiently socialist to think this is wrong, but in strict capatalism it isn't. Also, if you hide your actual risk, you damage the entire industry, including other policy holders, because the fund cannot adequately assess its risk).
I don't know how the US treats this sort of thing. In South Africa medical aid and medical insurance are vastly different animals. The med. aid industry is carefully regulated, and all policy holders cross-subsidised, so there is no loading of premiums based on your personal medical information. BUT you HAVE to fully disclose ALL information to the medical aid, or they can refuse to pay. Medical aids can even force you to go for tests on joining in order to determine your health, but the results cannot affect your ability to join, or affect your premiums. This is to ensure that the entire industry can correctly assess its risk.
Medical insurance is unregulated, and policies can be loaded against the holder according to his/her risk profile. Again, in a capatalist society why should you pay the same as me for insurance when you are a much higher risk (for example).
How do you prove your identity at the moment? "I am me"? Do you have a drivers' license, an ID document, what? And how do they prove that you are who you claim to be.
The only way to be certain is to have a birth certificate lodged with the government containing your name, a genetic fingerprint, and references to your parent's identities. And such a system is susceptible to an interal attack.
Unless the government claim the system is unhackable, there is still the opportunity to claim identity theft. As long as that option is open, this system is preferable to one where forging identification documents is limited to overcoming physical security.
On the other hand, lack of ID cards can be another problem altogether.
In South Africa, for example, all banks are required by law to verify your identity during "management" transactions; that means opening and closing accounts, and any non-cash instructions which are not protected by electronic passwords (your PIN).
Many other countries have similar laws, or at least practices in order to protect businesses. Often they have to rely on identification documents which are not meant for that purpose. The problem of SSNs and drivers' licenses in the US has already been cited.
Although I value my privacy, I am more secure in the knowledge that there is additional (albeit not perfect) protection against someone giving instructions on my accounts. At the very least, a digital signature is harder to fake than an ID document!
I have been in programming for 15 years, with 5 years of commercial experience in development and software engineering. I work extensively on Windows and Solaris on a daily basis. And this is my 2c.
You have made a massive assumption in this statement and your recommendations regarding it: that developers are familiar and proficient with the "Unix" way of doing things. This is far from a foregone conclusion. Most developers I work with have no familiarity with Unix systems. Often their areas of expertise are not in coding (as the case of the poster of this article), but they use coding to achieve their real job function. In such cases, the easiest tool is often the best tool.
Of benefit because it makes reading source code easier while you are editting it. As you rightly point out, such editors exist for Unix too.
You're either a GUI guru, or you never do GUI work. I have worked with people who are dedicated to GUI coding, using Java, MFC, Gtk or one of many other toolkits. To make a stable, usable interface for even a minimal program can easily take a week. Or you can use C++ Builder (since Borland's tools are the best in this regard) and do it in an afternoon.
The proof of the pudding is in the eating: until very recently we have not seen many attractive, easy to use applications on Unix. They are simply too difficult to implement.
GUI development is often no recognised for the art/science that it is. Most developers don't even KNOW about tab order, accelerator keys, and the psychological principles of layout and choice. While GUI tools can't help you with all of these, they do make most much easier to access and manipulate.
Now let's look at what Unix tools offer.
To an "everyday" developer, what benefit does this really offer? In an edit-compile-test-debug environment, where do pipes assist you?
More questionable benefit. I have worked on one project which required a parser/lexer, mostly because it was involved in source code analysis. Your average user application, including databases, accounting packages, scientific number crunching, etc, does not require a parser. Besides which, all of these tools have win32 ports, and there are good many win32-specific parser generating tools which allow interactive visual specification of the parser rules, which makes yacc grammar files look like tumbleweed on steroids.
Lint is an exceptionally useful tool
Both Visual Studio and Borland's IDEs support regular expression find/replace on all files in your project(s). Not many people know or use this functionality, because its simply too complex to learn unless it will make your life more efficient on a regular basis. And for most people, it doesn't.
One of the biggest problems is that REs are hamstrung when dealing with program code because code is a context-free grammar not a non-deterministic finite automaton. Find/replace across multiple files (which is a lot easier with a dialog than with sed) is often sufficiently powerful.
So
Nothing that you can't do with any C/C++ compiler on win32. If you really want, you can use cl.exe and do it from the command line.
We apparently have different definitions of "high quality". To me, "high quality" means accessible, readable, and understandable. It should include examples, and cross reference related documentation. It should be easy to navigate, indexed, searchable and categorised.
Now I'm sure man provides most of those things, in your opinion. But in the opinion of most developers (as discovered from emperical research for an Honours project) it sucks.
In case you weren't aware, Emacs, GCC and GDB are all available on win32, with or without Cygwin. In addition, you should probably be informed that GCC with maximum optimisations is likely to give you an application about 25% slower than VC (emperical observation based on a server-side non-database processing application with multiple clients, under load).
There are many alternatives for developing with free (as in beer) tools on Win32.
A point that is often missed is that DRM and the DMCA are about protection, not security. Protection aims to take reasonable steps to prevent damage, and to introduce means to control damage.
The DMCA is a backup for DRM. It does go too far, though. But the DMCA has been passed because it is clear that, in the light of the failure of existing DRM techniques, industry has been unable to resort to existing laws for damage control.
Copyright is an asset and as such needs protection. I disagree with the term of copyright and repreated extensions, but the rationale for having it in the first place is sound.
DRM is a first line of protection of copyright, and should prevent casual tresspass or theft. A successful DRM does not completely prevent duplication; it prevents casual duplication and should present a barrier for illegal mass duplication.
It is widely acknowledged (even within the record industry, although not publically) that DRM cannot provide security -- it cannot prevent determined (or even eager) crackers from getting around the protections. It doesn't need to. Once the number of transgressions is limited, it is possible to resort to legal action in those cases. DRM is intended to reduce the number of transgressions to an acceptable, and managable, level.
Yes. But you can't simply check that the certificate is there. The certificate has to be used in order to make the content work. Another way to put this is: the certificate in the hardware device is a private key; the content is encrypted under the public key.
Even this is far from foolproof - given such a device on its own, you can stick in the encrypted version and retrieve the decrypted version.
At the furthest end of the chain the content has to be "rendered" in some form ... its always possible to catch it there ;)
The only system known that MAY get around this is watermarking, in which it shouldn't matter WHERE you capture it in the chain, you can't make it input to any other DRM device because it will recognise the watermark and prevent you from using the content.
This is an excellent example of the Final Assault on DRM. It is inconceivable for a law to be passed which requires rights management on all digital works; but it IS conceivable to have all devices enforce the rights of managed works. In other words you can't prevent a performer from giving his works away.
So the final assault is to record the output of the amazingly high quality work from your amazingly high quality hi-fi, MP3/OGG the result, and you're away.
This is of course where watermarking comes in - theoretically a watermark should prove that it is a managed work. But we have yet to see a scheme which actually make watermarks work, either in technology or in practice. After all, how do you tie a watermark to a person ... especially if your mass producing DVDs?
Really? I don't suppose Burning Times is an issue here? No, witches aren't people, are they? And Jack the Ripper wouldn't count, then? Neither would a significant number of American soldiers ... oh wait, that's not murder, the US declared war first which makes it all okay. Not to mention British and Spanish colonists, and its well known that nobody expects the inquisition.
In the last year in this country we have had ten priests (not just believers) up on rape charges. One recently took his life to avoid the consequences.
No, I think you're right ... let's blame the Muslims. I mean who in their right mind would complain about an occupying force from a democratic superpower, or having pieces of their country carved up and handed to some other religious zealots who were picked on by some europeans.
On the other hand, what is "sexually explicit"? Does this include sex education material, scary pictures of STDs, guides for better relationships? Pornography has an accepted definition in courts, but sexually explicit is far broader.
When considering other things to censor, why should violence be censored? It is shown that REAL violence (as opposed to media violence) has an impact on children that makes them less likely to engage in violence (oh, there is the trauma side effect, but its part of the growing experience *wg* ; not to mention that kids are equally traumatised by depictions of sex). What's wrong with gun catalogues? I mean, you can look but you can't buy, right?
And what constitutes a "religious cult"? Anything with socially unacceptable teaching which screws up your mind? Can you say Christianity? One of the side effects of freedom of religion is a guarantee of access to information like this.