You know that email you get to confirm subscriptions? It should be in a standard format, containing a public key and an unsubscribe mechanism. That way, mailers would know for a fact that somebody opted-in and could provide an unsubscribe button instead of a spam button.
Perhaps this already exists? I know there are already some standard mailing list mail headers, but I don't think they cover this, do they?
It's more of an issue of *just* criticising, instead of offering constructive opinions. If all you can do is say "this sucks" but not say why or how it can be improved, then I agree, you have no business in software.
No, that's not criticising without being constructive, that's just insulting. Just because somebody doesn't tell you how to improve, it doesn't make the criticism invalid. It's perfectly possible to offer constructive criticism without suggesting solutions. Your attitude is typically held by people who don't want to be told they are wrong. It's an easy comeback to ask somebody else to do your job, but it's no excuse. If a critic points out that an interface is confusing, it's the designer's job to fix it, not theirs. Just because the critic isn't a designer themselves, it doesn't make the interface any less confusing.
The Java plugin would be invoked by a page on a completely separate sever (that the attacker controls), with an <object> / <applet> tag.
If the server being attacked specifies that it is an image in the Content-Type header, then a browser should respect that and not pass what is supposedly an image to a Java plugin. If a browser ignores the Content-Type header, then it is in violation of the HTTP 1.1 specification.
The plugin would load from the attacked server (e.g. facebook), and therefore for origin checking purposes it belongs to the attacked server.
It's been a while since I've done anything with Java applets, but I thought that the host restrictions were based on the location of the page and not the applet?
Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain)
If you missed it, that was a thinly-veiled jab at Apache. Check out Bug #13986. You know you aren't doing well when an author of the HTTP 1.1 specification shows up on your bug tracker to post a "WTF?" comment:).
The article was light on details, but it sounds like an extension of a known attack, and if this is the case, then it's not Windows, but Internet Explorer. Internet Explorer ignores the Content-Type header in various circumstances, in violation of the HTTP 1.1 specification.
This matters because services like Facebook serve these fake "images" provided by their users to Internet Explorer and explicitly tell Internet Explorer that they are images. Internet Explorer then happily ignores them and tries to guess what type of file it is on its own. If the file looks a bit like HTML and you click on a link to it, Internet Explorer will happily execute Java and JavaScript on that page within the security context of the domain serving it.
If you've wondered why these types of services force you to save images when you try to view them outside of the context of a web page, now you know why. It's because it's the only reliable way to ensure that Internet Explorer doesn't execute it. Think of it as a straight-jacket to stop a mentally ill person from hurting themselves.
It's okay though, Microsoft are fixing the issue in Internet Explorer 8. By making Internet Explorer respect the HTTP 1.1 specification? Of course not! By adding a new proprietary header attribute.
Polls show the public overwhelmingly doesn't want to be subjected to people talking on their cell phones on increasingly over-packed airplanes.
It's not the government's job to protect people from mild annoyances. If it's really true that the public "overwhelmingly" dislikes this, then that's a market the airlines can capitalise on. The market should solve this, and if it doesn't, tough.
What next? The government monitoring the Internet and fining anybody who says LOL U WAT? 'Cause, you know, that irritates me, and apparently I have the right not to be irritated. Next up: passing the Freedom from Arm Rest Theft act.
If this was truly about piracy and stopping people from infringing copyright, these fascist bastards would stop you from sharing CDs, Vinyl and tapes. Hell they'd bring down radio just to stop you sharing.
Why the hell are they so bent on MP3s?
Can you set up servers to monitor for people sharing CDs, vinyl and tapes? It's a lot more cost effective in terms of expenditure:detection to go after MP3s. I'm sure we'd all like it if grep worked in the real world, but I'm afraid it doesn't. Not for you, not for me, and not for the government.
I'd assume that they'd just hire a couple of models, get them to sign release forms, and use their faces. Which will probably lead to the surreal experience of seeing the same person no matter where you look on Google Street View. A few years from now, there will probably be an FAQ that asks "Who is this guy, and how come you've photographed him all over the world?"
I believe that a matter which many commenters appear to have missed, is that the OP's comments indicated that there was no need to for the techs to look through his database.
I think most people missed that because he never said it. He obviously seems surprised that they didn't ask permission first, and he says that they failed to fix the problem, but he didn't say that the mail problem was unrelated to the database. Obviously the hosting company thought that it could be related to the database, otherwise why would they access it and tell him so? If they just wanted to snoop, they wouldn't have mentioned it at all and he would be none the wiser.
Apparently you didn't even read my post, just picked parts out so you can criticize.
Yes, because I can't possibly have read your post and disagreed with it too, right? Get over yourself.
Only issue I've ever had was a power outage that lasted a good couple hours
Lucky you. Just because the gamble paid off for you, it doesn't automatically mean that it's a good idea to do it.
When you take on the burden of hosting, that involves making sure somebody is around to fix any problems that arise. Sure, you can cut corners and gamble that nothing is going to go wrong, but that's a big risk, and it can result in a lot of stress and downtime.
The 'at home' solution offers total control. If you're making enough money off your clients, it's worth it in my opinion.
So long as "enough money" is enough to employ multiple competent administrators. If a server goes down, somebody needs to bring it back up in a reasonable timeframe. Being on call 24/7 is not fun. What if you are sick or injured? What if you want to go on holiday? As you said, "Yay redundancy!" It's not just hardware that needs redundancy to be reliable, wetware needs it too.
The problem here is that the hosting company was looking at something that was unrelated to their problem (so they assume).
Where does he say that? It's unusual to have mail configuration depend upon a database, but it's not unheard of. For example, the simplest way of setting up a web interface to SpamAssassin is to configure it to read rules from a database. The only thing the Ask Slashdotter says on the matter is:
they had accessed my MySQL database directly and looked at the contents; presumably, in order to tell me what I was doing wrong.
It sounds like he has put some mail-related configuration in his database and they looked at it because his mail wasn't working correctly and they suspected he had screwed it up somehow.
I've never had this happen as far as I know (obviously hosts can snoop without telling you). I'd say that this was quite unusual, if for no other reason that hosting companies rarely help you diagnose problems that are likely of your own making. They'll usually just tell you to revert to a supported configuration.
It seems quite odd that they'd be poking around in your database to debug a mail configuration unless you are doing something unusual. But if it is indeed technically related, I doubt you could support the argument that they shouldn't be inspecting your configuration when you ask them to help you debug something. If the database can cause your problem, then how do you expect them to help you without giving them access to it?
The original quote makes no mention of serverside scripting, it makes mention of a browser. Therefore any reference to javascript is assumed to be executed within a browser.
How do you propose that web developers test server-side scripting? Telnet to port 80 and type the requests by hand?
Yes, you want a web browser when you are writing server-side JavaScript. No, that doesn't mean that it is executing within a browser.
Response, you dont have to use more than 1 browser if you use an OO library
I never said that at all. I disagreed with the assessment that cross-browser JavaScript incompatibilities require developers to write two different scripts, and I said that part of the reason for that was the availability of libraries that mitigate the problems with the DOM.
if you're going to be literal about only needing 1 browser to write javascript (which you arent even doing anymore if you only use an api)
Using an API means that you are no longer using the same language? Now you're just being silly. You aren't arguing because you think you are right, you are just arguing for the sake of it. JavaScript is JavaScript regardless of whether you access the DOM directly or make use of a library. Besides, the DOM is an API, so by your logic, it's pretty much impossible to write JavaScript to execute in a browser at all.
Javascript requires knowledge of a browser's DOM implementation to display anything.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website.
This is a red herring as webites are not the topic
How can it be a "red herring"? What do you even mean by that? If you are talking about browser testing, you are talking about websites. I was pointing out that multi-browser testing isn't as mandatory as Benbrizzi claims because browsers aren't the only place that JavaScript is used.
To display anything at all with javascript requires you to reference the DOM means that they are effectively parts of the same problem.
Please go back and read my comment again, you seem to have completely missed the point of it.
No, you don't need the DOM to display anything with JavaScript. In fact, the DOM isn't going to be much help at all if you aren't running JavaScript inside a web browser. The DOM and JavaScript are two distinct things, and lumbering JavaScript with criticism of DOM incompatibilities is ludicrous in the instances where you are using JavaScript but not the DOM.
Attacking the language as opposed to acknowledging the known problem seems to be your goal.
Dead wrong. If you would care to read my comment properly instead of flying off the handle you might actually see why.
Are you really implying that because someone else has written browser specific routines, that the OP's point:
There are still so many cross-browser incompatibilities with javascript today you pretty much have to write one script for firefox and one for IE each time you code.
is incorrect?
Yes. Very few web developers need to write separate scripts for different browsers these days because of the work that has gone into these libraries.
Might want to check the source of the/. page you're reading before you spout about obsoletion of browser specific javascript.
Browser-specific JavaScript and separate scripts for different browsers are two very different things. Browser-specific JavaScript is mainly done with shims and helper functions these days. Back in the olden days you really did have to write two different scripts.
Call me flamebait or troll if you wish, but facts are facts. It is dangerous to be so trusting and most Flash is just a waste of bandwith especially to those customers furthest from the big stores and stuck on dialup.
Okay, you're a troll. What does checking in Firefox have to do with server-side or desktop JavaScript that isn't even designed to run in a browser? What "trust" do you think is dangerous here and what does your opinion of Flash being a waste of bandwidth have to do with it?
You need waaay more thane ONE browser to write JavaScript.
Not all JavaScript is intended to be executed in browsers. Server-side JavaScript was introduced a year after client-side JavaScript, and desktop scripting in JScript has been available in Windows for a decade as part of Windows Scripting Host.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website. These are two very distinct things.
There are still so many cross-browser incompatibilities with javascript today you pretty much have to write one script for firefox and one for IE each time you code.
Actually, there are very few incompatibilities between JavaScript implementations. It's the DOM that is the cause of most incompatibilities, and all the major libraries like jQuery, Prototype, etc, abstract those difficulties away. Modern JavaScript development is not a case of writing two different scripts. In fact, even without the help of libraries, that style of development was mostly obsoleted when Netscape 4 died.
There are better ways to apologize than to escape prison!
Of course there are. He should email everybody to apologise!
Hello, this is Edward 'Eddie' Davidson, a.k.a. Spammy Dude. The court has ordered
me to email every person on the Internet to apologize for my spam scam.
I'm sorry. If you can find it in your heart to forgive me, send one
dollar to Sorry Dude, 742 Evergreen Terrace, Springfield. You have the
power.
"Incremental, fast and includes clients" certainly has the risk of scope creep, but with proper change management, that can be mitigated. The benefit, however, is transparency. You don't get the developers going off and wasting lots of time building the wrong thing. You don't get a continual state of development where it's never production-ready. The end effect is that it breeds a culture where you get used to delivering production-quality code. It sounds pathetic, but that's actually a rare skill. There's far less opportunity to dig yourself into a deep hole of failure, because as soon as you get a few inches down, the clients start complaining and your management can't make excuses.
Furthermore, we've spent so much time training users to ignore messages that say "Your $FOO is out of date! Click here to install the latest version because it's almost always malware, and now you want to turn around and do the exact opposite?
Sure. Because if they don't update, then the malware gets in anyway, because they are undoubtedly using a browser with known vulnerabilities. The worst case scenario is the same in both cases, so we might as well pick the one where they at least have a chance at fending off the malware.
No, this isn't an issue with Google. A search engine's job is to index things it finds on the web. If you put something on the web without any kind of password protection, then don't be surprised if it ends up being indexed by search engines. Just because you don't consider it an "official" part of your website because there isn't a link to it on your homepage, it doesn't mean that's true.
Incompetent web developers have been complaining about this for as long as search engines have been around. It's not an issue unique to the Google web toolbar either. You can get tripped up, for example, if a "secret" page linked elsewhere. The URL of the secret page gets sent as a Referer header, and may end up appearing in a log summary, which may or may not be public.
Bottom line: if you want something to be secret, a randomised URL is not enough. You need to actually put some kind of password protection on it.
Slashdot Mirror
You know that email you get to confirm subscriptions? It should be in a standard format, containing a public key and an unsubscribe mechanism. That way, mailers would know for a fact that somebody opted-in and could provide an unsubscribe button instead of a spam button.
Perhaps this already exists? I know there are already some standard mailing list mail headers, but I don't think they cover this, do they?
No, that's not criticising without being constructive, that's just insulting. Just because somebody doesn't tell you how to improve, it doesn't make the criticism invalid. It's perfectly possible to offer constructive criticism without suggesting solutions. Your attitude is typically held by people who don't want to be told they are wrong. It's an easy comeback to ask somebody else to do your job, but it's no excuse. If a critic points out that an interface is confusing, it's the designer's job to fix it, not theirs. Just because the critic isn't a designer themselves, it doesn't make the interface any less confusing.
If the server being attacked specifies that it is an image in the Content-Type header, then a browser should respect that and not pass what is supposedly an image to a Java plugin. If a browser ignores the Content-Type header, then it is in violation of the HTTP 1.1 specification.
It's been a while since I've done anything with Java applets, but I thought that the host restrictions were based on the location of the page and not the applet?
If you missed it, that was a thinly-veiled jab at Apache. Check out Bug #13986. You know you aren't doing well when an author of the HTTP 1.1 specification shows up on your bug tracker to post a "WTF?" comment :).
The article was light on details, but it sounds like an extension of a known attack, and if this is the case, then it's not Windows, but Internet Explorer. Internet Explorer ignores the Content-Type header in various circumstances, in violation of the HTTP 1.1 specification.
This matters because services like Facebook serve these fake "images" provided by their users to Internet Explorer and explicitly tell Internet Explorer that they are images. Internet Explorer then happily ignores them and tries to guess what type of file it is on its own. If the file looks a bit like HTML and you click on a link to it, Internet Explorer will happily execute Java and JavaScript on that page within the security context of the domain serving it.
If you've wondered why these types of services force you to save images when you try to view them outside of the context of a web page, now you know why. It's because it's the only reliable way to ensure that Internet Explorer doesn't execute it. Think of it as a straight-jacket to stop a mentally ill person from hurting themselves.
It's okay though, Microsoft are fixing the issue in Internet Explorer 8. By making Internet Explorer respect the HTTP 1.1 specification? Of course not! By adding a new proprietary header attribute.
It's not the government's job to protect people from mild annoyances. If it's really true that the public "overwhelmingly" dislikes this, then that's a market the airlines can capitalise on. The market should solve this, and if it doesn't, tough.
What next? The government monitoring the Internet and fining anybody who says LOL U WAT? 'Cause, you know, that irritates me, and apparently I have the right not to be irritated. Next up: passing the Freedom from Arm Rest Theft act.
Can you set up servers to monitor for people sharing CDs, vinyl and tapes? It's a lot more cost effective in terms of expenditure:detection to go after MP3s. I'm sure we'd all like it if grep worked in the real world, but I'm afraid it doesn't. Not for you, not for me, and not for the government.
I'd assume that they'd just hire a couple of models, get them to sign release forms, and use their faces. Which will probably lead to the surreal experience of seeing the same person no matter where you look on Google Street View. A few years from now, there will probably be an FAQ that asks "Who is this guy, and how come you've photographed him all over the world?"
I think most people missed that because he never said it. He obviously seems surprised that they didn't ask permission first, and he says that they failed to fix the problem, but he didn't say that the mail problem was unrelated to the database. Obviously the hosting company thought that it could be related to the database, otherwise why would they access it and tell him so? If they just wanted to snoop, they wouldn't have mentioned it at all and he would be none the wiser.
Yes, because I can't possibly have read your post and disagreed with it too, right? Get over yourself.
Lucky you. Just because the gamble paid off for you, it doesn't automatically mean that it's a good idea to do it.
When you take on the burden of hosting, that involves making sure somebody is around to fix any problems that arise. Sure, you can cut corners and gamble that nothing is going to go wrong, but that's a big risk, and it can result in a lot of stress and downtime.
Yes, which means that they failed to correct the problem, not that the database was unrelated to the mail problem.
So long as "enough money" is enough to employ multiple competent administrators. If a server goes down, somebody needs to bring it back up in a reasonable timeframe. Being on call 24/7 is not fun. What if you are sick or injured? What if you want to go on holiday? As you said, "Yay redundancy!" It's not just hardware that needs redundancy to be reliable, wetware needs it too.
Where does he say that? It's unusual to have mail configuration depend upon a database, but it's not unheard of. For example, the simplest way of setting up a web interface to SpamAssassin is to configure it to read rules from a database. The only thing the Ask Slashdotter says on the matter is:
It sounds like he has put some mail-related configuration in his database and they looked at it because his mail wasn't working correctly and they suspected he had screwed it up somehow.
I've never had this happen as far as I know (obviously hosts can snoop without telling you). I'd say that this was quite unusual, if for no other reason that hosting companies rarely help you diagnose problems that are likely of your own making. They'll usually just tell you to revert to a supported configuration.
It seems quite odd that they'd be poking around in your database to debug a mail configuration unless you are doing something unusual. But if it is indeed technically related, I doubt you could support the argument that they shouldn't be inspecting your configuration when you ask them to help you debug something. If the database can cause your problem, then how do you expect them to help you without giving them access to it?
He didn't. The DOM includes events.
How do you propose that web developers test server-side scripting? Telnet to port 80 and type the requests by hand?
Yes, you want a web browser when you are writing server-side JavaScript. No, that doesn't mean that it is executing within a browser.
I never said that at all. I disagreed with the assessment that cross-browser JavaScript incompatibilities require developers to write two different scripts, and I said that part of the reason for that was the availability of libraries that mitigate the problems with the DOM.
Using an API means that you are no longer using the same language? Now you're just being silly. You aren't arguing because you think you are right, you are just arguing for the sake of it. JavaScript is JavaScript regardless of whether you access the DOM directly or make use of a library. Besides, the DOM is an API, so by your logic, it's pretty much impossible to write JavaScript to execute in a browser at all.
How can it be a "red herring"? What do you even mean by that? If you are talking about browser testing, you are talking about websites. I was pointing out that multi-browser testing isn't as mandatory as Benbrizzi claims because browsers aren't the only place that JavaScript is used.
Please go back and read my comment again, you seem to have completely missed the point of it.
No, you don't need the DOM to display anything with JavaScript. In fact, the DOM isn't going to be much help at all if you aren't running JavaScript inside a web browser. The DOM and JavaScript are two distinct things, and lumbering JavaScript with criticism of DOM incompatibilities is ludicrous in the instances where you are using JavaScript but not the DOM.
Dead wrong. If you would care to read my comment properly instead of flying off the handle you might actually see why.
Yes. Very few web developers need to write separate scripts for different browsers these days because of the work that has gone into these libraries.
Browser-specific JavaScript and separate scripts for different browsers are two very different things. Browser-specific JavaScript is mainly done with shims and helper functions these days. Back in the olden days you really did have to write two different scripts.
Okay, you're a troll. What does checking in Firefox have to do with server-side or desktop JavaScript that isn't even designed to run in a browser? What "trust" do you think is dangerous here and what does your opinion of Flash being a waste of bandwidth have to do with it?
Not all JavaScript is intended to be executed in browsers. Server-side JavaScript was introduced a year after client-side JavaScript, and desktop scripting in JScript has been available in Windows for a decade as part of Windows Scripting Host.
You don't need more than one browser to write a JavaScript program, you need more than one browser to develop a website. These are two very distinct things.
Actually, there are very few incompatibilities between JavaScript implementations. It's the DOM that is the cause of most incompatibilities, and all the major libraries like jQuery, Prototype, etc, abstract those difficulties away. Modern JavaScript development is not a case of writing two different scripts. In fact, even without the help of libraries, that style of development was mostly obsoleted when Netscape 4 died.
Of course there are. He should email everybody to apologise!
"Incremental, fast and includes clients" certainly has the risk of scope creep, but with proper change management, that can be mitigated. The benefit, however, is transparency. You don't get the developers going off and wasting lots of time building the wrong thing. You don't get a continual state of development where it's never production-ready. The end effect is that it breeds a culture where you get used to delivering production-quality code. It sounds pathetic, but that's actually a rare skill. There's far less opportunity to dig yourself into a deep hole of failure, because as soon as you get a few inches down, the clients start complaining and your management can't make excuses.
Sure. Because if they don't update, then the malware gets in anyway, because they are undoubtedly using a browser with known vulnerabilities. The worst case scenario is the same in both cases, so we might as well pick the one where they at least have a chance at fending off the malware.
Both excellent books for this situation, in my opinion.
No, this isn't an issue with Google. A search engine's job is to index things it finds on the web. If you put something on the web without any kind of password protection, then don't be surprised if it ends up being indexed by search engines. Just because you don't consider it an "official" part of your website because there isn't a link to it on your homepage, it doesn't mean that's true.
Incompetent web developers have been complaining about this for as long as search engines have been around. It's not an issue unique to the Google web toolbar either. You can get tripped up, for example, if a "secret" page linked elsewhere. The URL of the secret page gets sent as a Referer header, and may end up appearing in a log summary, which may or may not be public.
Bottom line: if you want something to be secret, a randomised URL is not enough. You need to actually put some kind of password protection on it.