mercora

that is not that either though or is it? i mean say i found my vehicle on some platform for sale and then located it with their service, now what? i call the cops i suppose, i dont see how this is much different to calling them once they agreed to meet somewhere.

If a thief is selling your stolen car, would that not be very easy to locate by showing interest in buying it? Am I missing something?

> it’s more than that. it’s any device that can present itself as a possible base station.

can you elaborate on this a bit? what devices are able to to present themselves as possible base stations? do i need any form of entitlement to participate in the network or not? From past encounters with SS7 and its, uhm, capabilities, it seemed the hardest part would be getting access to the network, albeit not hard really, it sounds like you were hinting at possibly gaining access by participating in the network without any official entitlement, by posing as a base station.

thats news to me, i dont use the app either. Thanks for sharing this.

its funny you call out Mullvad in this specific case because its the one thing i really dislike about their VPN service. It wont route DNS to the root server, or any designated server really. They redirect DNS queries to their cache indiscriminately. which actually will harm the success of setting up a recursive resolver. I get this is done to prevent leaks, i would just like the option to opt out of it. been customer for many years now though. I use unbound semi recursively resolving using a forwarder with DNS over TLS. So Mullvad is not burdened with what i resolve and the forwarder not with information on who.

For hard cutovers it might be a viable strategy to forward or redurect traffic inbetween changes. That is, either let the old destination forward to the new, or vice versa, then update the records to the new destination, or have an intermediary forwarding destination where you can change the destination address on an an instant and once settled move the record to that.

The recursive resolver you describe would adhere to the same TTL as would do any reasonable public resolver. The difference in cache behaviour, if any, only depends on if the resolver already has a cached record that's still valid or doesn't have it. That it won't have it just happens to be more likely as the amount of requests your resolver received is smaller as the case if you are it's sole user. It's possible to force the behaviour you described by using specialised tools that are meant to be used for analysis like binds dig utility with its trace flag. It can bypass any resolver by querying up from the root servers to the designated label without any caches being involved. You still only will know that other resolvers will receive the desired answer eventually. Only safe bet is to assume it will take the TTL until every will receive the updated record.

24h seems overly excessive but some resolvers may refuse to adhere to arbitrary low TTL and chose to answer with stale records from cache for as long as they deem necessary. 24h certainly would make many issues with that strategy very apparent.

agreed.

It's supposed to be on another independent device.

You can configure the agent to confirm each key usage to have your cake and eat it too. :)

It's also good to see if any malicious process tries to make use of the agent locally!

i think it cleared a thing up or two. However, would you mind sharing why insertable streams are apparently required for this to work? As WebRTC traffic is encrypted already E2E it seems to me that constructing the SDP with the key, currently used here with insertable streams, would be good enough.