Ziteboard is a shareable board based on the HTML5 Canvas - www.ziteboard.com.
I don't see too much in the Network tab in Chrome Dev Tools.
Does it use websockets for sharing the board, WebRTC, or maybe anything else? How does communication work, undo function?
Thanks
It uses websockets. See the attached image.
You have to have the network tab open when the page loads to be able to see the websocket frames and connections.
Related
It has been discussed many times on Stackoverflow that by default WebRTC technology leaks your real IP even if your using a proxy to browse the web. What I haven't seen discussed is whether this requires the end user to click a button to enable this kind of leak or whether the leak occurs regardless of any action taken by the user.
For example, when you go to Express VPN they require you press a button to test for WebRTC leak. My question is - is this done for privacy reasons or somehow the button activates WebRTC tech so it can leak your IP?
In other words, assuming you never need to use WebRTC tech (just browser a blog or eCommerce shop) and all you do is click a few links - can a website still detect your real IP through WebRTC?
Thanks
Yes, a browser can detect your public IP address using WebRTC.
No, the leak is not reliant on your button interaction.
Recently, I found an unpatched github repo webrtc-ip, which can leak a user's public IP address using WebRTC. This is powerful because you cannot trace it, as nothing is shown in the Networks tab.
Sadly, this leak does not work for private IPs, due to the gradual shift to mDNS (at least for WebRTC), which is described completely in this great blog. Anyways,a here's a working demo:
https://webrtc-ip.herokuapp.com/
I am not sure if this leaks your true IP address even if you are using a proxy, but feel free to test it out.
I am able to view the frames as they come through but I have yet to find a way to see how much data is actually being sent.
Here is the trick. You can use "tshark" to capture the data in/out from web-socket. Or you can use the graphical version of tshark called Wireshark. If you are wanting to print the capture via your progarm (java file) then you can do Runtime.execute("tshark command here"). This must be the one way. Web-socket is a TCP socket between server and client. Wireshark can easily to this.
I have written a few dissectors in Lua for Wireshark, for example. I would like to know if Devtools can be extended to achieve similar effects. There are a few reasons this is desirable:
Installing and using Wireshark often mandates privileged access.
Capturing traffic from the loopback NIC on Windows remains problematic.
websocket traffic is included in saved HAR files, suitable for later dissection.
Devtools can inspect SSL secured websocket frames with zero user effort.
It's possible with Firefox.
There is an addon already that hooks into the WebSocket data. It can do some additional parsing of protocols on top of WebSockets like MQTT.
https://addons.mozilla.org/en-GB/firefox/addon/websocket-monitor/
It appears to hook into nsIWebSocketEventService to get the data. I haven't found any documentation for it.
https://github.com/firebug/websocket-monitor/blob/master/lib/wsm-actor.js#L80
Chrome does not appear to allow access to WebSocket frame data through an API.
You may be able to modify the WebSocket constructor to allow you to intercept the events from your plugin.
https://groups.google.com/forum/#!topic/google-chrome-developer-tools/7_a0W8Y92O4
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.
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.