I'm trying to develop an extension that detects every connection made by the browser to figure out the URLs being accessed. I know that this is possible via writing an HTTP/SOCKS proxy and configuring the browser to flow traffic via that. However, that's kind of overkill for the application that I'm trying to develop and it's best done as a Firefox Add-on if that's possible. Any clues/pointers would be highly appreciated.
Use nsIHttpActivityDistributor and there is many information about the http transaction and socket transport through observeActivity callback.
Read the official documentation https://developer.mozilla.org/en/Monitoring_HTTP_activity.
Related
I learned the hard way that the browsers' WebSocket API does not support back-pressure. Is there a way to work around this limitation without having to manually implement control flow on the application layer protocol? Would it for example be possible to implement a full WebSocket client in WASM, instead of having to proxy everything through the browser's API?
Back-pressure: no changes to the protocol that are addressing this issue are published to this time.
WebAssembly: there is no access to the WebSocket API (or any other) at this time from a pure WebAssembly module. You will have to use JavaScript in one way or another.
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.
This is sort of a theoretical question, however, I need to add file sharing capabilities to my web socket powered chat application. I could use a service like Amazon S3 to upload a file to share by posting a link to the file, but that involves the uploading of a file that may already be accessible over the local network (sharing a file between co-workers for example).
So I had the idea that it might be possible to somehow tunnel the upload/download/transfer through the already existing web socket connection. However, I don't know enough about HTTP file transfer to know the next step of how to implement it. Is there a limitation to web sockets that would prevent this from being possible?
I'm using Ruby and EventMachine for my current web socket implementation. If you were able to provide a high level overview to get me started, that would be very much appreciated.
Here's an example of a project that uses only Web Sockets and the javascript File API for transferring files: http://www.github.com/thirtysixthspan/waterunderice
To allow files to be shared without the need to upload it to the server, (i.e Coworkers) you can now use the WebRTC DataChannel API, to create a peer to peer connection.
What is the simplest way to send text data from chrome's javascript (running in a extension) and my external app? I saw XHR, but I don't want to use it cause it can be blocked by firewalls.
XHR is the way to go. It shouldn't be blocked by any firewall because it comes as a regular browser request, similar to retrieving external js file or image. Using anything else would look rather fishy.
You can implement HTML5 WebSockets.
http://www.html5rocks.com/tutorials/websockets/basics/
On your external app, you define the WebSocket server (many many implementations out there for many languages). And you just connect through it in your Extension. You can specify any port you please by allowing your WebSocket to listen to it.
This might sound really naive but I would really find a descriptive answer helpful.
So, my question is this:
I can use Firebug to look at AJAX requests made from any website I visit. So, am I right in saying that I wouldn't be able to examine the same communication between the client and the server if the website choses to use Websockets? In other words, does this make it more secure?
No. Not at all. Just because the browser does not (yet) have a tool to show WebSocket traffic, doesn't make it any more secure. You can always run a packet sniffer to monitor the traffic, for example.
No, because there will be other ways beside the browser-build in tools to read your traffic.
Have a try: Install and run Wireshark and you will be able to see all packets you send and receive via Websockets.
Depends on the application. If you are fully Ajax without reloading the document for data then I would think websockets would provide a better authentication for data requests then a cookie session in regards to connection hijack. Given that you are using SSL of course.
Never rely on secrecy of algorithm cause it only gives you false sense of security. Wiki: Security by obscurity
Remember that browser is a program on my computer and I am the one who have a full control over what is send to you, not my browser.
I guess it's only matter of time (up to few months IMO) when developer tools such as Firebug will provide some fancy tool for browsing data send/received by WebSockets.
WebSockets has both an unencrypted (ws://) and encrypted mode (wss://). This is analogous to HTTP and HTTPS. WebSockets protocol payload is simply UTF-8 encoded. From a network sniffing perspective there is no advantage to using WebSockets (use wss and HTTPS for everything at all sensitive). From the browser perspective there is no benefit to using WebSockets for security. Anything running in the browser can be examined (and modified) by a sufficiently knowledgeable user. The tools for examining HTTP/AJAX requests just happen to be better right now.