Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** You're contradicting yourself within a single two-line paragraph, being vague in your own statement ... that what I'm reaching for is doable. I know you know what you're talking about and I know what I'm reaching for is doable. What I don't know are the details of how that might be doable. I think a lot of developers would be interested in that. Not just me. I think you dropped some hint there but it's no where near a detailed and clear answer, so again shutting down the discussion because you know more? What the hey! Mr. Eich. This is a public discussion forum. If it wasn't open to the public, it would be private. In discussions, vagueness is not the enemy of the truth, only part of the journey... Relax. On a more serious basis, please provide us with clarity or point us to discussions on this topic that might help us understand how to get _to_ there! On Tue, Feb 10, 2015 at 7:19 PM, Brendan Eich bren...@secure.meer.net wrote: Marc Fawzi wrote: I've recently started using something called an atom in ClojureScript and it is described as a mutable reference to an immutable value. It holds the state for the app and can be safely mutated by multiple components, and has an interesting thing called a cursor. It is lock free but synchronous. I think I understand it to some degree. The win there is the mutations are local to the clients of the atom, but the underlying data structure it reflects is immutable. The DOM is not immutable and must not be for backward compatibility. I don't understand the implementation of the DOM but why couldn't we have a representation of it that acted like the atom in clojure and then write the diff to the actual DOM. Because browsers don't work that way. I wish they did, but they can't afford to stop the world, reimplement, optimize (if possible -- they will probably see regressions that are both hard to fix, and that hurt them in the market), and then restart the world. Is that what React does with I virtual DOM? No idea but I wasn't dropping words, I was describing what was explained to me about the atom in clojure and I saw parallels and possibility of something similar in JS to manage the DOM. I'm a big React fan. But it can virtualize the DOM using JS objects and do diffing/patching, without having to jack up the browsers (all of them; note stop the world above), rewrite their DOMs to match, and get them optimized and running again. With all the brains in this place are you telling me flat out that it is impossible to have a version of the DOM (call it virtual or atomic DOM) that could be manipulated from web workers? I'm not. People are doing this. My explicit point in a previous reply was that you don't need public-webapps or browser vendors to agree on doing this in full to start, and what you do in JS can inform smaller, easier steps in the standards body. One such step would be a way to do sync i/o from workers. Clear? Also I was mentioning immutable and transient types because they are so necessary to performant functional programming, as I understand it. Sure, but we're back to motherhood-and-apple-pie rhetoric now. Again the clojure atom is lock free and synchronous and is mutable and thread safe. Why couldn't something like that act as a layer to hold DOM state. First, lock-free data structures are not free. They require a memory barrier or fence, e.g., cmpxchg on Intel. Study this before endorsing it as a free lunch. Competing browsers will not add such overhead to their DOMs right now. Second, even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. But not by vague blather, and nothing to do with sync XHR, to get back on topic. Maybe that's how React's virtual DOM works? I don't know but I find the idea behind the atom very intriguing and not sure why it wouldn't be applicable to making the DOM thread safe. What do the biggest brains in the room think? That's all. A discussion. If people leave the list because of it then that's their right but it is a human right to speak ones mind as long as the speech is not demeaning or otherwise hurtful. I think you're on the wrong list. This isn't the place for vague albeit well-intentioned -- but as you allow above, uninformed (I don't know) -- speculations and hopes. I really don't understand the arrogance here. Cut it out, or I'll cite your faux-humility as tit-for-tat. We need to be serious, well-informed, and concrete here. No speculations based on free-lunch (!= lock-free) myths. As for sync XHR, I agree with you (I think! I may be misremembering your position) that compatibility trumps intentions
Re: [Unbearable] IETF seeking feedback on proposed Token Binding Working Group
On Wed, Feb 11, 2015 at 7:41 PM, Andrei Popov andrei.po...@microsoft.com wrote: This is part of a starting point proposal for the new working group; we expect the documents to change. I think it would be best if the document was written in such a way that any API could be plugged on top. And that it leaves changing APIs to those working on those APIs. https://github.com/TokenBinding/Internet-Drafts I filed some issues for now. -- https://annevankesteren.nl/
[clipboard] Feature detect Clipboard API support?
The current spec still leaves me a bit unclear about if implementors must
include the ability to feature detect Clipboard API support, which I think
is a critical requirement.
In particular, I *need* to be able to detect support for the Clipboard API
(click-to-copy support, in particular) in advance and without the user's
interaction in order to know if I need to load a Flash fallback or not.
If this is even *possible* based on the current spec, the only way I can
see that might make that possible is if executing `
document.execCommand(copy)` synthetically (without user interaction) MUST
still fire the `beforecopy`/`copy` events [but obviously not execute the
associated default action since it must not be authorized to inject into
the clipboard]. However, I don't feel that the spec defines any clear
stance on that.
Example detection attempt (more verbose version on JSBin [1]):
```js
var execResult,
isSupported = false;
if (typeof window.ClipboardEvent !== undefined window.ClipboardEvent) {
var checkSupport = function(e) {
isSupported = !!e e.type === copy !!e.clipboardData e
instanceof window.ClipboardEvent;
document.removeEventListener(copy, checkSupport, false);
};
document.addEventListener(copy, checkSupport, false);
try {
execResult = document.execCommand(copy);
}
catch (e) {
execResult = e;
}
document.removeEventListener(copy, checkSupport, false);
// Should I care about the `execResult` value for feature testing?
// I don't think so.
if (!isSupported) {
// Fallback to Flash clipboard usage
}
}
```
This currently yields poor results, as well as arguably false positives for
`window.ClipboardEvent` (conforming to an earlier version of the spec,
perhaps?) in Firefox 22+ (22-35, currently) and pre-Blink Opera (15).
It also causes security dialogs to popup in IE9-11 when invoking `
document.execCommand(copy)` if you do not first verify that
`window.ClipboardEvent` is present. That is obviously harmful to user
experience.
Can we agree upon some consistent feature detection technique to add to the
spec that can be guaranteed to yield correct results? I would love it if
it were as simple as verifying that `window.ClipboardEvent` existed but, as
I mentioned, that is already yielding false positives today.
[1]: http://jsbin.com/davoxa/edit?html,js,output
Sincerely,
James Greene
Re: [clipboard] Feature detect Clipboard API support?
AFAIK, you can't trigger a clip board request without human interaction.
$('#element).off().on('click',function(e) {
var clip = new ClipboardEvent('copy');
clip.clipboardData.setData('text/plain','some data');
clip.preventDefault();
e.target.dispatchEvent(clip);
});
This unfortunately won't work in my environment since my code is not
'trusted'.
m.
On 02/11/2015 12:21 PM, James M. Greene wrote:
The current spec still leaves me a bit unclear about if
implementors must include the ability to feature detect Clipboard
API support, which I think is a critical requirement.
In particular, I /need/ to be able to detect support for the
Clipboard API (click-to-copy support, in particular) in advance
and without the user's interaction in order to know if I need to
load a Flash fallback or not.
If this is even /possible/ based on the current spec, the only way
I can see that might make that possible is if executing
`document.execCommand(copy)` synthetically (without user
interaction) MUST still fire the `beforecopy`/`copy` events [but
obviously not execute the associated default action since it must
not be authorized to inject into the clipboard]. However, I don't
feel that the spec defines any clear stance on that.
Example detection attempt (more verbose version on JSBin [1]):
```js var execResult, isSupported = false;
if (typeof window.ClipboardEvent !== undefined
window.ClipboardEvent) { var checkSupport = function(e) {
isSupported = !!e e.type === copy !!e.clipboardData e
instanceof window.ClipboardEvent;
document.removeEventListener(copy, checkSupport, false); };
document.addEventListener(copy, checkSupport, false);
try { execResult = document.execCommand(copy); } catch (e) {
execResult = e; }
document.removeEventListener(copy, checkSupport, false);
// Should I care about the `execResult` value for feature testing?
// I don't think so.
if (!isSupported) { // Fallback to Flash clipboard usage } } ```
This currently yields poor results, as well as arguably false
positives for `window.ClipboardEvent` (conforming to an earlier
version of the spec, perhaps?) in Firefox 22+ (22-35, currently)
and pre-Blink Opera (15).
It also causes security dialogs to popup in IE9-11 when invoking
`document.execCommand(copy)` if you do not first verify that
`window.ClipboardEvent` is present. That is obviously harmful to
user experience.
Can we agree upon some consistent feature detection technique to
add to the spec that can be guaranteed to yield correct results?
I would love it if it were as simple as verifying that
`window.ClipboardEvent` existed but, as I mentioned, that is
already yielding false positives today.
[1]: http://jsbin.com/davoxa/edit?html,js,output
Sincerely, James Greene
Re: [clipboard API] platform integration stuff - in spec or out of scope?
We never really came to a decision on if RTF (application/rtf) should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward yes: https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html Sincerely, James Greene On Sat, Jan 31, 2015 at 5:31 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: I don't know what these map to on platforms that do not use MIME types to describe clipboard contents. Should this information be dug up and included? First request: can we add the three MathML media-types? I know you've brought this up before, I haven't done anything about it and it's partly because I'm not actually sure myself what an implementation would have to do to support a data type.. I think I could help dig the names out by looking at the following documents: That would be absolutely terrific Paul - maybe make a wiki page or etherpad somewhere? It would really help me - coming more from the JavaScript side of things I can figure out and describe how all the JavaScript stuff works, but it's much harder to determine how the platform side needs to be specified. - http://developer.apple.com/mac/library/documentation/FileManagement/Conceptual/understanding_utis/ - https://msdn.microsoft.com/en-us/library/system.windows.dataformats.aspx Also, some specs and media-type-registration RFCs indicate the names in the native formats. I think this would be the right place to hunt too (I know that MathML and SVG do). Probably it'll never be complete (e.g. I do not think application/octet-stream can have a name on clipboards). So.. If the most important platforms do not have a clipboard format or description for a specific MIME type, does that mean telling implementations to support it is meaningless? Sort of seems like it.. -Hallvord
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
Marc Fawzi wrote: even if the DOM must remain a single-threaded and truly lock/barrier/fence-free data structure, what you are reaching for is doable now, with some help from standards bodies. ***But not by vague blather*** Sorry, I was too grumpy -- my apologies. I don't see much ground for progress in this whole thread or the sub-thread you started. If we're talking about sync XHR, I gave my informed opinion that deprecating it is empty talk if actually obsoleting by whichever browser takes the first hit inevitably leads to market share loss or (before that) developers screaming enough to get the CEO's attention. We will simply waste a lot of time and energy (we already are) arguing and hollering for and against deprecation, without any definite hope of obsolescence. If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of adding barriers and other synchronization devices all over their DOM code. Only the Servo project, which is all about safety with maximal hardware parallelism, might get to the promised land you seek (even that's not clear yet). Doing over the top JS libraries/toolchains such as React is excellent, I support it. But it does not share mutable or immutable state across threads. JS is still single-threaded, event loop concurrency with mutable state, in its execution model. This execution model was born and co-evolved with the DOM 20 years ago (I'm to blame). It can't be changed backward-compatibly and no one will break the Web. We should add lighter-weight workers and immutable data structures and other such things, and these are on the Harmony agenda with the JS standards body. We might even find race-confined ways to run asm.js code on multiple workers with shared memory in an ArrayBuffer -- that's an area of active research. But none of these things is anything near to what you described in the forked subject line: Thread-Safe DOM. I'll leave it at this.I invite others from Mozilla, Google, Apple, and MS to speak up if they disagree. /be
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of adding barriers and other synchronization devices all over their DOM code. Only the Servo project, which is all about safety with maximal hardware parallelism, might get to the promised land you seek (even that's not clear yet). A good start is defining terms. What do we mean by multi-threaded DOM access? If we mean concurrent access to the same DOM objects from both a window and a worker, or multiple workers, then I think that's a no-go in Servo as well, and not worth trying to design for: it would introduce a lot of spec and implementation complexity that I don't think is warranted by the use cases I've seen. If we mean the much more modest have a DOM implementation available in workers then that might be viable. Even _that_ is pretty hard to do in Gecko, at least, because there is various global state (caches of various sorts) that the DOM uses that would need to either move into TLS or become threadsafe in some form or something... Again, various specs (mostly DOM and HTML) would need to be gone over very carefully to make sure they're not making assumptions about the availability of such global shared state. We should add lighter-weight workers and immutable data structures I should note that even some things that could be immutable might involved a shared cache in current implementations (e.g. to speed up sequential indexed access into a child list implemented as a linked list)... Obviously that sort of thing can be changed, but your bigger point that there is a lot of risk to doing that in existing implementations remains. -Boris
Re: [clipboard API] platform integration stuff - in spec or out of scope?
On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene james.m.gre...@gmail.com wrote: We never really came to a decision on if RTF (application/rtf) should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward yes: https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html There was some pushback from vendors - and I think their arguments were reasonable. Why should a web browser have to include code to generate RTF documents to write them to the clipboard? It's going to be a non-trivial amount of code, it will be rarely executed and could easily come with exploitable security vulnerabilities. It only makes sense to require this if there is a significant amount of software out there that supports pasting RTF data but does *NOT* support pasting HTML data - so that if we mandate support for writing HTML to the clipboard but leave RTF out, many users will have problems pasting text with formatting into another application. How many applications would have this issue on the various platforms? How widely are they used? Would users even expect to be able to preserve formatting on pasting into or copying from these applications? A reply from you in the earlier discussion of these questions is here: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html -Hallvord, wearing an invisible clipboard spec editor hat
Re: [clipboard] Feature detect Clipboard API support?
On Wed, Feb 11, 2015 at 12:34 PM, Michaela Merz michaela.m...@hermetos.com
wrote:
AFAIK, you can't trigger a clip board request without human interaction.
$('#element).off().on('click',function(e) {
var clip = new ClipboardEvent('copy');
clip.clipboardData.setData('text/plain','some data');
clip.preventDefault();
e.target.dispatchEvent(clip);
});
This unfortunately won't work in my environment since my code is not
'trusted'.
Events are used to detect that something happened, not to cause the thing
to happen. The copy event tells you that a copy happened, you don't
dispatch copy to cause a copy to happen. You use regular API calls to do
that, like execCommand(copy). You're correct that you usually can't use
that except in response to a user action, of course.
--
Glenn Maynard
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
On 2/11/15 9:45 PM, Marc Fawzi wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Pretty much, yep. this has worked so far, miraculously and not without overhead, but I can only assume that it's at the cost of growing complexity in the browser codebase. To some extent, yes. Browsers have obviously been doing refactoring and simplification as they go, but I think it's pretty clear that a minimal viable browser today is a lot more complicated than one 10 years ago. I'm sure you have to manage a ton of code that has to do with old features and old ideas... Sometimes. Sometimes it can just be expressed easily in terms of the newer stuff. And sometimes we do manage to remove things -- I'm seeing it happen right now with plugins, which definitely fall in the bucket of a ton of annoying-to-maintain code. how long can this be sustained? forever? If we're lucky, yes. what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? About 10-15 years ago, really. We've just gotten pretty good at facing the nightmare. ;) -Boris
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones this has worked so far, miraculously and not without overhead, but I can only assume that it's at the cost of growing complexity in the browser codebase. I'm sure you have to manage a ton of code that has to do with old features and old ideas... how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? On Wed, Feb 11, 2015 at 12:33 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of adding barriers and other synchronization devices all over their DOM code. Only the Servo project, which is all about safety with maximal hardware parallelism, might get to the promised land you seek (even that's not clear yet). A good start is defining terms. What do we mean by multi-threaded DOM access? If we mean concurrent access to the same DOM objects from both a window and a worker, or multiple workers, then I think that's a no-go in Servo as well, and not worth trying to design for: it would introduce a lot of spec and implementation complexity that I don't think is warranted by the use cases I've seen. If we mean the much more modest have a DOM implementation available in workers then that might be viable. Even _that_ is pretty hard to do in Gecko, at least, because there is various global state (caches of various sorts) that the DOM uses that would need to either move into TLS or become threadsafe in some form or something... Again, various specs (mostly DOM and HTML) would need to be gone over very carefully to make sure they're not making assumptions about the availability of such global shared state. We should add lighter-weight workers and immutable data structures I should note that even some things that could be immutable might involved a shared cache in current implementations (e.g. to speed up sequential indexed access into a child list implemented as a linked list)... Obviously that sort of thing can be changed, but your bigger point that there is a lot of risk to doing that in existing implementations remains. -Boris
Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest
On Thu, Feb 12, 2015 at 1:45 PM, Marc Fawzi marc.fa...@gmail.com wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Yup. this has worked so far, miraculously and not without overhead, but I can only assume that it's at the cost of growing complexity in the browser codebase. I'm sure you have to manage a ton of code that has to do with old features and old ideas... how long can this be sustained? forever? what is the point in time where the business of retaining backward compatibility becomes a huge nightmare? When someone comes up with something sufficiently better to be worth abandoning trillions of existing pages for (or duplicating the read trillions of old pages engine alongside the new one). ~TJ
Re: [clipboard API] platform integration stuff - in spec or out of scope?
Allow me to clarify my position. My expectation is NOT for the browsers' default action on copy/cut to convert HTML into RTF. I do not see any such implication of that behavior in the spec language [1]. Rather, I just want to ensure that browsers will honor/maintain that clipboard format/segment if it is set during a custom copy event handler using the `event.clipboardData.setData` method. The current language of the spec [2] leaves the possibility open for an implementor to choose to ignore/discard any data formats that are not on the mandatory data types list [1], and I find that worrysome. Is the problem that spec may be implying that the browser must know what to do with the data when PASTING from a clipboard segment associated with a mandatory data type? I could see that as more of a sticking point for implementors... but again, I really just want to ensure that the application/rtf clipboard segment is simply left intact bi-directionally. If the spec were to be updated to generally ensure that type of maintained/untouched transfer for data types that are NOT on the mandatory data types list (i.e. custom data types), then I would be fine leaving application/rtf OFF the mandatory data types list. Can we get some clarification on the vendor pushback reasoning in this regard? Thanks! [1]: http://dev.w3.org/2006/webapi/clipops/clipops.html#mandatory-data-types [2]: http://dev.w3.org/2006/webapi/clipops/clipops.html#writing-contents-to-the-clipboard Sincerely, James M. Greene On Feb 11, 2015 3:15 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene james.m.gre...@gmail.com wrote: We never really came to a decision on if RTF (application/rtf) should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward yes: https://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0197.html There was some pushback from vendors - and I think their arguments were reasonable. Why should a web browser have to include code to generate RTF documents to write them to the clipboard? It's going to be a non-trivial amount of code, it will be rarely executed and could easily come with exploitable security vulnerabilities. It only makes sense to require this if there is a significant amount of software out there that supports pasting RTF data but does *NOT* support pasting HTML data - so that if we mandate support for writing HTML to the clipboard but leave RTF out, many users will have problems pasting text with formatting into another application. How many applications would have this issue on the various platforms? How widely are they used? Would users even expect to be able to preserve formatting on pasting into or copying from these applications? A reply from you in the earlier discussion of these questions is here: https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0325.html -Hallvord, wearing an invisible clipboard spec editor hat
IETF seeking feedback on proposed Token Binding Working Group
[ public-webapps should have been included but was not ] Forwarded Message Subject:IETF seeking feedback on proposed Token Binding Working Group Date: Wed, 11 Feb 2015 07:00:35 -0500 From: Arthur Barstow art.bars...@gmail.com Reply-To: unbeara...@ietf.org CC: Stephen Farrell stephen.farr...@cs.tcd.ie [ Bcc: WebApps, WebAppSec, Web Security IG; Reply-to: unbearable @ ietf.org ] Hi All, Below is an e-mail from Stephen Farrell regarding a proposed Token Binding Working Group at the IETF. Stephen is interested in feedback regarding the proposed group: * Home: https://datatracker.ietf.org/wg/tokbind/charter/ * Draft spec: https://tools.ietf.org/html/draft-balfanz-https-token-binding * List archive: http://www.ietf.org/mail-archive/web/unbearable/current/maillist.html The Draft charter includes: [[ Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination with HTTPS. ... ]] WebAppSec, Web Security IG - this is mainly an FYI for you. WebApps - please note the draft spec includes a new XHR property withRefererTokenBindingID https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4. If anyone has feedback about the proposal, please send it to the unbearable @ ietf.org list. However, comments related to the XHR aspect should be Cc/Bcc to public-webapps. -Thanks, AB On 6 Feb 2015, at 8:40 am, Stephen Farrellstephen.farr...@cs.tcd.ie wrote: Hi Mark W3C folks, (I'm cc'ing various W3C folks I know in case one of you just know the answer and can save us some iterations, apologies to the others of you:-) We're starting the chartering process for a WG aiming to do better than bearer tokens. [1] As of now, it looks like that has a good chance of getting into some or all browsers which is great. We'll see what else turns up during the chartering process as usual, and please do comment on that also as usual. One thing I noted is that the current draft [2] for part of this work proposes (in section 3.4 [3]) a small change to XHR, so I wanted to bring that up with you and see if you think that's a thing that'll need to be addressed during chartering or if it's ok to handle later (in whatever is the right manner) after we've chartered an IETF WG. Or maybe it's something that's already done or bring done in W3C. The informal IESG evaluation of this charter is set for Feb 19th, so if we could figure it out by then that'd be great. If not, we've another couple of weeks of external review when we can get it done, but I'd prefer be quick if we can. And in case it helps, I think the simplest way to handle this if the change turns out to be needed in the end, would be for the relevant folks to just keep chatting and ideally get that XHR change tee'd up in W3C. In the meantime, the IETF spec could say something like if you did change XHR in such-and-such a way then... just so's we don't get in one another's way. Or maybe some other plan is better. Anyway, please let me know who's the right W3C person to keep in the loop on this and hopefully let's sort it out in the next week or so. Cheers, Stephen. [1]https://datatracker.ietf.org/wg/tokbind/charter/ [2]https://tools.ietf.org/html/draft-balfanz-https-token-binding [3] https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4
Re: IETF seeking feedback on proposed Token Binding Working Group
On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow art.bars...@gmail.com wrote: WebApps - please note the draft spec includes a new XHR property withRefererTokenBindingID https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4. If anyone has feedback about the proposal, please send it to the unbearable @ ietf.org list. However, comments related to the XHR aspect should be Cc/Bcc to public-webapps. Relatively recently we decided not to extend XMLHttpRequest further and prioritize fetch(). Can we expect a more concrete proposal to revise either or is this it? One problem with this proposal is that it does not use the Sec-* convention for headers so the header can be spoofed... -- https://annevankesteren.nl/
