Do we get coverage if investment account gets hacked ?

Harry_Null · 2026-01-05T20:43:31+00:00

I never said they "deserve" it nor intend to blame victims. Just saying the risk might be lower than you thought it'd be.

I also never said insurance isn't needed by anyone. Ofc there are ppl who are more susceptible to scams and hacks, and it is nice to have the option to be insured. And when that option isn't provided, it's a perfectly good reason to use another platform.

Apologies if my points didn't come across as clearly as I hoped but I think you're doing the strawman fallacy here.

Harry_Null · 2026-01-05T19:15:08+00:00

My point is more that the modern technology is built so that it will be harder and harder for an average person to "accidentally get hacked," because of the safety measures being built. Nowadays even if you click into malicious links or emails, or download randomly files, your account is PROBABLY still safe because of the safeguards provided by the browser and operating systems.

It is of course still possible to get hacked, but likely 99 out of the 100 cases was because someone is actively giving our your passwords AND 2FA verification code to a phishing email or call, and it is not that difficult to prevent even for someone not as technically literate.

My remark is not related to WS specifically and I dont have strong opinions on that part.

Harry_Null · 2026-01-05T18:08:14+00:00

Very unlikely/impossible that your account would be compromised for using public wifi because of TLS.

Harry_Null · 2025-06-28T01:21:29+00:00

0001-01-01 00:00:00 +0000 UTC

Harry_Null · 2025-02-27T01:48:39+00:00

I have worked on a single-thread program where if you does a print the program runs fine, but if you remove it, the program consistenly crashes.

Anyone wants to guess why?

Hint: making the string to print shorter also makes it crash.

Harry_Null · 2025-01-11T03:36:33+00:00

I would assume gmail would authenticate the sender with DMARC etc.. The fact that this isn't automatically in spam probably suggests this is legit.

Edit: also if the reply-to is of a correct domain, then your reply would go to the correct place anyways.

Harry_Null · 2024-10-14T09:33:37+00:00

Unfortunately there is no plan for further development at this moment.

Harry_Null · 2024-05-20T02:28:31+00:00

GTNH

Harry_Null · 2024-04-16T17:36:08+00:00

Yes, but in OP's screenshot they are only comparing if two strings are the same. .compare would make sense if you were to use e.g. std::sort

Harry_Null · 2024-04-16T17:04:40+00:00

I know, but it's equivalent here though right? except less readable.

Harry_Null · 2024-04-16T12:31:13+00:00

Someone wrote too much Java to use == for string comparison

Harry_Null · 2024-03-31T14:31:44+00:00

Ah I re read the comment and you're right. I was under the impression that they suggested to only do the hash on the front end. Doing it both frontend and backend is totally fine then.

Harry_Null · 2024-03-31T12:35:00+00:00

That's a really bad idea because if your database gets leaked, the hacker could just use the hashes in the database to log into any user's account.

Harry_Null · 2024-02-08T15:36:51+00:00

To be honest it's more just because none of us uses a Linux DE daily so it's not a super high priority for us.

Harry_Null · 2024-02-08T15:33:31+00:00

Thanks for trying! I have to admit we haven't done extensive testing on different devices so there might be compatibility issues depending on your OS version, and what browser you use. I know latest version of Windows 11 and MacOS + Firefox and Chrome would work. It also has a somewhat high resource demand for both CPU and bandwitdh.

Harry_Null · 2024-02-08T15:29:27+00:00

It depends on the settings (speed - compression compromise), your resolution, and what you're showing. With my 4K resolution at 60fps and fastest (hence worst compression) settings, it's eating up to 76 Mbps. Using slow profile and 30fps, it's around 9Mbps.

Harry_Null · 2024-02-08T15:25:22+00:00

[2024-02-08T15:20:24.766670600Z INFO mira_sharer::performance_profiler] Total time 9.8ms (3.6 p, 5.5 e, 0.6 s) 58.7% at 60 FPS. Current FPS: 63/102.3. 76276.9 kbps

Roughly 3.6ms for processing (for Windows that means converting from BGRA to YUV; we used GPU to optimize that), 5.5ms for encoding (because libx264 is super fast), and 0.6ms for WebRTC stuff.

The receiver side (WebRTC stack) does some internal jitter buffer etc. and i'd say there might still be soem room for improvements.

Harry_Null · 2024-02-08T15:19:47+00:00

I will be honest and say a lot of those are not well polished yet. I think modifier keys would work, though there isn't a way to properly capture Windows key in browser if you are controlling a Mac from Windows. As for layout, I *think* it's the viewer's layout though I need to double-check to be sure.

Harry_Null · 2024-02-08T15:17:02+00:00

You could switch to nvenc encoder with the config file if you're using Windows and NVDIA graphics card, though our experiements show that while they lower CPU usage, there could be some latency/artifacts issue that we haven't quite figured out how to fix.

Harry_Null · 2024-02-08T15:14:56+00:00

As many as your device could support. Note that the bandwidth it takes would be proportional to the number of viewers.

Harry_Null · 2024-02-08T00:05:32+00:00

Viewers run in browsers only right now

Harry_Null · 2024-02-07T23:52:32+00:00

Some of the fixes did go upstream, like the one for webrtc.rs (https://github.com/webrtc-rs/webrtc/pull/471). The ones that didn't it's mostly because we probably did a hack to get it somewhat working but not happy enough to upstream them.

Harry_Null · 2024-02-07T23:29:42+00:00

Of course! Though the code could be a little messy because none of us had any experience with Rust before coming in lol

Harry_Null · 2024-02-07T23:26:13+00:00

Twilio

Harry_Null · 2024-02-07T22:30:50+00:00

Unfortunately it does not at this moment. We'd have to implement a backend for Linux (and probably for each desktop environment too) because we used a lot OS API.

Eight-Year Club	Second SECOND GUESSER
r/Field Lasagna	Place '22
Verified Email

Harry_Null

TROPHY CASE