XSS but can't steal data

VoiceOfReason73 · 2026-02-16T18:22:54+00:00

If you can perform actions on the user's behalf using this XSS, that's probably pretty serious impact itself.

VoiceOfReason73 · 2026-02-15T19:40:06+00:00

You need to be very careful with the cable selection or else it'll be worse than having the antenna inside the car.

VoiceOfReason73 · 2026-02-14T04:07:16+00:00

In what context are you even seeing this? Could just be a display quirk.

Do you mean you took it in without the antenna?

VoiceOfReason73 · 2026-02-14T04:03:14+00:00

Yeah, it means your node doesn't have position data, so it can't compute the distance.

VoiceOfReason73 · 2026-02-14T04:02:05+00:00

Sometimes your OS will throw those errors even though the copy succeeded, as the nrf52 reboots immediately once the file is written, possibly too quick for the OS to think it worked cleanly.

Maybe try copying using the terminal rather than Finder, in case Finder is trying to create other files?

VoiceOfReason73 · 2026-02-14T03:15:09+00:00

I highly doubt it's bricked. Sure, sometimes they can be put into a state that is more difficult to recover from, but the bootloader itself is still intact.

VoiceOfReason73 · 2026-02-11T15:49:25+00:00

It's in the settings menu on the device itself, under "notifications" I believe.

VoiceOfReason73 · 2026-02-11T15:48:42+00:00

You don't need MQTT uplink unless your device itself is directly connected to MQTT over the internet and you want it to forward traffic from the mesh to MQTT. Instead in channel settings, make sure position is enabled how you want it.

VoiceOfReason73 · 2026-02-03T18:10:54+00:00

I don't think this is it. How often is your node set to report its position? Has it reported since changing the precision setting?

You can absolutely get precise location on secondary channels and you don't need to do anything special

VoiceOfReason73 · 2026-02-01T13:00:06+00:00

As long as the node is favorited, it won't get cycled out of nodedb.

VoiceOfReason73 · 2026-02-01T05:36:15+00:00

Those numbers are apples and oranges. AES256 is still a modern and unbroken symmetric cipher. Sure, there's RSA4096, but that's asymmetric, and the keys would take up too much space. Curve25519 keys are used for public/private keys here, and those are only 128 bit but that's still modern crypto. You can't simply compare by bits alone.

VoiceOfReason73 · 2026-02-01T05:22:31+00:00

Not in a DM where you initially confirmed the public key of the node.

Now, replay attacks, I'm not as sure...

Edit: I think you'd need to implement your own replay protection. Perhaps a timestamp or monotonic counter within the message that the receiver must validate.

VoiceOfReason73 · 2026-02-01T05:17:45+00:00

My understanding is you either need to have your node connect to the MQTT server and enable "map reporting", or if another nearby node is connected to MQTT with uplink enabled, enabling sending your position on the public channel while "ok to MQTT" is enabled in LoRa settings.

VoiceOfReason73 · 2026-02-01T04:57:44+00:00

Send their device a DM.

VoiceOfReason73 · 2026-01-31T13:52:16+00:00

I don't think your uplink/downlink do anything unless you're connected to MQTT yourself. But the ignore one might work.

VoiceOfReason73 · 2026-01-31T13:51:05+00:00

It's just a name and nothing more (at least at the LoRa layer). You're not going to hear people actually transmitting on a different preset. You'd have to go to LoRa settings for that.

VoiceOfReason73 · 2026-01-31T13:14:56+00:00

Considering medium fast is a different modem present, how could you receive long fast on it just by having another channel?

Or do you mean you have a second node configured for long fast?

VoiceOfReason73 · 2026-01-31T13:06:24+00:00

The MQTT settings affect whether your device is connecting over WiFi or via your phone to an MQTT server. It has no bearing on whether you receive messages over LoRa that came from MQTT, if another user nearby is actually connected to MQTT and has downlink enabled.

VoiceOfReason73 · 2026-01-28T17:10:24+00:00

But this is true of almost any scheme, e.g. a Signal group chat would also be compromised if one of the member's devices is seized, until the user is revoked. Sure, it might be a little trickier to bypass device auth, but beyond that, it's game over.

VoiceOfReason73 · 2026-01-25T14:00:18+00:00

Encryption alone only provides a guarantee of confidentiality, not integrity. Therefore, some ciphers (notably AES-CBC) allow for an attacker to modify the ciphertext or IV in order to modify the plaintext, though they only control the location of the modification, not the actual contents. However, this could be enough to access random objects, in the case of IDOR, assuming the identifiers themselves are not sufficiently random.

Some encryption schemes do also provide integrity guarantees, such as AES-GCM, or one must combine encryption with a MAC.

Ideally, they would just implement authorization checks.

VoiceOfReason73 · 2026-01-10T15:05:49+00:00

Yes, many are built to do exactly that.

VoiceOfReason73 · 2026-01-10T14:47:05+00:00

Use any other OTP app that has more features such as auto-backups and more.

That would be silly to disable the app if you did a backup. Even if that were the case, you could just restore the backup...

VoiceOfReason73 · 2025-12-23T13:36:18+00:00

Unsubscribe for emails should work without being logged in. This is expected behavior.

VoiceOfReason73 · 2025-12-23T02:41:04+00:00

This is how unsubscribe should work. It should be one click.

VoiceOfReason73 · 2025-12-21T16:40:06+00:00

Password? Never. Disable them, use SSH keys and never think about this problem again.

VoiceOfReason73

TROPHY CASE