Way too many times does this editorial blend two concepts that are quite different:
PRIVACY: What you say only goes to your intended audience, what is meant to be read by you is for your eyes only.
FREEDOM of Speech: Being able to say what you want, where you want.
Restrictions on Privacy for increased safety are in my mind completely acceptable to increase my own Safety and ensure to some extent i'm not guna get blown out of the sky next time i fly. But that doesn't automatically mean my Freedom of Speech will be restricted. I can still talk shit about whoever I want with whomever I want.
I don't give a flying crap if the FBI reads all the steamy erotic emails i've sent to all my lovers. I hope they get off on it. As long as they don't stop me from doing it.
Just *think* what type of information government entities are after: Stuff that may threaten us. They're not trying to profile you. They're not guna sell any of their information to corporations.
I'll *gladly* give up some freedoms like online privacy, heck i'll gladly let feds snoop on my phone to be safer from terrorism. You privacy freaks need to chill the fuck out. We're not talking about some big corporation that's looking to snoop on your private life to gather personal information they can redistribute/sell/leverage to make more money, it's about an entity who really doesn't give a flying fuck about your private life, just trying to make sure you're not trying to nuke anyone. Get over yourselves people. For crying out loud.
I think you have some good ideas (especially recording sounds from the cabin as well as the cockpit if the plane is put in emergency mode - in fact, technology exists today where video could be used too, especially in the cockpit).
Agreed. I'm talking about building new planes. Completely re-thinking their design from the ground-up. And it's obviously not realistic, just like you, I vaguely understand the prohibitive costs. I just want something to be done, as you pointed out, a small subset of those ideas could more realistically be put in place on existing planes, but the key here is to put some *serious* thought about counter-terrorism systems and measures into the next generation of planes, and do whatever is possible to build them and roll them out to mainstream carriers as soon as possible.
Anybody working near a plane, who has the ability to come in and out of plane should be subject to the highest levels of security and background checks and be considered candidates for the highest levels of security clearance, people fit to work at the pentagon. Planes should from now-on be considered as some of the most DEADLY weapons and anything surrounding them should be subject to massive paranoia.
It's simple. You can work on a plane or near a plane, you can work at the pentagon. Law enforcement agencies have your whole life on-file.
ok I agree it's a little extreme but maybe something along those lines could be set-up.
Every airport in the united states should have a specific landing area called "emergency landing" that is kept clear at all times.
Upon triggering of a plane's emergency mode, not only should the pilots in the cockpit be completely isolated from any communications with the main cabin, BUT also communications with the ground or anywhere in the outside world, should only be one-way: PLANE to the GROUND. The Pilots should become instantly unable to receive any verbal communication from anything coming from the ground or the outside world so that terrorists could not coerce ground authorities to communicate with the plane to relay their demands to the pilots. The only communications coming from the ground to the pilots during an emergency mode should be in the form of DIGITAL instructions made of speed, heading, coordinates. It should be made widely known to the entire world that no other type of instruction can come from the outside world to the pilots during an emergency mode. Emergency mode should trigger an automated set of digital instructions to the pilot with the coordinates of the nearest emergency landing zone. The ground should not be able to remotely control the plane in any way so it cannot be coerced into taking any action.
The basic idea is, during an emergency mode, the only possible direction a plane can take is towards the nearest emergency landing area, while the pilots have absolutely no way of ever being aware of what's going on in the main cabin or anywhere else in the world and only know what to do to land the plane, while the ground knows EVERYTHING about what's going on ANYWHERE in the plane in real-time thru sensors and microphones, and heck JUST STICK HIDDEN VIDEO CAMERAS EVERYWHERE on the plane so the ground can also get a live feed of mug shots.
This "emergency mode" I keep referring to, should actually be "terrorist response mode", not just any emergency situation obviously.
I know the following seems a little drastic, costly and prolly impossible to implement, if not flat out whacky, *but* it just may spark some good ideas in the minds of people much smarter than I am.
From looking at the various accounts of what happened, it is obvious the terrorists somehow managed to gain control of the plane. Barring inside jobs from certified airline pilots who would have somehow managed to infiltrate the airlines, and assuming the people initially controlling the planes are the good guys, we should re-think the way PLANES are built and the processes surrounding loading and boarding planes, so that:
Pilots are completely isolated from the rest of the plane in their cockpit
The cockpit should be a freakin' BANK VAULT: impossible to force open, shoot down or destroy.
Only way to get in or out of the cockpit should be through some highly sophisticated authentication protocols using digital access codes, finger prints, voice, access card, keys, whatever.
Pilots should have everything they need in a cockpit to hold a freakin' siege, it should be highly comfortable and allow them to go thru a whole flight without ever having to leave their place.
Pilots should be escorted on the ground to their cockpit and from their cockpit to the outside by a heavily armed law enforcement body, after thorough extra identity check, maybe involving fingerprints. Airlines could store all of their pilots' fingerprints on-file, along with everything they know about their lives, along with a very comprehensive set of mug shots of the pilot. When picking-up and escorting a pilot to their destination, law enforcement agents could carry a little device on which the pilots would put place their thumb, scan the finger print, compare it with what's on file and establish a first positive identification, AND bring to the screen PICTURES, face AND profile of the pilot, so the law-enforcement agent can establish a second positive identification AND visually ensure he's escorting the right person. The identification device should be linked at all times to a central computer system on which all pilots would be pre-programmed to their assigned flight in advance. Only the pre-programmed pilots should be able to get escorted to the plane.
All flight attendants should carry at all times some sort of remote "panic" trigger that would instantly put the plane in emergency mode, and isolate the cockpit with the pilots from any sound going on in the main cabin so they can't be coerced into some destructive actions. The panic button should also instantly trigger notifications to ground-based crisis-handling agencies
Supplement the "black box" with a comprehensive network of microphones throughout the plane that could be instantly turned on in crisis-mode and relay any sound on the plane to the ground agencies BUT NOT the cockpit.
It's gotta be a coincidence, yet the subject of the message being 911 as in 09/11, seems kinda disturbing. I found that thru google searches while trying to gather stuff about today's events.
take a look at my comment, you could basically spend a couple days to a coupl weeks max building a trivial to complex tool to edit all your documentation:) drop me a mail at valmont|at|wildstar|dot|net if u want more info. good luck:)
I work at an ISP... (not AOL, not MSN) We have a whole department who's in charge of writing up procedural documentation, walkthroughs, how-to's, FAQ's, to solve just about any problem you could ever encounter on almost any platform and operating systems under the sun on your way to getting connected to the internet.
As soon as XML standards and derived technologies and languages (XSLT, DOM, and more) started to be strongly established nearly 2 years ago, we moved whatever existing documentation we had into XML, conforming to internally developed DTD's and specs, after a couple guys and I built a handy HTTP-based authoring tool that leverages technologies built-in Internet Explorer 5.0 which I've previously described right here, allowing writers to not have to know anything about XML, and simply click their way thru easy interactive forms, in a fairly compelling user interface...
With all of our information stored in XML, we can easily present it to various audiences, may it be our members who can search it by keywords to help themselves in our online support area or our technical support reps who can browse directory trees to specific XML documents and have access to more detailed information about hardware and platform configurations, document revision information and more.
The bottom line is this system works really well. And we have the amazing peace of mind of having GREAT information in a format that can never become completely obsolete, and that is always a couple XSLT stylesheets away from fitting just about *any* need.
Whether you make up your own DTD's or follow existing standard DTD's like DocBook mentioned in other posts, as long as you put some thought into structuring your XML data at the beginning, you can only win in the long run: XML documents can easily be processed into other XML DTDs/formats to represent the information in a way that better fits another application, and/or transformed into other documents made of a markup language meant for presentation like HTML or WAP.
please mod that comment about Sash way up. It is highly relevant. This is an IBM project started a few years ago for rapid development of desktop applications using a number of WWW standards and unifying some popular programming languages.
It hurts me to say it, but Microsoft Internet Explorer 5.0 and all subsequent releases of the browser do incorporate a lot of the functionality Curl claims to have.
IE 5.0 was way ahead of its time with support for XML parsing, XML DOM, XSL-T, XML Schemas on top of the usual very strong support for Cascading Stylesheet, JavaScript and VBScript, HTML DOM and HTML 4.0.
Since the W3C was taking forever to release the definitions of what are now well-established standards, IE5.0's XML-technologies were mainly based on microsoft-defined standards which were already pretty close to standards in the making within the W3C. All those components were part of what was called "MSXML 2.5".
What did that platform give you? Absolutely *everything* you need to build an entire very complex browser-driven application, whose main functionality would live on the client rather than the server. This means that once you "loaded" a "page", you could interact with form inputs, links or anything else on the page, and see changes being reflected "on-the-fly" on the presentation layer while also affecting an in-memory XML DOM representing some user-specific XML data.
Shortly after IE5 came out, the company I work for wanted to build a comprehensive platform for technical writers to build "walkthroughs, FAQs, and HOW-TO's" pieces of documentation. They wanted that documentation to be stored in an XML format so it could be saved in a platform/presentation-neutral way, so it could be represented in various ways internally as well as externally to the company's millions of customers as a big "knowledge base".
The traditional way to build such a platform would have been to hire a couple of Java or C++ programmers who would manually create complex GUI components to give the application the interactivity and intuitivity it needs on top of a complex data-handling layer. You're talking about months and months of design and hard-core coding. They wanted it done it 3 weeks. So I said a couple of guys and I could make it all work within IE5 and a couple perl scripts on the server. All the GUI components would be built using HTML 4.0 and CSS. The data layer would be handled with IE5' support for XML parsing and XML DOM. Interaction between user, GUI and data would be handled via JavaScript and HTML events. Once a user would be done editing a piece of documentation, hitting the "save" button would simply HTTP POST an XML string to a perl script which would save all that into a file into some well-defined directory structure.
So we made it happen. Granted I didn't sleep much for a while due to the countless feature creeps that turned the application into a very complex one. But it's very cool and it works really well.
The tech writers have built well over 3000 pieces of documentation used company-wide and by our users. All that documentation is in XML and usually presented in various HTML formats for the various audiences, thru series of batch XSL-T processing.
Since then Microsoft has released "MSXML 3.0" which is a pretty-much standards-compliant version of all the XML technologies supported by IE. I'm not sure they're 100% yet but it's pretty darn close. And I believe the upcoming IE6.0 will be even more standards-compliant.
The main drawback of this plaform is that all those cool features currently only work in IE5+ for windows, the Mac version doesn't support all that stuff yet.
Microsoft should look into turning all those IE5-specific features into a separate browser plug-in that could work within other browsers. Still, in light of all this, Curl doesn't impress me too much yet.
user input validation is not the *only* thing you can do with javascript to minimize server-side processing and save precious CPU cycles. But i'd be revealing trade secrets if i told you what else.
I wonder if voice portals like Hey Anita! will leverage this cool new technology, 'cuz last time I checked most text to speech engines out there could use some serious help.
See comment #85 below, but keep in mind that most people do have javascript enabled, that javascript is a good thing to have enabled as it can often save a lot of unnecessary client-server requests and greatly improve a site's usability.
The danger comes from sites that base their authentication schemes on persistent cookies after the user has signed-on once.
Such cookie basically tells the server "hey i'm the right guy now gimme my personalized page".
You can use javascript to sniff the cookie via document.cookie and send that value to a cgi script that'll store it.
Some prominent web-based email sites like hotmail had a similar security-hole in their "dictionary" feature, which would allow a malicious user to paste an apparently harmless link in an email, because the link would be within the hotmail domain.
Once the user would click on that link, it would take them to the spell-checker interface of hotmail, but the 'word' passed to that CGI is actually HTMLcode that gets "echo'ed" as part of the "result page", just like any dictionary interface would do. That HTML code could be a SCRIPT tag downloading a.js javascript file from the perpetrator's server (to keep it clean) which could very well sniff a user's document.cookie and change the location of some hidden image on the page or pop a window by making an HTTP request to some evil CGI and passing the value of that document.cookie string as a parameter and store it in some text file.
The victim's cookie string most likely contains information that tells the server "hey i'm authenticated" so all it takes is for the evil person to reproduce that cookie.
As I browse the web, I find such vulnerabilities on member-driven sites all the time, some times I warn the webmaster, some times I don't bother, but it can potentially be pretty nasty. I even got a t-shirt from some mildly popular online community fedexed to me once after I rode their asses likes a madman so they'd finally plug a really *really* bad similar hole.
I found one in some remote feature of yahoo a few weeks ago, but its very small and I doubt anyone else would find it.
The rule of thumb to always follow as you design your web application, is "what is that HTML i'm sending to the user made of?". "is there any content in there that is taken from any kind of user input?". "if yes, am I filtering out all angled brackets?". "if i am allowing for user-input HTML content, am i filtering all unnecessary tags and among the tags i'm allowing am i filtering all unnecessary attributes (onload,onmouseover,onclick)?"
OK I've really had it with irresponsible IT personel unable to plug blatant security holes.
I've seen many entities out there like "Trust-e" which review privacy practices and policies for e-commerce sites, but I really don't think any of them out there is big on auditing network and systems security practices. Even if they do, those companies are hired at-will by the sites conducting e-business to give themselves more credibility.
Face it people, I really am starting to believe that statements like "This is a secure site because it uses SSL and strong encryption and... [insert heart-warming buzzwords here]" are nowadays flat out lies for too many e-commerce sites. Those sites are not secure. They store passwords and social security numbers in clear text in databases that reside on the same machine as the web server, which prolly runs way more services than it really needs to because "hey, we can get a pretty fast server up and running in no time and for really cheap, by getting ourselves a cheap pentium and sticking red hat linux on it". "OK, well it looks like the red-hat installation went fine... let's connect to localhost on port 80... ooo see the pretty Apache default page? Great! Well Sir, looks like we're good to go and ready to stick a shopping cart on this puppy!"
The danger doesn't lie in "packet sniffing" anymore. There has been such a hype over the whole "eavesdropping" over a transaction as it is being made, that it looks like this is the only thing irresponsible systems administrators ever worry about: "Well, we need a secure server that does that SSL thing. To do that we need to shell out a couple hundred bucks and apply for a Verisign ID so people don't get nagged by their browser when they hit our site. Verisign will tell people we are who we say we are."
Big deal. Am I supposed to feel good now? In light of what I've been reading for the past few years... I'll say NO.
The danger truly lies in HOW and WHEREsensitive consumer data is being stored. *This* is what matters and what should get thoroughly audited.
If a site possesses an SSL certificate from Verisign, it should be illegal for the owners of this site to request a consumer's highly-sensitive,permanent and personal data like a Social Security Number (credit card numbers don't apply here as those can easily be changed), unless their SSL certificate also comes with some kind of SEAL of approval from some government-sponsored network and systems security auditing.
I do realize I'm going a little far with government involvment, but we're talking about protecting data issued to every citizen by the government in the first place. You're talking about people's lives: their ability to buy a house, open a 401k account, even get work! I have been victim of identity theft in the past after my mail was stolen, fortunately it didn't go too far as I think they didn't get their hands on my SSN, but it truly poisoned my life for a while. I came back from christmas vacation only to find someone had gone on a shopping spree courtesy of me with several of my credit cards and realized they had applied for and shopped with a couple others in my name! Yes some credit-yielding entities don't even ask for your SSN to open an account.
If government involvment isn't the solution, then users should somehow get educated and notified with a message along the lines of "Although this site encrypts all its transactions, its network and systems security practices have not been audited by [INSERT GLOBAL ENTITY NAME HERE]-approved party and may be exposed to security holes".
Better yet, the W3C could work on amending the HTML specification to define a new type of form input field: INPUT type="secure-ssn" name="userssn", which browsers would ONLY display if a site's SSL Certificate contains information stating that this site's security practices were audited and approved. If that is the case, the browser could 'automagically' display the field as [][][]-[][]-[][][][] with a 'secure key' near it which could be clicked to explain what this all means, and possibly remove that field from any scripting-bound client-side Document Object Model so that data could not be evilly manipulated within sites open to cross-site scripting vulnerabilities. The browser could further insure that the value of this field could only be submitted to a form whose "action" attribute points to a secure protocol. The browser should have built-in validation of this field to compensate for its lack of access thru scripting. Browsers should not allow this field's value to be pre-populated on page load unlike other input fields so users would have to re-enter their SSN every time they see the field.
Now with that standard special-looking "social security" form input field, people could be educated to only enter their social security number in such an input field. If they do enter their SSN on any other type of form input field, then they should know they're further exposing themselves to identity theft.
These are just initial ideas, but further brainstorming should help finding a solution that would work to protect people's privacy on-line.
Someone should create an HTTP interface to a dmoz XML database, which would allow users to place XPATH queries which would return XML nodesets to the requesting client.
Someone could leverage XML RDBMS like DBXML which is based on the "XML:DB" standard.
If enough people are interested, I could try downloading dmoz myself and "massage" it into some dbxml store on my own system and build a web-based interface to query it, I've just been really busy with other stuff lately though.
If you happen to read this and are interested, shoot me an email at valmont@wildstar.net and we can take it from there.
Slashdot Mirror
Way too many times does this editorial blend two concepts that are quite different:
PRIVACY: What you say only goes to your intended audience, what is meant to be read by you is for your eyes only.
FREEDOM of Speech: Being able to say what you want, where you want.
Restrictions on Privacy for increased safety are in my mind completely acceptable to increase my own Safety and ensure to some extent i'm not guna get blown out of the sky next time i fly. But that doesn't automatically mean my Freedom of Speech will be restricted. I can still talk shit about whoever I want with whomever I want.
I don't give a flying crap if the FBI reads all the steamy erotic emails i've sent to all my lovers. I hope they get off on it. As long as they don't stop me from doing it.
Just *think* what type of information government entities are after: Stuff that may threaten us. They're not trying to profile you. They're not guna sell any of their information to corporations.
I think you have some good ideas (especially recording sounds from the cabin as well as the cockpit if the plane is put in emergency mode - in fact, technology exists today where video could be used too, especially in the cockpit).
Agreed. I'm talking about building new planes. Completely re-thinking their design from the ground-up. And it's obviously not realistic, just like you, I vaguely understand the prohibitive costs. I just want something to be done, as you pointed out, a small subset of those ideas could more realistically be put in place on existing planes, but the key here is to put some *serious* thought about counter-terrorism systems and measures into the next generation of planes, and do whatever is possible to build them and roll them out to mainstream carriers as soon as possible.
another thing ....
Anybody working near a plane, who has the ability to come in and out of plane should be subject to the highest levels of security and background checks and be considered candidates for the highest levels of security clearance, people fit to work at the pentagon. Planes should from now-on be considered as some of the most DEADLY weapons and anything surrounding them should be subject to massive paranoia.
It's simple. You can work on a plane or near a plane, you can work at the pentagon. Law enforcement agencies have your whole life on-file.
ok I agree it's a little extreme but maybe something along those lines could be set-up.
From looking at the various accounts of what happened, it is obvious the terrorists somehow managed to gain control of the plane. Barring inside jobs from certified airline pilots who would have somehow managed to infiltrate the airlines, and assuming the people initially controlling the planes are the good guys, we should re-think the way PLANES are built and the processes surrounding loading and boarding planes, so that:
bleah.
http://groups.google.com/groups?hl=en&threadm=3b9
Here's the link:
http://groups.google.com/groups?hl=en&frame=right
take a look at my comment, you could basically spend a couple days to a coupl weeks max building a trivial to complex tool to edit all your documentation
-c
I work at an ISP ... (not AOL, not MSN) We have a whole department who's in charge of writing up procedural documentation, walkthroughs, how-to's, FAQ's, to solve just about any problem you could ever encounter on almost any platform and operating systems under the sun on your way to getting connected to the internet.
...
:)
As soon as XML standards and derived technologies and languages (XSLT, DOM, and more) started to be strongly established nearly 2 years ago, we moved whatever existing documentation we had into XML, conforming to internally developed DTD's and specs, after a couple guys and I built a handy HTTP-based authoring tool that leverages technologies built-in Internet Explorer 5.0 which I've previously described right here, allowing writers to not have to know anything about XML, and simply click their way thru easy interactive forms, in a fairly compelling user interface
With all of our information stored in XML, we can easily present it to various audiences, may it be our members who can search it by keywords to help themselves in our online support area or our technical support reps who can browse directory trees to specific XML documents and have access to more detailed information about hardware and platform configurations, document revision information and more.
The bottom line is this system works really well. And we have the amazing peace of mind of having GREAT information in a format that can never become completely obsolete, and that is always a couple XSLT stylesheets away from fitting just about *any* need.
Whether you make up your own DTD's or follow existing standard DTD's like DocBook mentioned in other posts, as long as you put some thought into structuring your XML data at the beginning, you can only win in the long run: XML documents can easily be processed into other XML DTDs/formats to represent the information in a way that better fits another application, and/or transformed into other documents made of a markup language meant for presentation like HTML or WAP.
yea. XML is nifty.
IE 5.0 was way ahead of its time with support for XML parsing, XML DOM, XSL-T, XML Schemas on top of the usual very strong support for Cascading Stylesheet, JavaScript and VBScript, HTML DOM and HTML 4.0.
Since the W3C was taking forever to release the definitions of what are now well-established standards, IE5.0's XML-technologies were mainly based on microsoft-defined standards which were already pretty close to standards in the making within the W3C. All those components were part of what was called "MSXML 2.5".
What did that platform give you? Absolutely *everything* you need to build an entire very complex browser-driven application, whose main functionality would live on the client rather than the server. This means that once you "loaded" a "page", you could interact with form inputs, links or anything else on the page, and see changes being reflected "on-the-fly" on the presentation layer while also affecting an in-memory XML DOM representing some user-specific XML data.
Shortly after IE5 came out, the company I work for wanted to build a comprehensive platform for technical writers to build "walkthroughs, FAQs, and HOW-TO's" pieces of documentation. They wanted that documentation to be stored in an XML format so it could be saved in a platform/presentation-neutral way, so it could be represented in various ways internally as well as externally to the company's millions of customers as a big "knowledge base".
The traditional way to build such a platform would have been to hire a couple of Java or C++ programmers who would manually create complex GUI components to give the application the interactivity and intuitivity it needs on top of a complex data-handling layer. You're talking about months and months of design and hard-core coding. They wanted it done it 3 weeks. So I said a couple of guys and I could make it all work within IE5 and a couple perl scripts on the server. All the GUI components would be built using HTML 4.0 and CSS. The data layer would be handled with IE5' support for XML parsing and XML DOM. Interaction between user, GUI and data would be handled via JavaScript and HTML events. Once a user would be done editing a piece of documentation, hitting the "save" button would simply HTTP POST an XML string to a perl script which would save all that into a file into some well-defined directory structure.
So we made it happen. Granted I didn't sleep much for a while due to the countless feature creeps that turned the application into a very complex one. But it's very cool and it works really well.
The tech writers have built well over 3000 pieces of documentation used company-wide and by our users. All that documentation is in XML and usually presented in various HTML formats for the various audiences, thru series of batch XSL-T processing.
Since then Microsoft has released "MSXML 3.0" which is a pretty-much standards-compliant version of all the XML technologies supported by IE. I'm not sure they're 100% yet but it's pretty darn close. And I believe the upcoming IE6.0 will be even more standards-compliant.
The main drawback of this plaform is that all those cool features currently only work in IE5+ for windows, the Mac version doesn't support all that stuff yet.
Microsoft should look into turning all those IE5-specific features into a separate browser plug-in that could work within other browsers. Still, in light of all this, Curl doesn't impress me too much yet.
just think.
The danger comes from sites that base their authentication schemes on persistent cookies after the user has signed-on once.
Such cookie basically tells the server "hey i'm the right guy now gimme my personalized page".
You can use javascript to sniff the cookie via document.cookie and send that value to a cgi script that'll store it.
heh fun.
Once the user would click on that link, it would take them to the spell-checker interface of hotmail, but the 'word' passed to that CGI is actually HTMLcode that gets "echo'ed" as part of the "result page", just like any dictionary interface would do. That HTML code could be a SCRIPT tag downloading a .js javascript file from the perpetrator's server (to keep it clean) which could very well sniff a user's document.cookie and change the location of some hidden image on the page or pop a window by making an HTTP request to some evil CGI and passing the value of that document.cookie string as a parameter and store it in some text file.
The victim's cookie string most likely contains information that tells the server "hey i'm authenticated" so all it takes is for the evil person to reproduce that cookie.
As I browse the web, I find such vulnerabilities on member-driven sites all the time, some times I warn the webmaster, some times I don't bother, but it can potentially be pretty nasty. I even got a t-shirt from some mildly popular online community fedexed to me once after I rode their asses likes a madman so they'd finally plug a really *really* bad similar hole.
I found one in some remote feature of yahoo a few weeks ago, but its very small and I doubt anyone else would find it.
The rule of thumb to always follow as you design your web application, is "what is that HTML i'm sending to the user made of?". "is there any content in there that is taken from any kind of user input?". "if yes, am I filtering out all angled brackets?". "if i am allowing for user-input HTML content, am i filtering all unnecessary tags and among the tags i'm allowing am i filtering all unnecessary attributes (onload,onmouseover,onclick)?"
I've seen many entities out there like "Trust-e" which review privacy practices and policies for e-commerce sites, but I really don't think any of them out there is big on auditing network and systems security practices. Even if they do, those companies are hired at-will by the sites conducting e-business to give themselves more credibility.
Face it people, I really am starting to believe that statements like "This is a secure site because it uses SSL and strong encryption and ... [insert heart-warming buzzwords here]" are nowadays flat out lies for too many e-commerce sites. Those sites are not secure. They store passwords and social security numbers in clear text in databases that reside on the same machine as the web server, which prolly runs way more services than it really needs to because "hey, we can get a pretty fast server up and running in no time and for really cheap, by getting ourselves a cheap pentium and sticking red hat linux on it". "OK, well it looks like the red-hat installation went fine ... let's connect to localhost on port 80 ... ooo see the pretty Apache default page? Great! Well Sir, looks like we're good to go and ready to stick a shopping cart on this puppy!"
The danger doesn't lie in "packet sniffing" anymore. There has been such a hype over the whole "eavesdropping" over a transaction as it is being made, that it looks like this is the only thing irresponsible systems administrators ever worry about: "Well, we need a secure server that does that SSL thing. To do that we need to shell out a couple hundred bucks and apply for a Verisign ID so people don't get nagged by their browser when they hit our site. Verisign will tell people we are who we say we are."
Big deal. Am I supposed to feel good now? In light of what I've been reading for the past few years ... I'll say NO.
The danger truly lies in HOW and WHERE sensitive consumer data is being stored. *This* is what matters and what should get thoroughly audited.
If a site possesses an SSL certificate from Verisign, it should be illegal for the owners of this site to request a consumer's highly-sensitive,permanent and personal data like a Social Security Number (credit card numbers don't apply here as those can easily be changed), unless their SSL certificate also comes with some kind of SEAL of approval from some government-sponsored network and systems security auditing.
I do realize I'm going a little far with government involvment, but we're talking about protecting data issued to every citizen by the government in the first place. You're talking about people's lives: their ability to buy a house, open a 401k account, even get work! I have been victim of identity theft in the past after my mail was stolen, fortunately it didn't go too far as I think they didn't get their hands on my SSN, but it truly poisoned my life for a while. I came back from christmas vacation only to find someone had gone on a shopping spree courtesy of me with several of my credit cards and realized they had applied for and shopped with a couple others in my name! Yes some credit-yielding entities don't even ask for your SSN to open an account.
If government involvment isn't the solution, then users should somehow get educated and notified with a message along the lines of "Although this site encrypts all its transactions, its network and systems security practices have not been audited by [INSERT GLOBAL ENTITY NAME HERE]-approved party and may be exposed to security holes".
Better yet, the W3C could work on amending the HTML specification to define a new type of form input field: INPUT type="secure-ssn" name="userssn", which browsers would ONLY display if a site's SSL Certificate contains information stating that this site's security practices were audited and approved. If that is the case, the browser could 'automagically' display the field as [][][]-[][]-[][][][] with a 'secure key' near it which could be clicked to explain what this all means, and possibly remove that field from any scripting-bound client-side Document Object Model so that data could not be evilly manipulated within sites open to cross-site scripting vulnerabilities. The browser could further insure that the value of this field could only be submitted to a form whose "action" attribute points to a secure protocol. The browser should have built-in validation of this field to compensate for its lack of access thru scripting. Browsers should not allow this field's value to be pre-populated on page load unlike other input fields so users would have to re-enter their SSN every time they see the field.
Now with that standard special-looking "social security" form input field, people could be educated to only enter their social security number in such an input field. If they do enter their SSN on any other type of form input field, then they should know they're further exposing themselves to identity theft.
These are just initial ideas, but further brainstorming should help finding a solution that would work to protect people's privacy on-line.
What do you guys think?
Someone could leverage XML RDBMS like DBXML which is based on the "XML:DB" standard.
If enough people are interested, I could try downloading dmoz myself and "massage" it into some dbxml store on my own system and build a web-based interface to query it, I've just been really busy with other stuff lately though.
If you happen to read this and are interested, shoot me an email at valmont@wildstar.net and we can take it from there.