koobas.hobune.stream
Question is off-topic or not relevant
Add .NET Socket capability to WebGL.
The Answer is: The only option for bidirectional socket support in WebGL is websockets.
Sorry but you interpreted the documentation wrongly. It says:
Due to security implications, JavaScript code does not have direct access to IP Sockets to implement network connectivity. As a result, the .NET networking classes (ie, everything in the System.Net namespace, particularly System.Net.Sockets) are non-functional in WebGL
This is not a limitation decision made by Unity but a general security feature of the sandbox system of web browsers. Websites are not allowed to make arbitrary network connections as this is would be a high security issue. That's why websockets has been developed.
If you read a bit ahead in the documentation you will find:
Unity Networking supports WebGL by enabling communication via the WebSockets protocol.
Unity has essentially deprecated all of it's network solutions up to date, but they still work. You should look up some general information on web security and the websockets protocol. For actual real time bi-directional network traffic, websockets are your only option in web applications.
Note that under no circumstances can a web application open a listen socket. You always need a server application to connect to. In the past Unity offered the UnityWebPlayer browser plugin which is essentially a native code plugin which of course could implement whatever you like. However since all major browers have dropped the native plugin support for security reasons, using websockets is your only option at the moment if you want to target webGL.
I also don't quite see why https should be any less secure than any other socket connection. https is already pretty much immune to any man in the middle attacks if proper certificates are used. If you are worried about players / users fiddle with the locally executed code, there's no way to make that "secure".
First, thank you for replying. I appreciate the effort you put in for your reply.
Let me know if this is accurate, you are saying that the only option for bi-directional socket connections is to use websockets in webGL. As for the other stuff... I'll address it anyway.
In terms of security, web technology is historically and factually, horrendously bad regardless of any security measures you take. Period. Web sockets are upgraded from an HTTP(S) call which means that at the very base it is as vulnerable as HTTP(S) is.
This part: "I also don't quite see why https should be any less secure than any other socket connection. https is already pretty much immune to any man in the middle attacks if proper certificates are used. If you are worried about players / users fiddle with the locally executed code, there's no way to make that "secure"."
Here are some facts: JP $$anonymous$$organ spent $500 million on cybersecurity in 2018. Their general counsel came out and said they still feel challenged. Binance was hacked for $58 million despite the security measures they put into place. Bithumb was hacked 3 times, despite their security measures. NASA was hacked with a Rasberry pie web server and lost dozens of Top Secret Documents. $$anonymous$$arriott lost 500 million user accounts (That's everyone right?) City of Baltimore hacked with ransomware early 2019. University of Canada's entire network hijacked by a javascript based crypto-jacking attack.
What do they have in common? Every single one uses Web Technology: Browser/app, HTTPS, Web Sockets.
HTTPS is well known in the world, well known to hackers, well known to cheaters for games, etc... The internet and the web are two different things. $$anonymous$$an in the middle attacks are completely an issue even today. Javascript payloads delivered to environments is 100% an issue.
HTTPS is a problem because it's part of web technology: browsers, https, and web servers and it is what everyone uses. I don't use web technology in my games or applications. I have an end to end custom build solution in Unity that I built from scratch on my own. I built everything from the application, the custom messaging, and the back-end server with and in Unity, and I obfuscate my client and rotate custom certificates that I build myself weekly.
The web was never built for security, and javascript is the worst offender. Out of 180,000 websites and 94 popular plugins 30% have at least ONE vulnerability and it takes an average of 3 years to fix ONE vulnerability. So let's not talk about how web tech is secure. That's only the beginning, that doesn't touch web app, OS's, or web server vulnerabilities, etc...etc..
Ultimately. The point here is that HTTPS and web sockets are the only option and I appreciate you pointing that out as disappointing as that is.
You clearly have a clear-cut opinion on the matter, but let me ask you one thing. Are any of the attacks you listed caused by https? That would surprise me. $$anonymous$$ost attacks are simply servers that don't sanitize inputs, have user-triggered memory unsafe operations, use out-of-date software, or simply have human errors, like plugging external hardware on sensitive machines, bad passwords, or not securing the platform at all. I doubt your custom implementation of secured signed sockets is safer than https. And if it is, you can just add it as another security layer on top of https, with no difference to you.
You know what's one major source of vulnerability? People without the qualifications coding sensitive code from scratch ins$$anonymous$$d of using the industry standard.
Why do you want to add .Net Sockets to WebGL?
There is a FM WebSockets Live Streaming Demo, which you may be interested:
https://www.youtube.com/watch?v=82_-a7WF3vs
It's included in our full package FMETP STREAM.
Asset Store: http://u3d.as/1uHj
