If I recall my history, Eisenhower was decent. I read his bio when I was a kid (I read everything I could get my hands on when I was a kid), and he seemed to remember his roots even when he was at the top. Honest Ike. Too bad most governments have failed to heed his warning "May we never confuse honest dissent with disloyal subversion".
Out of curiosity, is there any negative thing you *don't* blame Bush for?
I was hoping the Bush haters would go away now that it's apparent that Obama is almost precisely as useless as Bush was. I'm disappointed to see that's not happening.
which protested that US exports "could be impacted".
Have you seen the US trade deficit lately? The man was trying to save some jobs.
So, instead of encouraging research to develop newer. safer products (which would obviously have a market if the unsafe stuff is banned), it's better to have his oil buddies just keep manufacturing the same old crap.
So, what happens when an offshore competitor develops a replacement? Domestic production craters, and you end up with no jobs AND more imports.
There's a reason we don't allow asbestos (as another example of an unsafe product) to be used in schools, etc., and the ban drove innovation and created new economic opportunities. Your way of thinking, we'd have more cancers.
Yet gender-benders are largely exempt from new EU regulations controlling hazardous chemicals. Britain, then under Tony Blair's premiership, was largely responsible for this - restricting their inclusion in the first draft of the legislation, and then causing even what was included to be watered down.Confidential documents show that it did so after pressure from George W Bush's administration, which protested that US exports "could be impacted".
No show, no show,
Gnome's just like a cheap ho!
Promise a lot, insides all shot,
You'll catch mono!
No show, no show,
To KDE I go!
Looks up to date, not fugly, mate,
Like gnome, you know...
... or this chant...
Gimme a "G"!
"GEE !"
Gimme an "N"!
"ENNN !"
Gimme an "O"!
"OWE !"
Gimme an "M"!
"EMMM !"
Gimme an "E"!
"EEEE !"
What's that spell?
"GNOME'S NO OPTION, MUST EVADE!"
"Huh? It's not dead."
"Sure it is mate."
"It's not. It's... it's pining for the fjords, it is!"
Seriously, I hope they achieve what they want, but they're going to be MIA for a full year...most distros will have shipped at least one version with an even more advanced KDE on them by then.
There have been so many affiliate link hijacks that you can't depend on it. The best thing to do is to find a revenue model that doesn't depend on identifying affiliates. For the affiliate, that's PPV (pay per view), rather than a PPC (pay per click) or PPA (pay per action). Since, as your post points out, it usually takes more than one impression, the affiliate who gets the sale isn't necessary the one who contributed the most to "building up the brand", etc. Plus, advertisers are getting a benefit even if the person doesn't click the ad - their name, logo, product or whatever is still out there, and that has value that isn't compensated in either the PPC or PPA models.
Ditto for the tv, radio, or print media that carry your advertising. They're paid for putting it out there, not for how well it eventually turns out.
This is one reason why in-game advertising is becoming such a big thing - you know who's seeing your ad. You know your audience. You're not getting clicks from useless landing pages that someone accidently came across. Once rewriting content on the client (doing mashups locally, rather than through a server) becomes the norm, most internet advertising is going to quickly die off, since it will be dropped as "not the target content". We'll see several things happen. The disappearance of landing pages, the collapse of sites like facebook (they'll be redundant) and twitter (doubly redundant), the movement of most cloud computing away from servers and into peer-to-peer networks, and search becoming a distributed meritocracy.
Fortunately, it will still be possible to generate ad revenue - just not on the low-level, per click or per view basis.
Liberals want to be liberal with conservative's money, and conservative with liberal's money.
Conservatives want to be conservative with conservative's money, and liberal with liberal's money.
Every "class" or group wants to spend more of other peoples' money, and less of their own, and they all have rationalizations to justify their individual positions.
Me, I'm a true egalitarian - I want to spend EVERYONE's money!:-p
Here, let me fix that for you: Real programmers don't ONLY use php. They can use c, assembler, java, an abacus, or whatever tool is right for the job - even perl...:-)
The ridiculously retarded requirements for hidden inputs in forms in HTML4/XHTML make automating that kind of stuff obnoxious because now your app is inserting a div after every form tag with whatever junk it's supposed to be passing, making it impossible to use "first" child selectors (because whatever div you wrote is magically the second).
Stop being a div diva:-) You can dynamically add the hidden inputs in an onsubmit event handler. Or you can add them to the form in an onload handler. Either way, you control where they end up in the logical hierarchy. Added benefit - no server-side code to generate all the hidden fields, no cluttered-up page.
You don't set a cookie with their opt-out. Opt-out has to be the default (because if they've opted out, you can't set a cookie saying they've opted out). You set a cookie saying they've opted in.
If you read the requirements of section 6 of the rfc (I've linked to it and cut-n-pasted it a few times in this discussion), sites that don't get informed consent before setting a cookie are already non-compliant with the existing standard. If they've consented, from a programming perspective, it's like logging them in. You don't need a user name and password to log someone in - just generate a unique id, store it on the server, and set the cookie. You now have a fully-featured session, not just a cookie. You can set it to expire in so many minutes/hours/days/whatever, expire on browser close, or not expire unless the user logs out. Just inform the user.
Of course, unless you're offering the user some other benefit, they won't accept this. It's up to you to figure out how to make this attractive.
As for google analytics, you need more than cookies - you need javascript enabled, and google analytics slows down page loads enough so that people will sometimes just go elsewhere. In tests using a proxy to rewrite a page and remove the analytics code, I found pages loaded quicker, even taking into account the delay induced by running through a proxy, parsing out the page, and removing google's code. But don't take my word for it - interesting discussion of some issues here..
Tom, Maybe I'm a bit out of date, but can you propose a way to keep the link between an affiliate and a store, BETWEEN browsing sessions? As far as I know, Ajax still isn't going to help there without cookies. Flash cookies are still cookies, and frankly I stay away from them.
I think the more important, and increasing urgent, question is what do we replace the current revenue model with? I don't see it lasting much longer, because of the following:
Ad blocking software is getting more sophisticated, and more widespread,
Click fraud is also getting more sophisticated, and more widespread,
Consumers are getting more jaded, as well as more habituated to being "ad-blind"
Ad prices are currently artificially inflated by google refusing to sell keywords below a certain minimum, providing a false bottom. It's only a matter of time before regulators step in.
Locally-generated (as opposed to hosted) content mash-ups with specs that can be shared among users will have the ability to remove all advertising
#5 is the killer. We can already do this by running a local proxy and modifying content before displaying it. We can also bypass the browser and have the content assimilated, modded, displayed, stored, and shared in, say, a custom java app that other users could directly subscribe to. That's where the REAL "cloud" will be - millions of users' computers sharing data sliced and diced the way people want it. You might like my modded view spec of slashdot better than the "real" one, and I might like some of the custom add-ons you run - and we both might like a sidebar that pulls in relevant journal entries that someone else is running, so we share our "views" in an aggregate "view" - a real mish-mash.
And think about the power of distributed, customized search, where you choose not only the terms and algorithms, but the order of preference for the boxes it runs on (where each box has its' own particular data and peers).
If you've ever played around with modding content via a local proxy, you know how fun it can be. I think my best was fixing up a proxy so that it didn't change anything until you went to google news - then, it replaced on of the stories with a collection of "news articles" saying that police were on the lookout for [insert co-workers' name] as "the suspected phantom shitter" - taking dumps in public places - and if you clicked on any of the related news links, that news source would come up, all legit, except that the headline would again be that they were looking for him:-)
Anyway, back on topic - most web sites are going to have to come up with a better business model than display ads, or "we just got another $50 million of venture capital to burn through" (eg: the twats at Twitter).
Or maybe we'll gradually shift to a distributed net, where everyone is both a client and a server, and anyone who wants free services like web mail or blogs will either host it themselves or on a friends' machine, or both for some redundancy.
As I pointed out, you can also pass it around in a POST variable. Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
You can't link your friend to your cookie.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
Actually, it's a safer option, because you can control, on a page-by-page, object-by-object (page element-by-page element) basis, what gets sent back. It's also possible to do it FASTER - an xmlhttp request, rather than a page load.
Keep trying - eventually, you'll realize that cookies are there for the convenience of the lazy coder, not the end user.
Let it die? Are you serious? Do you know how much FREE content on the internet you consume is paid for by affiliate marketing? It's a lot.
Say goodbye to a TON of homegrown content.
Let me introduce you to my friend AdBlock Plus.
I don't block ads because I want to keep in touch with the latest scams, such as the one currently making the rounds about "get a gov't check by doing this" which basically means "I'm gonna scam you, sucka". This way, when n00bs and rubes tell me about how they are going to cash in on it, I'm ready with the real facts, dug up with a bit of research.
The proper "defense" is to have browsers that don't naively handle content served to them. In other words, just because the server says the content-type is image/jpg doesn't mean the browser should blindly trust it. Same as it shouldn't trust content-length if you want to avoid buffer over/under-runs. A separate domain won't help - an underrun lets me steal the previous contents of the portion of the buffer I haven't written over, so the domain is a non-issue. And an overrun - well, "BAD THINGS(TM)" time.
Browsers should no more trust server data than the server should trust data from the browser.
the server will (probably) say it's content-type is application/zip or similar, and the browser will do whatever it's configured to do for that kind of content.
... and this is broken. Just like the server should not blindly trust user-generated content, the browser should not blindly trust server-generated content. There's no need - it's just sloppy. Just like it shouldn't blindly trust the content-length information and sit there forever if it's wrong - or worse, set a buffer to that size+1 terminating null byte, and then, if the server sends more than the header specified, generate a nice buffer overrun. Or use a buffer underrun to grab data that's sitting in memory.
As I posted elsewhere, the problem is with the browsers. A browser should consistently employ only one technique to decide what type of plugin to run, and it should not allow a file to be mis-identified as two different types of files by using two different validation routines. Cod that allows a file to be identified as an swf in one execution path should not mis-identify the file as a jpg in another path.
... and also arrest the programmers at Moodys, Standard and Poors, Fitch, and AIG. I'm sure they'd be willing to cooperate in return for consideration.
There's one difference between IT and janitors - sometimes the users LIKE their janitors.
Another difference - janitors can drink on the job... oh, wait...
9 similarities and one difference between programmers to janitors:
They both have to clean up shit.
They both aren't really see as all that important until the shit hits the fan.
They're both told it's more important to "just get the job done" and not waste time making sure it's perfect.
The boss always underestimates the length of time it will take to do the job properly
They both instinctively know that PowerPoint makes you stupid
They both have less pr0n and malware on their computers than their boss.
They both understand the importance of "visiting the library" as a temporary reprieve
It might be good enough today, but you know by next week, the guys in marketing will have made a mess of things
They both belivee that if you want something done right, you have to do it yourself.
One important difference: Janitors have better unions. Unlike programmers, janitors have a limit to the amount of shit they have to take from their bosses.
I've been hoping for a long time that there would be some kind of CPA/SPE/bar/board equivalent for both IT and software design and engineering. It would really help our industries so very much. I believe it's only a matter of time before such things are created, but I really wish it would happen sooner rather than later.
No need for all that. We could start with a simple code of ethics. If people adhere to it, they don't need anything else, and if they don't adhere to it, no amount of certification or regulation will help.
It would include such complicated requirements as "Don't pirate shite. Not even good shite." "Don't enable invasion of privacy." "Do encourage open standards instead of shite." "Do document your own shite." "Shite happens is not an excuse." "When you leave a place, leave passwords, code, etc. behind - it's not yours." "NDA term is 1 year from exit. No more, no less."
10 REM BASIC CODE OF CONDUCT (PUN INTENDED)
20 DO NOT SCREW PEOPLE OVER
30 GOTO 10
/* C our new code of ethics */
#include <std/ethics.h>
int main(int argc, char* argv[], char* env[]) {
ethics_init();
ethics_run();
/* insert your code here */
ethics_free();
return NO_ETHICAL_VIOLATIONS_FOUND;
}
#regex code of ethics - see the power of regular expressions!
s/evil/good/gi;
I'd put a java version, butTheNamesOfTheVariousClassesWouldBeTooFuckingLongAndTheMethod-InvocationsAndAllTheTryExceptHandling-WouldBeSooooooooErrorProne-ItWouldBeAnEthicalViolationToDoSo and we'd end up in debugging ecursion hell anyway.
Well, one thing they'd have to learn to do differently is not panic when the power goes off if they're using linux and a journaling file system:-)
I've demonstrated this by telling people to go ahead and yank the plug out of the wall on running machines. They are *so* conditioned to "OMG it's going to take FOREVER to boot again" that I have to pull it, wait a minute, then plug it back in, hit escape so they can see the bootup messages, and show them that the file system check only takes a second or two.
Freaks them out almost every time.
But the kicker is when I log back in and my desktop is the same as when the power went out - including any open apps restored. Very handy when your laptop shuts off because you killed the battery.
The problem is that even the cookie spec says that conforming servers have to obtain informed consent before any use of cookies. This includes disclosing how any 3rd party is using the data. So, unless your rating service is willing to disclose, both to you and the end user, exactly how they collect, analyse, store, forward, archive, and sell the data, your web site isn't in conformance with the spec.
RFC 2965 for cookies says the Europeans are 100% right.
6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.
Quite simply, people have a right to expect that web sites and their operators conform to the RFCs. Privacy is a huge problem, and it's only going to get worse.
And considering what is at stake, the decision to use one rating service over another is unlikely to be based on their technical method of tracking.
Bot traffic is a huge problem, as are pay-to-click scams. Unfortunately, tracking via cookies is an extremely naive way of trying to ferret out either of these problems. Ultimately, if you're suspicious and want to build up a case, you have to go back to the server logs anyway...
unless you on occasion insert a "survey" like the following into the data stream:
Click Subcontractor Performance Survey
We are evaluating the cost/performance of our pay-to-click program. Please choose one of the following options.
[_] I am getting less than 5 cents for every link I click.
[_] I am getting between 5 and 10 cents for every link I click.
[_] I am getting more than 10 cents for every link I click.
[_] I am not being paid when I click on a link.
And for those following along - yes, this actually catches people who are participating in pay-to-click scams - especially if you add a captcha to it to make it look more like you're not just trying to catch the low-hanging morons^fruit. Randomize the order, include hidden values, and you'll even catch some bots.
Feel free to cite me how to use third party tracking without cookies without giving up user security by sending everything in the URI.
Guess what - cookies don't just reside on your machine. They're transmitted with every page request, same as all the POST and GET data. And because even some programmers don't think for two seconds and realize this, they think that cookies are somehow "more secure".
They're no more secure (actually, they're less secure) than POST data. Think about it - POST data has the advantage of not persisting on the host machine between uses, so it's actually more secure than a cookie.
As for 3rd party tracking, there are plenty of ways. Go buy a good book on javascript.
And before you say "they can turn javascript off", that same criticism applies to cookies.
Look, I don't want to be harsh, but the article is uninformed fud, and the european law only codifies what RFC 2965 already mandates.
6. PRIVACY
Informed consent should guide the design of systems that use cookies.
A user should be able to find out how a web site plans to use
information in a cookie and should be able to choose whether or not
those policies are acceptable. Both the user agent and the origin
server must assist informed consent.
So, what's so bad about informed consent? Even the RFC says that both the server and the user agent must enforce this. In other words, you can't just set ANY cookies w/o first getting informed consent, or letting the user choose to opt in/out, or your site doesn't conform to the RFC - it's broken.
Bravo to the Europeans for finally forcing "web designers" to get their act into shape.
Actually, the article is pure junk. There's no such thing as "Sociopathic PowerTalk" outside of what this guy writes. BTW, he really needs to lay off the bong if he thinks "The Office" means anything in "real life". Same as the people who think wresting isn't faked.
Slashdot Mirror
If I recall my history, Eisenhower was decent. I read his bio when I was a kid (I read everything I could get my hands on when I was a kid), and he seemed to remember his roots even when he was at the top. Honest Ike. Too bad most governments have failed to heed his warning "May we never confuse honest dissent with disloyal subversion".
You obviously didn't see my journal entry earlier on, Borat Obama - Change You Can't Believe In. I'll update my sig to make it more visible :-)
Bush was chummy with oil. Obama is chummy with FIRE (finance, insurance, real estate). You know what happens when you play with fire.
It would be nice to see a politician who was more interested in being a friend of the voters for a change.
So, instead of encouraging research to develop newer. safer products (which would obviously have a market if the unsafe stuff is banned), it's better to have his oil buddies just keep manufacturing the same old crap.
So, what happens when an offshore competitor develops a replacement? Domestic production craters, and you end up with no jobs AND more imports.
There's a reason we don't allow asbestos (as another example of an unsafe product) to be used in schools, etc., and the ban drove innovation and created new economic opportunities. Your way of thinking, we'd have more cancers.
FTFA:
No show, no show,
Gnome's just like a cheap ho!
Promise a lot, insides all shot,
You'll catch mono!
No show, no show, ...
To KDE I go!
Looks up to date, not fugly, mate,
Like gnome, you know
Gimme a "G"! ... it's pining for the fjords, it is!"
"GEE !"
Gimme an "N"!
"ENNN !"
Gimme an "O"!
"OWE !"
Gimme an "M"!
"EMMM !"
Gimme an "E"!
"EEEE !"
What's that spell?
"GNOME'S NO OPTION, MUST EVADE!"
"Huh? It's not dead."
"Sure it is mate."
"It's not. It's
Seriously, I hope they achieve what they want, but they're going to be MIA for a full year ...most distros will have shipped at least one version with an even more advanced KDE on them by then.
There have been so many affiliate link hijacks that you can't depend on it. The best thing to do is to find a revenue model that doesn't depend on identifying affiliates. For the affiliate, that's PPV (pay per view), rather than a PPC (pay per click) or PPA (pay per action). Since, as your post points out, it usually takes more than one impression, the affiliate who gets the sale isn't necessary the one who contributed the most to "building up the brand", etc. Plus, advertisers are getting a benefit even if the person doesn't click the ad - their name, logo, product or whatever is still out there, and that has value that isn't compensated in either the PPC or PPA models.
Ditto for the tv, radio, or print media that carry your advertising. They're paid for putting it out there, not for how well it eventually turns out.
This is one reason why in-game advertising is becoming such a big thing - you know who's seeing your ad. You know your audience. You're not getting clicks from useless landing pages that someone accidently came across. Once rewriting content on the client (doing mashups locally, rather than through a server) becomes the norm, most internet advertising is going to quickly die off, since it will be dropped as "not the target content". We'll see several things happen. The disappearance of landing pages, the collapse of sites like facebook (they'll be redundant) and twitter (doubly redundant), the movement of most cloud computing away from servers and into peer-to-peer networks, and search becoming a distributed meritocracy.
Fortunately, it will still be possible to generate ad revenue - just not on the low-level, per click or per view basis.
Cookies have never been necessary; they're mostly for adding persistence between browser instantiations and programmer convenience
Liberals want to be liberal with conservative's money, and conservative with liberal's money.
Conservatives want to be conservative with conservative's money, and liberal with liberal's money.
Every "class" or group wants to spend more of other peoples' money, and less of their own, and they all have rationalizations to justify their individual positions.
Me, I'm a true egalitarian - I want to spend EVERYONE's money! :-p
Here, let me fix that for you: Real programmers don't ONLY use php. They can use c, assembler, java, an abacus, or whatever tool is right for the job - even perl ... :-)
Stop being a div diva :-) You can dynamically add the hidden inputs in an onsubmit event handler. Or you can add them to the form in an onload handler. Either way, you control where they end up in the logical hierarchy. Added benefit - no server-side code to generate all the hidden fields, no cluttered-up page.
Just a thought.
You don't set a cookie with their opt-out. Opt-out has to be the default (because if they've opted out, you can't set a cookie saying they've opted out). You set a cookie saying they've opted in.
If you read the requirements of section 6 of the rfc (I've linked to it and cut-n-pasted it a few times in this discussion), sites that don't get informed consent before setting a cookie are already non-compliant with the existing standard. If they've consented, from a programming perspective, it's like logging them in. You don't need a user name and password to log someone in - just generate a unique id, store it on the server, and set the cookie. You now have a fully-featured session, not just a cookie. You can set it to expire in so many minutes/hours/days/whatever, expire on browser close, or not expire unless the user logs out. Just inform the user.
Of course, unless you're offering the user some other benefit, they won't accept this. It's up to you to figure out how to make this attractive.
As for google analytics, you need more than cookies - you need javascript enabled, and google analytics slows down page loads enough so that people will sometimes just go elsewhere. In tests using a proxy to rewrite a page and remove the analytics code, I found pages loaded quicker, even taking into account the delay induced by running through a proxy, parsing out the page, and removing google's code. But don't take my word for it - interesting discussion of some issues here..
I think the more important, and increasing urgent, question is what do we replace the current revenue model with? I don't see it lasting much longer, because of the following:
#5 is the killer. We can already do this by running a local proxy and modifying content before displaying it. We can also bypass the browser and have the content assimilated, modded, displayed, stored, and shared in, say, a custom java app that other users could directly subscribe to. That's where the REAL "cloud" will be - millions of users' computers sharing data sliced and diced the way people want it. You might like my modded view spec of slashdot better than the "real" one, and I might like some of the custom add-ons you run - and we both might like a sidebar that pulls in relevant journal entries that someone else is running, so we share our "views" in an aggregate "view" - a real mish-mash.
And think about the power of distributed, customized search, where you choose not only the terms and algorithms, but the order of preference for the boxes it runs on (where each box has its' own particular data and peers).
If you've ever played around with modding content via a local proxy, you know how fun it can be. I think my best was fixing up a proxy so that it didn't change anything until you went to google news - then, it replaced on of the stories with a collection of "news articles" saying that police were on the lookout for [insert co-workers' name] as "the suspected phantom shitter" - taking dumps in public places - and if you clicked on any of the related news links, that news source would come up, all legit, except that the headline would again be that they were looking for him :-)
Anyway, back on topic - most web sites are going to have to come up with a better business model than display ads, or "we just got another $50 million of venture capital to burn through" (eg: the twats at Twitter).
Or maybe we'll gradually shift to a distributed net, where everyone is both a client and a server, and anyone who wants free services like web mail or blogs will either host it themselves or on a friends' machine, or both for some redundancy.
As I pointed out, you can also pass it around in a POST variable. Also, if you're using php and the user has cookies disabled, it'll get passed around in the query string anyway.
That just doesn't parse. At all. I can't link my dog to a cookie either - so what?
Actually, it's a safer option, because you can control, on a page-by-page, object-by-object (page element-by-page element) basis, what gets sent back. It's also possible to do it FASTER - an xmlhttp request, rather than a page load.
Keep trying - eventually, you'll realize that cookies are there for the convenience of the lazy coder, not the end user.
Let me introduce you to my friend AdBlock Plus.
I don't block ads because I want to keep in touch with the latest scams, such as the one currently making the rounds about "get a gov't check by doing this" which basically means "I'm gonna scam you, sucka". This way, when n00bs and rubes tell me about how they are going to cash in on it, I'm ready with the real facts, dug up with a bit of research.
The proper "defense" is to have browsers that don't naively handle content served to them. In other words, just because the server says the content-type is image/jpg doesn't mean the browser should blindly trust it. Same as it shouldn't trust content-length if you want to avoid buffer over/under-runs. A separate domain won't help - an underrun lets me steal the previous contents of the portion of the buffer I haven't written over, so the domain is a non-issue. And an overrun - well, "BAD THINGS(TM)" time.
Browsers should no more trust server data than the server should trust data from the browser.
And everyone already knows "FLASH IS EVIL(TM)" :-)
As I posted elsewhere, the problem is with the browsers. A browser should consistently employ only one technique to decide what type of plugin to run, and it should not allow a file to be mis-identified as two different types of files by using two different validation routines. Cod that allows a file to be identified as an swf in one execution path should not mis-identify the file as a jpg in another path.
... and also arrest the programmers at Moodys, Standard and Poors, Fitch, and AIG. I'm sure they'd be willing to cooperate in return for consideration.
That won't happen, because people like Warren Buffett made out like bandits under the bail-out.
Another difference - janitors can drink on the job ... oh, wait ...
9 similarities and one difference between programmers to janitors:
One important difference: Janitors have better unions. Unlike programmers, janitors have a limit to the amount of shit they have to take from their bosses.
No need for all that. We could start with a simple code of ethics. If people adhere to it, they don't need anything else, and if they don't adhere to it, no amount of certification or regulation will help.
It would include such complicated requirements as "Don't pirate shite. Not even good shite." "Don't enable invasion of privacy." "Do encourage open standards instead of shite." "Do document your own shite." "Shite happens is not an excuse." "When you leave a place, leave passwords, code, etc. behind - it's not yours." "NDA term is 1 year from exit. No more, no less."
There ae plenty of examples to draw from.
or, for those who prefer KISS:
10 REM BASIC CODE OF CONDUCT (PUN INTENDED)
20 DO NOT SCREW PEOPLE OVER
30 GOTO 10
#include <std/ethics.h>
int main(int argc, char* argv[], char* env[]) {
ethics_init();
ethics_run();
ethics_free();
return NO_ETHICAL_VIOLATIONS_FOUND;
}
#regex code of ethics - see the power of regular expressions!
s/evil/good/gi;
I'd put a java version, butTheNamesOfTheVariousClassesWouldBeTooFuckingLongAndTheMethod-InvocationsAndAllTheTryExceptHandling-WouldBeSooooooooErrorProne-ItWouldBeAnEthicalViolationToDoSo and we'd end up in debugging ecursion hell anyway.
Well, one thing they'd have to learn to do differently is not panic when the power goes off if they're using linux and a journaling file system :-)
I've demonstrated this by telling people to go ahead and yank the plug out of the wall on running machines. They are *so* conditioned to "OMG it's going to take FOREVER to boot again" that I have to pull it, wait a minute, then plug it back in, hit escape so they can see the bootup messages, and show them that the file system check only takes a second or two.
Freaks them out almost every time.
But the kicker is when I log back in and my desktop is the same as when the power went out - including any open apps restored. Very handy when your laptop shuts off because you killed the battery.
The problem is that even the cookie spec says that conforming servers have to obtain informed consent before any use of cookies. This includes disclosing how any 3rd party is using the data. So, unless your rating service is willing to disclose, both to you and the end user, exactly how they collect, analyse, store, forward, archive, and sell the data, your web site isn't in conformance with the spec.
RFC 2965 for cookies says the Europeans are 100% right.
Quite simply, people have a right to expect that web sites and their operators conform to the RFCs. Privacy is a huge problem, and it's only going to get worse.
Bot traffic is a huge problem, as are pay-to-click scams. Unfortunately, tracking via cookies is an extremely naive way of trying to ferret out either of these problems. Ultimately, if you're suspicious and want to build up a case, you have to go back to the server logs anyway ...
unless you on occasion insert a "survey" like the following into the data stream:
And for those following along - yes, this actually catches people who are participating in pay-to-click scams - especially if you add a captcha to it to make it look more like you're not just trying to catch the low-hanging morons^fruit. Randomize the order, include hidden values, and you'll even catch some bots.
Guess what - cookies don't just reside on your machine. They're transmitted with every page request, same as all the POST and GET data. And because even some programmers don't think for two seconds and realize this, they think that cookies are somehow "more secure".
They're no more secure (actually, they're less secure) than POST data. Think about it - POST data has the advantage of not persisting on the host machine between uses, so it's actually more secure than a cookie.
As for 3rd party tracking, there are plenty of ways. Go buy a good book on javascript.
And before you say "they can turn javascript off", that same criticism applies to cookies.
Look, I don't want to be harsh, but the article is uninformed fud, and the european law only codifies what RFC 2965 already mandates.
So, what's so bad about informed consent? Even the RFC says that both the server and the user agent must enforce this. In other words, you can't just set ANY cookies w/o first getting informed consent, or letting the user choose to opt in/out, or your site doesn't conform to the RFC - it's broken.
Bravo to the Europeans for finally forcing "web designers" to get their act into shape.
Actually, the article is pure junk. There's no such thing as "Sociopathic PowerTalk" outside of what this guy writes. BTW, he really needs to lay off the bong if he thinks "The Office" means anything in "real life". Same as the people who think wresting isn't faked.