canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/Firefox6/ReviewNotes/ServerDomEvents: Difference between revisions
Security/Reviews/Firefox6/ReviewNotes/ServerDomEvents (view source)
Revision as of 19:00, 27 June 2011
, 27 June 2011no edit summary
(Created page with "2011.06.27 https://bugzilla.mozilla.org/show_bug.cgi?id=338583 Add support for Server-Sent DOM Events (Remote Events) http://dev.w3.org/html5/eventsource/ https://bugzilla.mozill...") |
No edit summary |
||
| Line 1: | Line 1: | ||
2011.06.27 | == Server Sent DOM Events 2011.06.27 == | ||
*Add support for Server-Sent DOM Events (Remote Events) {{bug|338583}} | |||
Add support for Server-Sent DOM Events (Remote Events) | * Spec http://dev.w3.org/html5/eventsource/ | ||
http://dev.w3.org/html5/eventsource/ | * Related Bugs | ||
** {{bug|664179}} | |||
In aurora for 6 (without CORS) | * Current Status: In aurora for 6 (without CORS) | ||
== Introduce Feature | == Introduce Feature == | ||
* Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) | |||
** support data that a server can push to a web page | ** support data that a server can push to a web page | ||
** only supports http[s] today but could support other protocols in the future | ** only supports http[s] today but could support other protocols in the future | ||
* What solutions/approaches were considered other than the proposed solution? | |||
** multi-part xmlhttp is also being implemented as other browsers support this | ** multi-part xmlhttp is also being implemented as other browsers support this | ||
** websockets (which are two-way) requires big changes to servers | ** websockets (which are two-way) requires big changes to servers | ||
* Why was this solution chosen? | |||
* Any security threats already considered in the design and why? | |||
** same domain connections | ** same domain connections | ||
== Questions == | == Questions == | ||
* does support for http mean we also support https? | * does support for http mean we also support https? | ||
* content has to opt-in to | ** yes but should be tested and confirmed as correct | ||
** event source object | * content has to opt-in to receive messages? | ||
** event source object receives the messages | |||
*** it's not in the document tree, so there's no capture/bubbling phase | *** it's not in the document tree, so there's no capture/bubbling phase | ||
* two parallel listeners... what happens? | * two parallel listeners... what happens? | ||
** both get a reference to the same event (no race condition) | ** both get a reference to the same event (no race condition) | ||
** do they share a (network) connection, or are there multiple connections opened? | ** do they share a (network) connection, or are there multiple connections opened? | ||
*** Different connections? TODO: check to make sure they both see the same event object in the client. | *** Different connections? '''TODO:''' check to make sure they both see the same event object in the client. | ||
*** even if they are in different pages??? <-- good question, maybe separate pages should not share connection, but same page should (spec says?) | *** even if they are in different pages??? <-- good question, maybe separate pages should not share connection, but same page should (spec says?) | ||
* how is the URI in the constructor validated (ie check it's not a chrome URI or some other funky kind of URI) ? | * how is the URI in the constructor validated (ie check it's not a chrome URI or some other funky kind of URI) ? | ||
* how does CSP factor into EventSource usage ? | * how does CSP factor into EventSource usage ? | ||
** it's currently type script, but should probably be changed to type XHR (or its own type) | ** it's currently type script, but should probably be changed to type XHR (or its own type) | ||
* | * If you're on an HTTPS page and the event source references HTTP URL, does the mixed content UI get triggered (hide secure badging for the page)? | ||
** Not an issue for same-origin, but for CORS support needs to be considered. | ** Not an issue for same-origin, but for CORS support needs to be considered. | ||
** Do we want to consider https-using-http to be "mixed display" (allowed) or "mixed scripting" (blocked) when we adopt this distinction from chromium? (how about equivalent to XHR -- then we can deal with them together -- probably "mixed scripting") | ** Do we want to consider https-using-http to be "mixed display" (allowed) or "mixed scripting" (blocked) when we adopt this distinction from chromium? (how about equivalent to XHR -- then we can deal with them together -- probably "mixed scripting") | ||
| Line 35: | Line 37: | ||
* interaction with bfcache? | * interaction with bfcache? | ||
** frozen document gets its connections closed. thawed document gets reconnected. | ** frozen document gets its connections closed. thawed document gets reconnected. | ||
== Threat Brainstorming | |||
== Threat Brainstorming == | |||
=== Server attacking client === | === Server attacking client === | ||
* | * DoS by opening a bunch of connections, maxing out our limits | ||
** differs from XMLHttpRequest because it is expected to be long-lived (but same risk as multiple long-lived XHRs) | ** differs from XMLHttpRequest because it is expected to be long-lived (but same risk as multiple long-lived XHRs) | ||
** maybe we should have a per-tab limit so a single tab can't eat your networking limits | ** maybe we should have a per-tab limit so a single tab can't eat your networking limits | ||