[Enhancement] Implement the websocket fallback as a real fallback

[schlagmichdoch]

What problem is solved by the new feature
Currently, the websocket fallback (enabled via WS_FALLBACK=true) is only used when a device cannot use window.RTCPeerConnection. Some admins have expected it to be a fallback to the WebRTC connection, so it is also used whenever the WebRTC connection fails.

Describe the feature
If the WebRTC connection fails (3 times?) the websockets fallback is used instead.

Additional context
See also #215
Only implement this after implementing traffic encryption for the websocket fallback (part of #180)

[terrytw]

First of all I would like to thank you for the quick response and also for the continuous effort on maintaining this grea project. It benefits a lot of people and we are all grateful!

1. The clients were circled in red, I remember thinking about it "a nice UI touch". There must be some other elements (intead of the change in your implementaton which I thought was the reason) which prevented the WEBRTC protocol, which leads to point 2;
2. I live in a country with heavy internet censorship, and a lot of treacherous internet situations like UDP block, multiple layer of nat, etc. Plus many public webrtc server is blocked or really slow. Webrtc is basically unusable here.
3. I mostly used pairdrop in a local network (my home network), and I only tested websocket fallback the first time I implemented it a few months back, and it was working (looking back it was because of other reasons blocking webrtc completely instead of my dummy turn server config). But the last couple of days I needed to use it in a mobile network environment where direction connection is impossible, and it fails to connect, which leads me here.
4. I fully agree that a real fallback is the best solution. I just hope there is a way right now to establish connection without webrtc or direct connection because the real solution might be months away. But again my usecase is quite niche so I think if it is not a simple "flip of a switch" kind of deal, it won't be worth it.

Sorry for taking up your time. Once again, really appreciate the work!

[schlagmichdoch]

There was a bug in a version some months ago that accidentally enforced all connections to be made via ws if the fallback was activated.

You can try some things:

1. Set the iceServers of the rtcconfig.json to an empty array: this could enable devices on the same network to find each other:

   {
     "sdpSemantics": "unified-plan",
     "iceServers": []
   }

2. Use uBlock Origin (or alike) to disable WebRTC on your device
3. Use Firefox' about:config to disable WebRTC on your device
4. Enforce the WS fallback for all devices by changing this line:

   PairDrop/public/scripts/util.js

   Line 41 in b36105b

   window.isRtcSupported = !!(window.RTCPeerConnection || window.mozRTCPeerConnection || window.webkitRTCPeerConnection);

   
   Into this:

   window.isRtcSupported = false;

   This way all clients broadcast that they do not support WebRTC.

If you worry about your privacy and try to hide your identity via VPN, step 2 or 3 would probably be wise regardless of PairDrop to prevent WebRTC leakage.

About your fourth point: I’m heavily rewriting the complete WebRTC part that was written for Snapdrop right now so I will probably get to this issue soon as well while I’m at it. I’ll add it to the pipeline for the next minor version.

[terrytw]

Massive thank you! I will definitely try step 1 and 4, they are perfect for my need. schlagmichdoch ***@***.***> 于 2024年2月4日周日 22:02写道：

…

There was a bug in a version some months ago that accidentally enforced all connections to be made via ws if the fallback was activated. You can try some things: 1. Set the iceServers of the rtcconfig.json to an empty array: this could enable devices on the same network to find each other: { "sdpSemantics": "unified-plan", "iceServers": [] } 2. Use uBlock Origin (or alike) to disable WebRTC on your device 3. Use Firefox' about:config to disable WebRTC on your device 4. Enforce the WS fallback for all devices by changing this line: https://github.com/schlagmichdoch/PairDrop/blob/b36105b1cf51332bab548bc85cf3745090d706d6/public/scripts/util.js#L41 Into this: window.isRtcSupported = false; This way all clients broadcast that they do not support WebRTC. If you worry about your privacy and try to hide your identity via VPN, step 2 or 3 would probably be wise regardless of PairDrop to prevent WebRTC leakage. About your fourth point: I’m heavily rewriting the complete WebRTC part that was written for Snapdrop right now so I will probably get to this issue soon as well while I’m at it. I’ll add it to the pipeline for the next minor version. — Reply to this email directly, view it on GitHub <#228 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFY26LFJ4JRB6EJXSHGP6JLYR6IHRAVCNFSM6AAAAABAXGND2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVG43DCMRTHE> . You are receiving this because you commented.Message ID: ***@***.***>

[swiftbird07]

What is the status on this? I would love the fallback to actually work. My use case is that if I want to share between two devices where one of them is behind a corporate firewall and therefore can't use my turn server, the fallback should be used.

[schlagmichdoch]

@swiftbird07 The project came to a halt for 1-2 months because GitHub falsely shadow hid my account and deleted loads of issues and comments. I have since restored everything back to its original state.

The implementation as a real fallback will be part of the next minor version v1.11.0 which is quite big (see #267). I’m currently testing all changes and should finish in a week or two. Are you willing to test the fallback feature on a development instance?

[swiftbird07]

Yes I would do that

[bt90]

@schlagmichdoch I took a look at the current codebase and apparently the websocket transfer uses base64 encoded content to be transferable as a single JSON message. Would it be possible to split this? e.g. send the control message as JSON and then send the data as a binary message?

The reason I ask is because base64 adds 33% overhead for each file.

[schlagmichdoch]

This was the easiest way to implement the websocket fallback as each message must also include the addressee to be able to relay it. Probably there are other optimized methods than sending it encoded as text. I also think all peer to peer communication should be at least transport encrypted as with WebRTC transfers but this too is not implemented yet. (See this comment and the following)

I'm open to ideas but would prefer to discuss them in a separate new issue as it is not connected to this issue.