Allow Cross-Origin URLs in EventSource (Server-Sent Events) - bug 664179
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
Push-based event triggers, based on CORS/XHR stuff. Syntax sugar to make push and event notifications easier and require less scripting support for connection maintenance, etc.
The goal of this feature is to allow cross-site pushing of server sent events. For example allowing a bank site to push events that keep you up-to-date with your portfolio, or facebook pushing an event stream containing updates to your wall. http://pulse.mozilla.org/ has also expressed desire to use this to allow other sites to consume and visualize data concerning the mozilla project.
- bug 664179 Tracks the cross-site support
- There appears to be agreement between all concerned parties that CORS will be used as security model.
Any security threats already considered in the design and why?
- Credential (cookies) use without target site expecting it (CSRF).
The threats are the same as for cross-site XMLHttpRequest.
- Sites might share data without first checking with the user that this is ok.
- Sites might accidentally share data with third party sites while not intending to do so.
- The data can be sniffed while going over the net.
There are lots of mitigations built into CORS which is used as security model
- Can only opt in on a per-URI basis (though serverside technologies can make this available on a per-site or per-subtree basis)
- Can't opt in to sharing private data with "the world" without using custom server-side scripting which echos back the "Origin" header in the "Access-Control-Allow-Origin" header.
- Sharing private data requires setting two explicit headers: "Access-Control-Allow-Origin" and "Access-Control-Allow-Credentials".
Additionally, we're reusing the same code as used for cross-site XMLHttpRequest, cross-site @font-face, CORS-based <img>.
Topics To Discuss During The Review
Please be prepared to discuss the topics listed at ReviewTopics as they relate to your feature / project. Optionally, you may copy the most relevant questions here and answer them before the review, which could speed up the review meeting.
The threat model is largely the same as for CORS and for EventSource, both of which have already been reviewed. However since CORS allows two "modes" in the form of with-cookies and without-cookies, we need to choose a strategy for which modes to allow and which mode to default to. Concern was raised that some sites might misunderstand what enabling CORS on their event-source stream means. There's a possibility that they understand it to mean that you can only use EventSource to read the stream. This might for example think that it's ok to put potentially sensitive information in comments in the stream. However since the full unparsed stream can be read using cross-site XHR, this is in fact not safe.
Conclusions / Action Items