Yikes. As far as I can tell, the only meaningful thing this adds is the ability to require developer registration in order to use experimental APIs. > The ult

Yikes. As far as I can tell, the only meaningful thing this adds is the ability to require developer registration in order to use experimental APIs. > The ultimate goal is to enable experimentation and iteration on pre-standardization APIs, in a way that gathers meaningful feedback, but without burn-in of the APIs. I'm not sure what's broken about the "experimental" label except that it can't trace usage back to specific developers. If it's experimental, it will probably break or disappear. "Burn-in" doesn't have to be a problem if you actually iterate and yank or change stuff. API keys don't solve anything that code removal doesn't solve (aside from developer tracking). Want to curb "developer abuse" of vendor prefixes? Remove the API. Train developers to understand that experimental features are experimental by actually following through. If you don't want users to think the browser is at fault, maybe alert the user to that fact. "Oops, looks like this website's developers were a bit careless with their code. Sorry about that; some people like to take big risks and it stinks that you the user had to suffer for it." If you really want to ensure that only specific devs are allowed to use some features, presumably to limit impact on users and loss of browser market share, then just ship those devs a custom release. Protect usage of the whole browser with a key, if you want. Personally, I'd rather we leave things open to experimentation (with an established and valid understanding they may break) over locking it down to devs willing to give you their phone number so you actively approach them for feedback and turn off the tap on a per-developer basis if you so desire.