Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Sat, Apr 7, 2012 at 10:17 AM, Ian Hickson i...@hixie.ch wrote: In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution is to not use window.open(), which is in any case bad UI. A top-level window is the only context in which you can ask the user to engage in security-sensitive interaction, like entering a password, or making a selection that must not be vulnerable to clickjacking. Then, again, we should fix this at the window.open() level, not the handler level. It's not a problem specific to register*Handler(). The simplest way to address this, which doesn't require any spec changes, is for the opener to tell the window what origin to use, e.g. by opening an iframe to do the work and then having the iframe pop up the window, The browser's popup blocker would block that interaction, unless you require an additional click inside the iframe. UX people are generally fanatical about eliminating extra user clicks. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Right, the obvious thing to do is use the fragment identifier, but that's got some security problems. With a small tweak we can make this safe and easy. I don't understand the security problem. Could you give a concrete example of an attack scenario? It is well-understood that URL fragment messaging is vulnerable to tampering between windows or frames in the browser. Boris already posted further clarifying this point and you seemed to understand. I don't know what you're confused about. I agree that there are ways to use Web technologies that are unsafe. For example, you could just allow people to inject arbitrary markup into your page. What I do not understand here is what the attack scenario is that is specific to register*Handler(), if there is one. For RPH to be used in an offline scenario, the %s argument is put in the URL fragment component of the RPH handler's URL. This means the client page is sending data to the RPH handler using URL fragment messaging. So: offline RPH uses URL fragment messaging. URL fragment messaging is vulnerable to tampering. So, I'm asking that we provide a tamper-proof channel for the client to send data to the RPH handler: namely a new DOM field. Here's another concrete attack scenario showing how this vulnerability could be exploited in a mailto RPH handler. Consider a site that requires a user to confirm a security sensitive operation by sending an email with a confirmation number in the Subject field. The site expects this email to be signed by the user's mail software. The web page that sets up this user interaction includes a mailto link to open a pre-populated email editor. This mailto: link includes a subject parameter that contains the confirmation number. The attacker has previously setup an operation that is waiting on such an email confirmation from the victim user. The attacker has additionally lured the user into browsing the legitimate site in a window that the attacker has a reference to. The attack page waits for an iframe to show up in the legitimate site's frame hierarchy at the place where a mailto RPH confirmation action is being done. The attack page overwrites the iframe's URL fragment with a mailto URL that contains a subject parameter specifying the confirmation number for the operation setup by the attacker, instead of the one that the victim user was setting up. The user sends the email, confirming the attacker's operation, instead of their own. From the user's perspective, they see that they are at the legitimate web site and they setup an operation in the normal way which, as expected, opens an email editor with a confirmation number. The user typically never looks closely at the confirmation number, it's just some number chosen by the legitimate web site. So, everything looks normal to the user. From the perspective of the RPH handler page, everything also looks normal. It opens and finds a mailto URL in the %s position in it's URL fragment. It has no idea that the URL fragment has changed since the legitimate site first specified it. We can fix this by putting the %s data in a DOM field that cannot be overwritten by an attacker in this way. Consequently, the legitimate site can securely pass a confirmation number to the RPH handler. The attacker can still navigate to the mailto URL from one of the attacker's own pages, but can't do it from one of the legitimate site's pages. So the attacker can't make it look like the legitimate site is asking the user to send the confirmation email. The important thing to understand here is that a communication channel that is vulnerable to tampering can be abused in unexpected ways. Rather than quibble about how a future attacker might make use of this
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 9, 2012 at 3:12 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Apr 2012, Tyler Close wrote: The user sends the email, confirming the attacker's operation, instead of their own. From the user's perspective, they see that they are at the legitimate web site and they setup an operation in the normal way which, as expected, opens an email editor with a confirmation number. The user typically never looks closely at the confirmation number, it's just some number chosen by the legitimate web site. So, everything looks normal to the user. From the perspective of the RPH handler page, everything also looks normal. It opens and finds a mailto URL in the %s position in it's URL fragment. It has no idea that the URL fragment has changed since the legitimate site first specified it. It doesn't even have any idea that there is a legit site. The RPH handler doesn't need to know which is the legit site. The RPH handler just needs to know that it's getting the RPH data from the site that the user was interacting with, not some other unseen site running in the browser. Putting the %s data in the window.location lets an attacker overwrite it. The important thing to understand here is that a communication channel that is vulnerable to tampering can be abused in unexpected ways. You don't need to tamper with the communications channel as far as I can tell. If you can navigate an iframe as you describe, then even if the mailto: information is put in the path or query component it would still be possible to do the attack you describe. Just wait for the iframe to appear and then navigate it to the mailto: handler with the parameters you want. That's exactly right! The whole window.location communication path is vulnerable to tampering, so we need some other way to communicate the RPH %s data, such as a DOM field. With appcache fallback, it's not necessary to use only the URL fragment for an offline scenario to work, which makes talking about the URL fragment in this scenario extraneous. Assuming the mailto RPH handler is using appcache with a fallback, this whole scenario works if the %s data is in the path or query. The problem is that the whole window.location is a communication channel that is vulnerable to tampering within the browser. Rather than quibble about how a future attacker might make use of this vulnerability in some future application, the right thing to do is eliminate the vulnerability. I don't see how what you propose eliminates the vulnerability. The vulnerability is that window.location can be overwritten by other code running in the browser. For that reason, I'm proposing we use a different channel to communicate RPH %s data from the client to the RPH handler. I'm swapping in a tamper-proof channel for one that can be tampered with. That window.location is vulnerable to tampering is widely agreed. We should be able to easily agree to not use it when we have a tamper-proof alternative. This should be easy. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 9, 2012 at 4:23 PM, Tyler Close tyler.cl...@gmail.com wrote: On Mon, Apr 9, 2012 at 3:12 PM, Ian Hickson i...@hixie.ch wrote: Just wait for the iframe to appear and then navigate it to the mailto: handler with the parameters you want. That attacker has to navigate the iframe to the RPH handler URL with the embedded mailto URL, not the mailto URL directly. Using the mailto URL directly would cause the browser to run through its RPH code a second time, causing the user to see a second Picker dialog, so the attack is no longer invisible to the user. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 9, 2012 at 4:17 PM, Jonas Sicking jo...@sicking.cc wrote: Why is this so complicated? It seems clear to me that there is a use-case for sending a message to your parent frame, but only wanting to do so when your parent frame is from the same origin as you. I think there's also a use case for securely sending a message to your original window.open()'er, such that it can't be intercepted by any page that can navigate your window.open()'er. That means a page needs to know the Origin of its window.open()'er, which may be different from the page's own Origin. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Apr 2012, Tyler Close wrote: The RPH handler doesn't need to know which is the legit site. The RPH handler just needs to know that it's getting the RPH data from the site that the user was interacting with, not some other unseen site running in the browser. Nothing we have discussed so far would provide such a guarantee. Yes, what I am proposing provides that guarantee. When an iframe is initially navigated to a mailto URL, the browser starts its RPH dispatch logic. In Firefox, this means a Picker dialog is shown and the user selects an RPH handler. The browser then navigates the iframe to the RPH handler URL and, under my proposal, would populate a DOM field containing the mailto URL. If at any point in this sequence an attacker navigates the iframe to a different, non-RPH URL, that page loads and the browser does not populate the RPH DOM field (since it's not an RPH navigation). If the attacker navigates the iframe to another RPH URL, then Firefox will show another Picker dialog, making the attack visible. Alternatively, the browser could refuse to do repeated RPH navigation of the same iframe. The vulnerability is that window.location can be overwritten by other code running in the browser. Then we should fix _that_. I was under the impression that the descendant policy on frame navigation was baked into the Web at this point and could not be changed. We also want RPH dispatch to be secure in cases where the client is an iframe, not a top level page. For example, a widget running on a social networking page should be able to securely send data to a user selected RPH handler. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 26 Sep 2011, Tyler Close wrote:
I was recently experimenting with the registerProtocolHandler (RPH) API
and came across a couple of security gotchas that make it hard to safely
use the API. One of these is already known, but AFAICT, hasn't been
fixed yet. I haven't seen the other discussed yet.
The Mozilla blog post that introduces the registerProtocolHandler API
makes use of window.parent.postMessage to send a response from the RPH
handler back to the client page.
I presume it uses this in conjunction with an a href= link with a
target= attribute to load the handler in an iframe.
The client page loads the handler page using an iframe or a
window.open(). Either can work.
In the example code, the targetOrigin for this postMessage invocation is
'*', while also noting that this is not secure. AFAICT, there is no API
that the intent handler can reliably use to determine the correct
targetOrigin for this postMessage invocation.
How can the origin be anything other than the origin of the page that
triggered the link?
Exactly, but we need a way for the handler page to find out what that origin is.
A client page on origin A causes a navigation to a RPH URL (iframe or
window.open). The browser loads the user chosen RPH handler, which is
another web page from origin B. After the handler page loads, it wants
to send a return value back to the client page. How does the handler
page know the client page's origin is A? It needs to know this origin
string so that it can securely use postMessage to send the return
value back. AFAICT, there is no existing API in the browser that lets
the handler page determine the client page's origin.
I suggest fixing this problem by adding a new readonly DOMString that
contains the correct origin for the postMessage invocation; perhaps
document.origin. So the response invocation would then be coded as:
window.parent.postMessage('my response data', document.origin);
Perhaps a different name or location is better for this field, so I'll
defer to the editor's judgment.
You can work out your own origin from window.location's members, but I
don't see how this helps you determine the origin of your parent. There's
a separate thread about adding a way to obtain your parent's origin, but
again, I don't see why you would need it in this case. Can you elaborate
on what the attack scenario you are envisaging is?
Currently, the handler page can only specify * in the postMessage
invocation that sends the return value. If the client page is
navigated by an attacker, before the postMessage is done, the attacker
can intercept the return value. It's the same rationale used every
time we advise programmers against using '*' as the targetOrigin for a
postMessage() invocation.
The second problem with RPH is that the handler page doesn't have a
way of reliably getting the URL of the content to be handled from the
browser. In order to work in offline scenarios, the RPH handler must
put the %s placeholder in the fragment of its handler's URL.
It's not clear to me that it makes sense to have an offline protocol
handler. What kind of protocol do you have in mind?
For example, consider an offline web mail program. I click on a
mailto: link and want to compose a message in my web mail editor,
queuing it to be sent next time I'm online.
RPH is a way for a web page to send data to a user determined
application. There will surely be many scenarios where offline
functionality is desirable.
Unfortunately, this means that other content in the browser could
modify the content URL before the handler reads it.
Well, any content can load any URL, so it doesn't matter whether the URL
is in the fragment identifier or the path or anything else, surely.
It matters if the handler page assumes that the URL came from its
parent or opener. The parent and opener then engage in a postMessage
conversation where the parent knows it said one thing, but the handler
heard it saying something different, something chosen by the attacker.
For example, an attacker could open a window on a victim web page. The
victim web page then opens an iframe on a content URL that triggers
RPH. The attacker then navigates the iframe so that its
window.location contains a different content URL.
How can the attacker navigate that iframe? Surely it would not be allowed
to navigate it, per the allowed to navigate definition in HTML.
Boris already answered this.
The intent handler sees a request coming from the victim page, but with
a content URL specified by the attacker. A related problem is that the
intent handler has no way to distinguish whether its URL was loaded via
the browser's RPH handling, or whether the client page directly
navigated to the intent handler's URL. Both of these problems could be
fixed by adding another readonly DOMString to the API that contains the
%s data for the RPH invocation.
I
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Fri, Apr 6, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to safely use the API. One of these is already known, but AFAICT, hasn't been fixed yet. I haven't seen the other discussed yet. The Mozilla blog post that introduces the registerProtocolHandler API makes use of window.parent.postMessage to send a response from the RPH handler back to the client page. I presume it uses this in conjunction with an a href= link with a target= attribute to load the handler in an iframe. The client page loads the handler page using an iframe or a window.open(). Either can work. In the example code, the targetOrigin for this postMessage invocation is '*', while also noting that this is not secure. AFAICT, there is no API that the intent handler can reliably use to determine the correct targetOrigin for this postMessage invocation. How can the origin be anything other than the origin of the page that triggered the link? Exactly, but we need a way for the handler page to find out what that origin is. A client page on origin A causes a navigation to a RPH URL (iframe or window.open). The browser loads the user chosen RPH handler, which is another web page from origin B. After the handler page loads, it wants to send a return value back to the client page. How does the handler page know the client page's origin is A? It needs to know this origin string so that it can securely use postMessage to send the return value back. AFAICT, there is no existing API in the browser that lets the handler page determine the client page's origin. Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is navigated? Will the postMessage be delivered or not? But in general, there's not expected to be any talking back. If you want something where the handler talks back to the page that provided the data, then you should use Web Intents. registerProtocolHandler() and registerContentHandler() are intended for things like mail clients (mailto:) or PDF viewers, which do not talk back. Indeed in the common use case, you just click the link and the entire browsing context gets replaced, so there's nothing to talk back _to_. I was prompted to write the original email by a Mozilla blog post that suggested talking back. It also seems bad for web APIs to break under simple composition like this; especially when there's an easy fix available. Currently, the handler page can only specify * in the postMessage invocation that sends the return value. If the client page is navigated by an attacker, before the postMessage is done, the attacker can intercept the return value. It's the same rationale used every time we advise programmers against using '*' as the targetOrigin for a postMessage() invocation. That rationale only applies when you're going from window to window, not when you're going from iframe to parent. The second problem with RPH is that the handler page doesn't have a way of reliably getting the URL of the content to be handled from the browser. In order to work in offline scenarios, the RPH handler must put the %s placeholder in the fragment of its handler's URL. It's not clear to me that it makes sense to have an offline protocol handler. What kind of protocol do you have in mind? For example, consider an offline web mail program. I click on a mailto: link and want to compose a message in my web mail editor, queuing it to be sent next time I'm online. RPH is a way for a web page to send data to a user determined application. There will surely be many scenarios where offline functionality is desirable. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Right, the obvious thing to do is use the fragment identifier, but that's got some security problems. With a small tweak we can make this safe and easy. Unfortunately, this means that other content in the browser could modify the content URL before the handler reads it. Well, any content can load any URL, so it doesn't matter whether the URL is in the fragment identifier or the path or anything else, surely. It matters if the handler page assumes that the URL came from its parent or opener. The parent and opener then engage in a postMessage conversation where the parent knows it said one thing, but the handler heard it saying something different, something chosen by the attacker. Why would a mail client talk back to its opener? It might not, but some RPH handlers will. They've got a postMessage API
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Fri, Apr 6, 2012 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is navigated? Will the postMessage be delivered or not? A task queued on a Document is associated with that Document and can only be processed when that document is active. I'll assume that means it's not delivered, even though postMessage is a method on a Window, not a Document. In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution is to not use window.open(), which is in any case bad UI. A top-level window is the only context in which you can ask the user to engage in security-sensitive interaction, like entering a password, or making a selection that must not be vulnerable to clickjacking. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Right, the obvious thing to do is use the fragment identifier, but that's got some security problems. With a small tweak we can make this safe and easy. I don't understand the security problem. Could you give a concrete example of an attack scenario? It is well-understood that URL fragment messaging is vulnerable to tampering between windows or frames in the browser. Boris already posted further clarifying this point and you seemed to understand. I don't know what you're confused about. Why would a mail client talk back to its opener? It might not, but some RPH handlers will. Why? What's the use case? So, it seems you're arguing that the Mozilla blog post was silly and developers won't try to solve problems that way. Is that so? I don't understand the attack scenario. Sure, a Web page can open another Web page with arbitrary arguments. Why does it matter here? Two reasons: 1. An RPH dispatch is different from a direct load because it communicates a user choice to the RPH handler. I explained above how a handler might use this information. I don't see how this difference affects the security here. Well, perhaps it's not strictly necessary for you to understand it. It's sufficient to understand that we want to enable offline RPH handlers, without using a known bad technique like URL fragment messaging. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: For example, a web mail program might have two registered RPH handlers for mailto: https://example.org/?from=me@companyq=%s; and https://example.org/?from=me@personalq=%s;. The user has configured their browser to send mailto links to their personal email editor. A malicious client page could directly open the URL for the company email editor. The web mail editor needs a way to detect when a client page is trying to subvert the user's chosen preferences. So, an RPH handler needs a way to know that it was loaded via the RPH dispatch. Once it knows this, it can also trust that the arguments in the URL, such as from in this case, were not tampered with by the client page. I don't understand the attack scenario. Sure, a Web page can open another Web page with arbitrary arguments. Why does it matter here? In the example above, the user is expecting that clicking a mailto link initiates sending of an email from their personal email account. The attack page bypasses the RPH dispatch and directly sends the user to their company email editor. Consequently, the user sends an email from the wrong account, with potentially embarrassing results. With the change I am asking for, the mailto RPH handler can detect that the RPH dispatch was bypassed and show UI that says: Hey user, this was an unusual request. Are you sure you want to use this account? Maybe you want to use one of these others. In the legitimate scenario, the mail handler page can assume that the user is using the account they intended to, since the browser indicated that this is an RPH request and so this handler is the one the user purposely selected. In other RPH use-cases, bypassing the user's selected preference could have worse consequences. It's easy to protect against this and so not have to worry about what else could go wrong. --Tyler
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, Sep 26, 2011 at 11:09 AM, Tyler Close tyler.cl...@gmail.com wrote: The second problem with RPH is that the handler page doesn't have a way of reliably getting the URL of the content to be handled from the browser. In order to work in offline scenarios, the RPH handler must put the %s placeholder in the fragment of its handler's URL. Unfortunately, this means that other content in the browser could modify the content URL before the handler reads it. Just to clarify, the problem here is the well-known message integrity problem with using window.location.hash for cross-domain messaging. Since window.location.hash can be written to by content from many other origins, the RPH handler can't rely on the window.location.hash containing the content URL specified by the RPH client. Putting a copy of the content URL in window.navigator.action solves this problem. --Tyler
[whatwg] Fixing two security vulnerabilities in registerProtocolHandler
I was recently experimenting with the registerProtocolHandler (RPH)
API and came across a couple of security gotchas that make it hard to
safely use the API. One of these is already known, but AFAICT, hasn't
been fixed yet. I haven't seen the other discussed yet.
The Mozilla blog post that introduces the registerProtocolHandler API
makes use of window.parent.postMessage to send a response from the RPH
handler back to the client page. In the example code, the targetOrigin
for this postMessage invocation is '*', while also noting that this is
not secure. AFAICT, there is no API that the intent handler can
reliably use to determine the correct targetOrigin for this
postMessage invocation. I suggest fixing this problem by adding a new
readonly DOMString that contains the correct origin for the
postMessage invocation; perhaps document.origin. So the response
invocation would then be coded as:
window.parent.postMessage('my response data', document.origin);
Perhaps a different name or location is better for this field, so I'll
defer to the editor's judgment.
The second problem with RPH is that the handler page doesn't have a
way of reliably getting the URL of the content to be handled from the
browser. In order to work in offline scenarios, the RPH handler must
put the %s placeholder in the fragment of its handler's URL.
Unfortunately, this means that other content in the browser could
modify the content URL before the handler reads it. For example, an
attacker could open a window on a victim web page. The victim web page
then opens an iframe on a content URL that triggers RPH. The
attacker then navigates the iframe so that its window.location
contains a different content URL. The intent handler sees a request
coming from the victim page, but with a content URL specified by the
attacker. A related problem is that the intent handler has no way to
distinguish whether its URL was loaded via the browser's RPH handling,
or whether the client page directly navigated to the intent handler's
URL. Both of these problems could be fixed by adding another readonly
DOMString to the API that contains the %s data for the RPH invocation.
This new field must be in a location that can only be set by the
browser, such as window.navigator.action (taking the action name
from the form element). Safe intent handler code is then:
if (window.navigator.action) {
// Handle navigation to the URL in window.navigator.action
myCustomContentLoader(window.navigator.action);
window.parent.postMessage('did it!', document.origin);
}
Again, I defer to the editors on the best name and location for this
new readonly DOMString. I'm mostly interested in seeing these two
security issues in RPH cured.
Thanks,
--Tyler
Re: [whatwg] a href= ping=
On Wed, 18 Jan 2006 23:38:41 +0600, James Graham [EMAIL PROTECTED] wrote: And boy does it suggest this feature will be a marketing problem :( Darin Fisher blogged the Mozilla implementation[1] and received a stream of comments, many from people who clearly haven't thought about how easy tracking already is, to the effect that they will never use a browser with this feature etc. I think the ping attribute is a great feature and I also think it's great that the cited presentation of the feature provoked the reaction that it did. Having a user base that expresses demand for privacy and security is crucial to actually getting some privacy and security, which is something I sorely want. The problem here is the presentation. In reality, the ping attribute is a net plus for privacy and security, not a new threat. The feature needs to be presented as something that will be applauded by privacy conscious folks, not something that will raise some eye-brows. I will certainly applaud it. As is noted in the cited blog post, web sites already have the ability to track link clicks and many do so. This ability to track link clicks also isn't a bug in the design, but a natural consequence of the application: the server chooses what links to present to the user. That's just the nature of the Web, resources can choose what to link to. They can link back to their own site, or they can link into another site. The problem is that the current HTML design forces sites to use a layer of indirection to track link clicks to external sites. This layer of indirection is a problem for usability, performance and design complexity. It's a usability problem because the real link target is obscured, so using the right-click menu to copy the link, or bookmark it, will not yield the expected results. It's a performance problem because the link traversals are done serially. It causes design complexity because the programmer must remember to wrap all links to external sites in a reference to a redirector. I think it would be fair to characterize current techniques for link click tracking as opaque. In contrast, the proposed ping attribute explicitly declares in the HTML what is intended and how it will happen. Perhaps the right way to explain the ping attribute is as providing transparent, or explicit, feedback; shining a light on the dark corners of click tracking. If it is explained that the feature will make link click tracking explicit, controllable and more usable, I think the user base will react more positively. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your trusted sites to distinguish them from phishing sites. https://addons.mozilla.org/extensions/moreinfo.php?id=957
Re: [whatwg] a href= ping=
Hi Jim, On 1/19/06, Jim Ley [EMAIL PROTECTED] wrote: On 1/19/06, Tyler Close [EMAIL PROTECTED] wrote: I think it would be fair to characterize current techniques for link click tracking as opaque. In contrast, the proposed ping attribute explicitly declares in the HTML what is intended and how it will happen. Perhaps the right way to explain the ping attribute is as providing transparent, or explicit, feedback; shining a light on the dark corners of click tracking. If it is explained that the feature will make link click tracking explicit, controllable and more usable, I think the user base will react more positively. No, they'll just disable it, as it does them directly no benefit and has a cost, so if you educate them enough to make a decision, they will not decide to be tracked. Why hasn't this happened to the HTTP Referer header? Since the main use of tracking has a direct economic cost to many parties the sites will then return to using the established successful methods for tracking, no-one will gain and browsers would've wasted lots of time that could've been spent on more productive features. I think an economic analysis of the scenario is a valid approach. Could you spell out your argument in more detail? For example, after I've submitted a search request to Google, what is the economic cost to me of letting Google know which result I selected? What is the economic benefit to me of providing this information to Google? I can see an argument that there is a net benefit to me to provide this information. I don't see a clear argument that there is a net cost to me. At the start of the exchange, the thing of value that I have are my search terms. Once I've given those up, Google already has most of what it needs to effectively advertise to me. Allowing Google to know which result was most relevant to me might mean I get more value in the future for revealing my search terms, in terms of better query results. I'm interested to hear your economic analysis. Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your trusted sites to distinguish them from phishing sites. https://addons.mozilla.org/extensions/moreinfo.php?id=957
