Today the devs want to be able to request a ping. Tomorrow they'll want more.
That smells like a slippery slope argument to me. That said, it's still wrong.
See, this is a "ping" in the logical sense: "Notify me". It's just another HTTP request, the same as a request for an image or page, except that the results aren't used as part of the rendering process. It's not a ping in the sense of "invoke some arbitrary non-browser-related functionality on my system" (as an ICMP ping, or invocation of the OS's ping tool, would be).
You're very adamant that tracking will never go away. Don't you see a problem with that at all? Not even a little? You have absolutely no thoughts that maybe, just maybe, this whole internet tracking thing has gone just a little too far?
No, I don't. Part of that is because I know exactly what level of tracking is possible; what its limitations are; and how to circumvent it. It's very much overblown, as security issues go -- the only aspect that's even remotely worrisome is tracking cookies from major advertisers, and those aren't as big of a risk as they're made out to be either.
And what of the next step? Can I change the request for a ping to a an xhost?
Umm, no, you can't. And why can't you? Because those of us who actually know how this stuff works know where to draw a line. See, when you don't understand the things you're afraid of, it's easy to argue "slippery slope" -- one thing that smells like a security violation isn't all that different from another thing that smells like a security violation. On the other hand, when you know computer security (and I do -- it's a very big part of my job, and I take it very seriously), it's very easy to see when the line has been crossed and when it hasn't. ActiveX crosses the line. Invoking arbitrary 3rd-party tools or code obviously crosses the line. An HTTP ping doesn't even invoke your system ping tool -- it just sends a new HTTP request. No non-browser code is ever invoked; no non-TCP connections are ever made; it's just one more HTTP request coming from your browser. I realize this, and the Mozilla folks realize this -- that's why they were willing to accept it.
How much further towards a Linux ActiveX implementation do you want to go before even you decide that, from a security standpoint, this is obviously circumventing delineations between my system and your system?
Adding yet another tag which causes a web browser to make a HTTP request is in no way, shape or form any kind of a step towards "a Linux ActiveX solution".
Today it's ping. Tomorrow the internet becomes pay per click, or the browsers will provide the pages with an entire shell to play with.
There's a reason that logic classes teach "slippery slope" as a fallacy.
At least with javascript and a href you can lie and say you're not tracking the users. With ping the plausible deniability goes to zero pretty fast.
Do you want to be lied to? With ping you can tell which requests are tracking the users and which ones are providing content, and you can turn off the ping requests with a simple switch in your browser. With a HREF, you can't.
You have not given a single example of any web functionality, from the user's perspective, which would require client side code to facilitate tracking.
What does that have to do with the price of beans?
Admittedly, I see what you're trying to get at: If it doesn't add functionality which is directly relevant to the user, why is it there? Arguing for functionality which is only beneficial to content providers feels a little remnicent of arguing for DRM.
However, tracking assisted by client-side requests is here, and is not going away while the web exists in its current form -- and will almost certainly be more pervasive in whatever form the web takes as it progresses in the future (as such progression will inevitably tend towards offering more functionality, rather than less) It cannot be forced to go away without removing functionality which actually does enhance the user experience -- advanced JavaScript functionality (and thus sites like Google Maps), IMG references to remote servers, so on and so forth. Ignoring that this practice does and will happen just because it disagrees with your philosophy does not and will not change the fact that it exists, and simply prevents you from taking steps -- such as the PING tag -- to minimize its effect.
So -- I haven't provided such an example, but I need not, because supporting HTTP PING is advantageous to the user even if it doesn't directly provide new user-visible functionality.
(And no, the PING tag won't stop the other approaches from working -- but it will make them less desirable: Web sites that render faster result in happier users, and a HTTP PING request requires [slightly, but measurably] less bandwidth than most of the alternatives. Among those sites which decide what HTML to provide to the user based on their user-agent string, and thus which can decide which approach to use based on which one will most likely work on the client in question, I would expect the HTTP PING approach to be readily accepted).
Your use of the term destructive is debatable. There's no clear indication that existing methods are destructive.
They are "destructive" in the following senses:
They allow a 3rd party to track when a page is being loaded. You obviously think this is a bad thing -- if you didn't, you would have no grounds on which to attack the PING approach.
They force the browser's rendering engine to make additional requests before being able to consider a page fully rendered. This inherently slows page render time, period.
They are not easily disabled by the user.
If none of these things are destructive, then the PING approach is also not destructive, since its impact is a subset of the first attribute of the existing approaches: It allows a 3rd party to track when a page is being loaded.
If you can show that the PING approach has any additional impact, then do so; otherwise, you're just trolling (and admittedly, I've bit).
I'd like to kill the discussion since you're sidestepping my point at every turn.
Really? I think I've answered it head-on -- if not here, in our other thread. If I haven't, give me a single sentence which contains your primary point, and I'll explain how and why I've addressed it.
What you've cited is exactly what the Nazis told the people who were being relocated.
Just because bad people use cars sometimes doesn't mean you and I should stop using them. "Do this thing because it's in your best interests" is not an inherently morally bankrupt argument; it's only so when it's being used for a morally bankrupt purpose.
Until and unless you can demonstrate to me that it is morally corrupt to encourage advertisers to stop using transparent GIFs and such for tracking in favor of an alternative which doesn't impact page load times and is easily disabled, I'm going to have trouble swallowing that line of thought.
Again, your entire argument is centered on "it can already be done, so what's wrong with it?"
No, it isn't.
My argument is thus: It already is done in more destructive ways; why not accept a less-destructive (lower-impact, easily disabled) one in its place?
If you don't have this code on your system, you're stuck with the more-destructive approaches; you get longer page load times, can't easily disable the extra requests, and still are being tracked by advertisers.
I have enough of a technical understanding to know that everything which you cite could be done from the server side without embedding easter eggs in the client code for the advertisers to find and use.
First of all, your server side/client side distinction is artificial.
All information leakage happens with the client's involvement. You track the user-info string to determine whether your user has been careless enough to get the CoolWebSearch bar installed in their browser? Well, that information got to the server only because the client volunteered it. You have a image link off to an advertiser's server so they can track your hits? The client's browser, not the web server which is putting up the HTML page, makes that request. You collect clients' IP addresses? That IP address is only accessible to the server because the client made a page request. Every single one of these operations is initiated by the client, just as the PING request is.
Your arguments so far have been,"It can already be done." If so then why do we need yet another way to do it?
Because the other ways make the user's experience worse, whereas this one doesn't. You've asked this question several times, and I've answered it several times. Why do you keep asking?
Why do I, as a user, want to blindly do someone else's work for them without seeing my own benefit?
Because you are seeing a benefit: If you agree to do the work this way, then they won't force you to do it some other way which (1) is harder to circumvent, and (2) delays your page load times. It's in your best interests to play along. Now, certainly you can argue that it would be better if folks didn't bother with any client tracking mechanisms involving extra requests whatsoever -- but it happens anyhow; it's effectively a fact of life at this point; it gives away no information which couldn't be done by more effective server-side log collation anyhow, and technical measures to stop it are impossible to implement without eliminating essential functionality. So: Given that it's going to happen one way or another, it's better if it's done this way instead of via the ways it's already being done right now.
So we're back to this choice: Stick with the existing approaches, which slow your page loads and aren't easy to disable -- or switch to this one, which doesn't impact your page load times and is trivially disabled. Now tell me, which one makes more sense?
Maybe, maybe not. Buggy standards should be rewritten from the ground up if that's what is needed.
My argument is that the standards in question are not buggy -- rather, that the tools they provide in order to give the user good and useful functionality can also be turned towards ill use. Developing a web browser that can't leak information back to the server is analogous to developing a hammer that can't smash someone's skull in: It won't be very good for nails either.
That's just bunk. The issue here is tracking mechanisms embedded in the client application. If you look at my history you'll see that I'm all in favor of whatever they feel like doing on the server side. Put a href wherever you like. If that's enough for tracking then why are all these other vectors needed?
Putting an HREF in is causing the client to take action: In particular, you're asking the client to go and affirmatively download an extra image from the server. If said image contains no useful information, that's exactly the same as doing a separate ping request -- except that you caused the rendering engine to slow down and wait for that image to be retrieved.
The purpose of the extra vector in this case, then, is to have a mechanism that doesn't slow down the rendering engine, because the browser knows it can make that request only after the content needed for page display has already been loaded.
Who is benefitting so greatly from the current insecure implementations that I'm required to behave like a hermit just to stay aware of possible exploitation whether it be computer, social, financial, political, or otherwise?
Who is benefitting? You. When you use Google Maps, you benefit from JavaScript that can make asynchronous (hidden!) calls back to the server. When you use Slashdot, you benefit from having the images loaded off a separate server farm (which can track you just as much as the ping tag can). When you use almost any banking site, you benefit from frames and DIVs (which can be used to cause new, hidden page requests, but also make for a pleasing page layout). Et cetera.
This ping tag gives away no more information than the approaches I mention in the above paragraph (which you say are "server-based" and thus harmless), but it has the additional benefit of not slowing down your browser.
To continue my metaphor (this is the parents checking on the kids when everything goes quiet): Your protests sound very similar to,"Nothing Dad. We're just reading." while carefully tucking something under the bed.
Given that your argument seem to be based on a presumption that a ping tag gives away more information than a IMG HREF can, I claim that the assertions on which your core argument is based are factually incorrect. Until you can explain how your argument is based on real, genuine facts about the technology in question, I'm forced to write this off as baseless paranoia -- and question my continued involvement in this thread.
Give me a genuine, technical explanation of what risks the PING tag adds which wouldn't otherwise exist, and we'll be able to have a real discussion -- talking not about what the other person "sounds like", but actually discussing the merits and faults of the technology in question.
You say there's no good way to do page hit counting on a distributed set of servers.
No, I didn't say that there exists no good way -- but one can be in a situation where, given the infrastructure that one is working within (and the lack of available sysadmin man-hours that many sites need to deal with), there's no easy way to do it. Making everyone who wants something as simple as a page counter have good log collation tools is assinine.
Now, if you're talking about hit tracking (IP addresses), then I must admit that I don't know how much access a page has to the data of the client without relying on a server.
The web server (which is where "the page" comes from, after all) gets the IP address, the name of the browser, the user-info string (which often contains info about what kinds of malware the host machine has installed)... all kinds of ugly stuff. Adding a ping tag exposes absolutely no more information than the web server already has -- it just exposes it to a different place, such as a server that's set up to do log analysis. There's not any additional leakage -- it's just happening to a different place.
There's a real reason behind all of this and the fact that it's so carefully hushed makes it all that much more suspicious. This isn't tin foil. This is the parent checking the kids' room when everything suddenly goes quiet.
I don't think you have enough of an understanding of the technical background for this decision to make that determination.
Precisely why we should not be adding new features to allow the same thing to happen. Instead the devs should be looking back and securing the existing protocols.
Not possible: The "existing protocols" leak information when behaving exactly as designed and specified, and can't be secured without throwing them out and writing completely new standards. That is to say: Improving the implementations of those standards cannot reduce the amount of leakage, because that leakage necessarily occurs when the standard is implemented as designed. That's not important, though, because the leakage in question is not sufficient as to have a significant, non-theoretical detrimental effect on the userbase.
Now, if you think we really ought to write completely new standards that prevent the "immoral" loopholes from being exercised, I urge you to consider some of the consequences:
JavaScript-based requests for XML documents (as those used for most AJAX work) are obviously insecure. Those, and Google Maps, and Flash remoting, and would need to be thrown out.
Requesting that images be loaded from a different server couldn't be allowed -- those are, after all, separate requests, and could be used for tracking purposes. Folks must keep their images and content on the same server, and can't use one server for dynamic content and a dispersed cache farm for static content.
Have a page on your company intranet which pulls up ViewCVS from your CVS server in one frame while keeping the other content loaded off your web server? Nope -- to do this the way you propose, this would need to be disallowed at the protocol level.
And so forth. Revizing HTML and related standards to focus on security in place of functionality -- neutering the Web to minimize the amount of (even harmless) information exposed without user confirmation -- is an absolutely horrid idea. Moreover, even if it were a good idea, it would never be accepted by a public accustomed to having functionality over usability.
So -- if you want to live in that world, here's what you do: Turn off Flash and JavaScript; disable all your browser plugins; disable images; go into the source of your browser and turn off support for frames and DIVs unless you affirmatively choose to load them after seeing their URLs, and go spend time pretending that you've actually bought yourself some level of privacy that's actually sufficient to have any substantial, non-detrimental effect whatsoever on how you interact with the outside world... but please leave the rest of us alone when we're trying to make life better for ourselves. You might want to read Secrets and Lies. One of its themes is the difference between real and merely illusory security; it's something you might do well to grasp.
I think that giving them an alternative to those questionable techniques is a Good Thing.
Further, I'd argue that there's nothing inherently questionable about this tool; it has valid uses. Consider running a page-hit counter on a site whose pages are loaded off a diversely located group of caching servers: If there isn't a mechanism in place to combine the logs off said servers (which there may well not be -- the caches will not infrequently be run by a 3rd party), asking the clients to make an extra request is reasonable. Consider running a Geocities or other free hosting site, where one simply doesn't have access to server logs.
Whatever the reasons, people already cause 3rd-party browsers to make additional requests for logging-related purposes, and they aren't going to stop. Allowing them to do so via a mechanism which (1) is not harmful to the end user's experience, and (2) which can easily be turned off is a large improvement over the present state of affairs.
Would you rather that the questionable techniques in place (those which actually reduce render time and thus inhibit the user experience and are hard to turn off) continue to be employed? By arguing against having a well-documented, easy-to-disable single mechanism for doing this, you're actually increasing the difficulty of preventing your browsing sessions from being tracked.
What functionality does this give to me, as a user, that couldn't be entirely implemented on the server side without requiring anything to happen behind my back?
The alternative is the same stuff happening on the client side, as it is right now, but through more user-hostile means. Think hidden frames and DIVs, transparent GIFs, JavaScript being used to make arbitrary requests, and all that junk.
ping gives a less user-hostile alternative to all of that miscellany -- and one that the users can actually easily turn off. It's a Good Thing. Embrace it.
JavaScript. Invisible frames which load arbitrary pages. All-transparent GIFs. There are tons and tons of tactics which *are already used* to give webmasters the same abilities. PING is just a less-evil way of doing them.
I can't imagine why you couldn't just not fetch any image of 1x1 size? You might have to code an extension, or use proxomitron, but I'm pretty sure you can discriminate by size as to what images to load.
Yes, if you're willing to go out of your way a bit, you certainly can do that -- but it's considerably less smooth than just having this ping setting which can be disabled. (Of course, they can then switch to 10x10 all-transparent GIFs -- which will compress down to not be too much bigger. Yes, you can have a filter that blocks those too... but it's just another arms race, and we don't need those).
It's not that they'd use the ping attribute -- it's that they'd use other tactics to do the exact same thing, but via a mechanism that slows down render time.
Webmasters already have the ability to have a page load cause a HTTP request to some other server -- at minimum, they can just have a . This doesn't impact rendering time (as that single-pixel image does), and has the same effect -- plus you can turn it off, while you can't turn off all the single-pixel images without turning off other images as well.
It's a Good Thing, and I can't help but imagine that most of the people who are so severely against it are just doing so because that's what the almighty slashdot article inferred they should think. Baaaa!
I don't believe so: It contains two complete sentences separated with only a comma. A semicolon or an em dash might make sense, but a comma strikes me as inadequate.
Yes, coal is dirty -- but a large plant can take advantage of economies of scale, making use of scrubbers and secondary heat engines which a vehicle's small plant can't. Thus, a large coal plant will be *vastly* more efficient than a small one -- likely enough of a difference to also make its advantage over a distributed gasoline engine worthwhile.
I believe there's been another reply with a link to actual numbers.
Plug-in hybrids are a lame idea, especially in the US where electricity is more expensive than gasoline.
If the user wishes to run off of electric power as much as possible, drawing off the grid should they be so inclined, why not offer this option? I would anticipate that power generation at a centralized plant (hopefully even after taking distribution losses into account) will generally be more ecologically friendly than doing so from smaller plants optimized for in-vehicle use.
I don't actually think an absolute threshold would necessarily cut it -- in practice, the furthest I can extend my left ring finger with the surrounding fingers fully withdrawn is close enough to the furthest I can withdraw said finger with the surrounding fully extended as to leave some difficulty in interpreting between the two states without using the surrounding fingers as context.
"Computer Scientists can count to 1024 on their fingers" (non-mutant, non-mutilatated, human computer scientists)
Not all permutations of fingers can be held up at a time without substantial discomfort, or (in some cases) far enough to clearly disambiguate between "up" and "down" when surrounding fingers are in the fully opposing state.
Now, this might not be true for you -- but that would make you a mutant.
A copyright covers original bits in the code (comments, or any places where the code itself can be changed without impacting how it does it).
A patent impacts the method the code uses. Independently written code which follows the same algorithms still infringes on the patent.
In cases where a patent describes a method for storing content in a standard format, there may be no reasonable alternate approach to writing data in that format -- in effect, the algorithm may be dictated by the format -- making the patent impact all sane implementations of said format.
Maybe it was something linked from the article rather than the article itself -- but it was made very clear that MSN removed the content themselves, rather than letting it be blocked upstream.
Slashdot Mirror
That smells like a slippery slope argument to me. That said, it's still wrong.
See, this is a "ping" in the logical sense: "Notify me". It's just another HTTP request, the same as a request for an image or page, except that the results aren't used as part of the rendering process. It's not a ping in the sense of "invoke some arbitrary non-browser-related functionality on my system" (as an ICMP ping, or invocation of the OS's ping tool, would be).
Perhaps they should have used a different name.
No, I don't. Part of that is because I know exactly what level of tracking is possible; what its limitations are; and how to circumvent it. It's very much overblown, as security issues go -- the only aspect that's even remotely worrisome is tracking cookies from major advertisers, and those aren't as big of a risk as they're made out to be either.
Umm, no, you can't. And why can't you? Because those of us who actually know how this stuff works know where to draw a line. See, when you don't understand the things you're afraid of, it's easy to argue "slippery slope" -- one thing that smells like a security violation isn't all that different from another thing that smells like a security violation. On the other hand, when you know computer security (and I do -- it's a very big part of my job, and I take it very seriously), it's very easy to see when the line has been crossed and when it hasn't. ActiveX crosses the line. Invoking arbitrary 3rd-party tools or code obviously crosses the line. An HTTP ping doesn't even invoke your system ping tool -- it just sends a new HTTP request. No non-browser code is ever invoked; no non-TCP connections are ever made; it's just one more HTTP request coming from your browser. I realize this, and the Mozilla folks realize this -- that's why they were willing to accept it.
Adding yet another tag which causes a web browser to make a HTTP request is in no way, shape or form any kind of a step towards "a Linux ActiveX solution".
There's a reason that logic classes teach "slippery slope" as a fallacy.
Do you want to be lied to? With ping you can tell which requests are tracking the users and which ones are providing content, and you can turn off the ping requests with a simple switch in your browser. With a HREF, you can't.
What does that have to do with the price of beans?
Admittedly, I see what you're trying to get at: If it doesn't add functionality which is directly relevant to the user, why is it there? Arguing for functionality which is only beneficial to content providers feels a little remnicent of arguing for DRM.
However, tracking assisted by client-side requests is here, and is not going away while the web exists in its current form -- and will almost certainly be more pervasive in whatever form the web takes as it progresses in the future (as such progression will inevitably tend towards offering more functionality, rather than less) It cannot be forced to go away without removing functionality which actually does enhance the user experience -- advanced JavaScript functionality (and thus sites like Google Maps), IMG references to remote servers, so on and so forth. Ignoring that this practice does and will happen just because it disagrees with your philosophy does not and will not change the fact that it exists, and simply prevents you from taking steps -- such as the PING tag -- to minimize its effect.
So -- I haven't provided such an example, but I need not, because supporting HTTP PING is advantageous to the user even if it doesn't directly provide new user-visible functionality.
(And no, the PING tag won't stop the other approaches from working -- but it will make them less desirable: Web sites that render faster result in happier users, and a HTTP PING request requires [slightly, but measurably] less bandwidth than most of the alternatives. Among those sites which decide what HTML to provide to the user based on their user-agent string, and thus which can decide which approach to use based on which one will most likely work on the client in question, I would expect the HTTP PING approach to be readily accepted).
They are "destructive" in the following senses:
If none of these things are destructive, then the PING approach is also not destructive, since its impact is a subset of the first attribute of the existing approaches: It allows a 3rd party to track when a page is being loaded.
If you can show that the PING approach has any additional impact, then do so; otherwise, you're just trolling (and admittedly, I've bit).
Really? I think I've answered it head-on -- if not here, in our other thread. If I haven't, give me a single sentence which contains your primary point, and I'll explain how and why I've addressed it.
Just because bad people use cars sometimes doesn't mean you and I should stop using them. "Do this thing because it's in your best interests" is not an inherently morally bankrupt argument; it's only so when it's being used for a morally bankrupt purpose.
Until and unless you can demonstrate to me that it is morally corrupt to encourage advertisers to stop using transparent GIFs and such for tracking in favor of an alternative which doesn't impact page load times and is easily disabled, I'm going to have trouble swallowing that line of thought.
No, it isn't.
My argument is thus: It already is done in more destructive ways; why not accept a less-destructive (lower-impact, easily disabled) one in its place?
If you don't have this code on your system, you're stuck with the more-destructive approaches; you get longer page load times, can't easily disable the extra requests, and still are being tracked by advertisers.
First of all, your server side/client side distinction is artificial.
All information leakage happens with the client's involvement. You track the user-info string to determine whether your user has been careless enough to get the CoolWebSearch bar installed in their browser? Well, that information got to the server only because the client volunteered it. You have a image link off to an advertiser's server so they can track your hits? The client's browser, not the web server which is putting up the HTML page, makes that request. You collect clients' IP addresses? That IP address is only accessible to the server because the client made a page request. Every single one of these operations is initiated by the client, just as the PING request is.
Because the other ways make the user's experience worse, whereas this one doesn't. You've asked this question several times, and I've answered it several times. Why do you keep asking?
Because you are seeing a benefit: If you agree to do the work this way, then they won't force you to do it some other way which (1) is harder to circumvent, and (2) delays your page load times. It's in your best interests to play along. Now, certainly you can argue that it would be better if folks didn't bother with any client tracking mechanisms involving extra requests whatsoever -- but it happens anyhow; it's effectively a fact of life at this point; it gives away no information which couldn't be done by more effective server-side log collation anyhow, and technical measures to stop it are impossible to implement without eliminating essential functionality. So: Given that it's going to happen one way or another, it's better if it's done this way instead of via the ways it's already being done right now.
So we're back to this choice: Stick with the existing approaches, which slow your page loads and aren't easy to disable -- or switch to this one, which doesn't impact your page load times and is trivially disabled. Now tell me, which one makes more sense?
My argument is that the standards in question are not buggy -- rather, that the tools they provide in order to give the user good and useful functionality can also be turned towards ill use. Developing a web browser that can't leak information back to the server is analogous to developing a hammer that can't smash someone's skull in: It won't be very good for nails either.
Putting an HREF in is causing the client to take action: In particular, you're asking the client to go and affirmatively download an extra image from the server. If said image contains no useful information, that's exactly the same as doing a separate ping request -- except that you caused the rendering engine to slow down and wait for that image to be retrieved.
The purpose of the extra vector in this case, then, is to have a mechanism that doesn't slow down the rendering engine, because the browser knows it can make that request only after the content needed for page display has already been loaded.
Who is benefitting? You. When you use Google Maps, you benefit from JavaScript that can make asynchronous (hidden!) calls back to the server. When you use Slashdot, you benefit from having the images loaded off a separate server farm (which can track you just as much as the ping tag can). When you use almost any banking site, you benefit from frames and DIVs (which can be used to cause new, hidden page requests, but also make for a pleasing page layout). Et cetera.
This ping tag gives away no more information than the approaches I mention in the above paragraph (which you say are "server-based" and thus harmless), but it has the additional benefit of not slowing down your browser.
Given that your argument seem to be based on a presumption that a ping tag gives away more information than a IMG HREF can, I claim that the assertions on which your core argument is based are factually incorrect. Until you can explain how your argument is based on real, genuine facts about the technology in question, I'm forced to write this off as baseless paranoia -- and question my continued involvement in this thread.
Give me a genuine, technical explanation of what risks the PING tag adds which wouldn't otherwise exist, and we'll be able to have a real discussion -- talking not about what the other person "sounds like", but actually discussing the merits and faults of the technology in question.
No, I didn't say that there exists no good way -- but one can be in a situation where, given the infrastructure that one is working within (and the lack of available sysadmin man-hours that many sites need to deal with), there's no easy way to do it. Making everyone who wants something as simple as a page counter have good log collation tools is assinine.
The web server (which is where "the page" comes from, after all) gets the IP address, the name of the browser, the user-info string (which often contains info about what kinds of malware the host machine has installed)... all kinds of ugly stuff. Adding a ping tag exposes absolutely no more information than the web server already has -- it just exposes it to a different place, such as a server that's set up to do log analysis. There's not any additional leakage -- it's just happening to a different place.
I don't think you have enough of an understanding of the technical background for this decision to make that determination.
Not possible: The "existing protocols" leak information when behaving exactly as designed and specified, and can't be secured without throwing them out and writing completely new standards. That is to say: Improving the implementations of those standards cannot reduce the amount of leakage, because that leakage necessarily occurs when the standard is implemented as designed. That's not important, though, because the leakage in question is not sufficient as to have a significant, non-theoretical detrimental effect on the userbase.
Now, if you think we really ought to write completely new standards that prevent the "immoral" loopholes from being exercised, I urge you to consider some of the consequences:
And so forth. Revizing HTML and related standards to focus on security in place of functionality -- neutering the Web to minimize the amount of (even harmless) information exposed without user confirmation -- is an absolutely horrid idea. Moreover, even if it were a good idea, it would never be accepted by a public accustomed to having functionality over usability.
So -- if you want to live in that world, here's what you do: Turn off Flash and JavaScript; disable all your browser plugins; disable images; go into the source of your browser and turn off support for frames and DIVs unless you affirmatively choose to load them after seeing their URLs, and go spend time pretending that you've actually bought yourself some level of privacy that's actually sufficient to have any substantial, non-detrimental effect whatsoever on how you interact with the outside world... but please leave the rest of us alone when we're trying to make life better for ourselves. You might want to read Secrets and Lies. One of its themes is the difference between real and merely illusory security; it's something you might do well to grasp.
I think that giving them an alternative to those questionable techniques is a Good Thing.
Further, I'd argue that there's nothing inherently questionable about this tool; it has valid uses. Consider running a page-hit counter on a site whose pages are loaded off a diversely located group of caching servers: If there isn't a mechanism in place to combine the logs off said servers (which there may well not be -- the caches will not infrequently be run by a 3rd party), asking the clients to make an extra request is reasonable. Consider running a Geocities or other free hosting site, where one simply doesn't have access to server logs.
Whatever the reasons, people already cause 3rd-party browsers to make additional requests for logging-related purposes, and they aren't going to stop. Allowing them to do so via a mechanism which (1) is not harmful to the end user's experience, and (2) which can easily be turned off is a large improvement over the present state of affairs.
Would you rather that the questionable techniques in place (those which actually reduce render time and thus inhibit the user experience and are hard to turn off) continue to be employed? By arguing against having a well-documented, easy-to-disable single mechanism for doing this, you're actually increasing the difficulty of preventing your browsing sessions from being tracked.
The alternative is the same stuff happening on the client side, as it is right now, but through more user-hostile means. Think hidden frames and DIVs, transparent GIFs, JavaScript being used to make arbitrary requests, and all that junk.
ping gives a less user-hostile alternative to all of that miscellany -- and one that the users can actually easily turn off. It's a Good Thing. Embrace it.
JavaScript. Invisible frames which load arbitrary pages. All-transparent GIFs. There are tons and tons of tactics which *are already used* to give webmasters the same abilities. PING is just a less-evil way of doing them.
It's a Good Thing, damnit!
It's not that they'd use the ping attribute -- it's that they'd use other tactics to do the exact same thing, but via a mechanism that slows down render time.
Webmasters already have the ability to have a page load cause a HTTP request to some other server -- at minimum, they can just have a . This doesn't impact rendering time (as that single-pixel image does), and has the same effect -- plus you can turn it off, while you can't turn off all the single-pixel images without turning off other images as well.
It's a Good Thing, and I can't help but imagine that most of the people who are so severely against it are just doing so because that's what the almighty slashdot article inferred they should think. Baaaa!
I don't believe so: It contains two complete sentences separated with only a comma. A semicolon or an em dash might make sense, but a comma strikes me as inadequate.
Yes, coal is dirty -- but a large plant can take advantage of economies of scale, making use of scrubbers and secondary heat engines which a vehicle's small plant can't. Thus, a large coal plant will be *vastly* more efficient than a small one -- likely enough of a difference to also make its advantage over a distributed gasoline engine worthwhile.
I believe there's been another reply with a link to actual numbers.
If you took your entire post, replaced the word "patent" with "copyright" then you'd be correct.
You may not have noticed that what he was doing was suggesting a proposal, as opposed to making a claim with regard to how patent law works presently.
Plug-in hybrids are a lame idea, especially in the US where electricity is more expensive than gasoline.
If the user wishes to run off of electric power as much as possible, drawing off the grid should they be so inclined, why not offer this option? I would anticipate that power generation at a centralized plant (hopefully even after taking distribution losses into account) will generally be more ecologically friendly than doing so from smaller plants optimized for in-vehicle use.
I don't actually think an absolute threshold would necessarily cut it -- in practice, the furthest I can extend my left ring finger with the surrounding fingers fully withdrawn is close enough to the furthest I can withdraw said finger with the surrounding fully extended as to leave some difficulty in interpreting between the two states without using the surrounding fingers as context.
"Computer Scientists can count to 1024 on their fingers" (non-mutant, non-mutilatated, human computer scientists)
Not all permutations of fingers can be held up at a time without substantial discomfort, or (in some cases) far enough to clearly disambiguate between "up" and "down" when surrounding fingers are in the fully opposing state.
Now, this might not be true for you -- but that would make you a mutant.
A copyright covers original bits in the code (comments, or any places where the code itself can be changed without impacting how it does it).
A patent impacts the method the code uses. Independently written code which follows the same algorithms still infringes on the patent.
In cases where a patent describes a method for storing content in a standard format, there may be no reasonable alternate approach to writing data in that format -- in effect, the algorithm may be dictated by the format -- making the patent impact all sane implementations of said format.
Shareholder lawsuits are much harder to succesfully prosecute than common wisdom has it to be.
Maybe it was something linked from the article rather than the article itself -- but it was made very clear that MSN removed the content themselves, rather than letting it be blocked upstream.