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 used to use [0]s3ql on-top of "slow" fuse storage. it comes with its own caching layer and some strategies around handling larger blobs of data efficiently even at high latency with ease but its a non shared filesystem. you mount/lock it only once at a time. otherwise this was a perfect solution to me at the time.

there is also [1]rclone with its own caching layer and own support for various backends directly. I don't remember anymore why i did prefer s3ql though, but i usually have some reasoning with things like this..

[0]: https://github.com/s3ql/s3ql [1]: https://rclone.org/

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.

I wish browser would do something similar with their WebRTC stack. Something that shows independently of the site (out of its execution context) which keys are used and allow for an easy comparison of them independently. But i don't know of such functionality being there yet.

>As a side note, this is why we built Booth.video -- to demo that this isn't a fundamental tradeoff and it's possible to have E2EE, metadata-secure video conferencing in the browser.

now i wonder how you did that. Is the key exchange of participants happening out of band?

E2EE implies both ends have an encrypted channel to transport data to each other directly, without an intermediary step. this is the very definition of the term, at least it is in my mind. Having the data only encrypted to and from their servers would merely be transport layer encryption. Although i have no idea whether they implement one, the other or both.

In context of video conferencing software (WebRTC specifically) this is actually somewhat interesting, because typically the signaling server is the one who hands out the public key of the other peer and needs to be trusted, so they could by all means deliver public keys to which they posses the keys for decryption and it therefore would allow them to play man in the middle in a typically relayed call. So even if E2EE is implemented, it might be done poorly without figuring out how to establish trust independently.

i think SRV records might be more appropriate for this use case.

more precisely a CNAME must be the only record type for a given label as it would be otherwise ambiguous to revolvers. that doesn't hold true for DNSSEC secured zones where the records for signatures are to be allowed, but also arent creating any ambiguity on how to resolve queries. the apex must have NS and SOA records for a minimum to work so that rules out any CNAME in addition to that. an apex without any other record but SOA and NS would work fine though. so saying it needs to be an A record implies the wrong thing.

just so you know, your assumption i am not using the right tools feels almost insulting to me considering i made no claim about any tooling used. i am using systemd-networkd to setup networking anywhere, i never touch wg-quick because it is no fit for my use cases. i have multiple routing tables and do policy routing and i would really like to have the "via" in the routing tables to have a meaning to wireguards crypto routing thing. i.e. i want to be able to set "AllowedIPs" based upon the routing table very similar to reverse path filtering. i know i can setup multiple interfaces with multiple keys to exchange and multiple ports to set and to make sure every client that needs to is kept in sync.... but it would be much nicer if i could handle it like an ip-ip tunnel and make routing decisions with software build for this purpose.

i just wish i could control the routing via routing tables instead, making dynamic routing decisions possible without specialized software that is able to manipulate it.

i use policy routing and let wireguard mark packets it wants to send out. the main table is empty (there is no route... at all..) external connections insert routes into their own tables. the wireguard interface does this too and any packet not marked by wireguard will use this routing table... if wireguard is missing nothing marks packets to leave at external interfaces. i have an additional rule that prohibits any traffic that did not have a route in any table applicable at the end of the policy rules

i mean sure there will be several dozens ways to compromise your machine once your user account is wide open already... but allowing any script or software to run any command privileged without any questions asked? there is certainly a risk attached to that and not even necessarily related to an active attack... you are one badly written script away from doing something dumb without even noticing it...

and not having to confirm anything to use your ssh keys means not only your machine is compromised but all of those that those keys allow access to are potentially compromised too now... i use an ssh-agent (gpg-agent implementation) to only ask once at the start of my session for the password and every time for confirmation of usage or after some time without usage it will ask for the password again. its not annoying at all...

what i do for work is very close to what you want and its pretty easy to achieve with using lightdm and the dm-tool with the add-nested-seat command. It will start a new Xephyr X server local to your current user and attach the session manager to it. from there you just login and have the second user session in a window just like you wanted... however, i did not get clipboard sharing to work but i actually like this extra bit of isolation.... its not even hackish and performance is exactly as native because it is... its a bit harder to get sound working concurrently, but not impossible, although i never really tried. However, i use pipewires pulseaudio interface to stream audio to a remote AV receiver in the room and this should work fine in the second user session too, although as said i never bothered to try...

just want to make it clear, usually you are assigned a prefix which you can announce to your network and then nodes will pick random addresses from that prefix. its still easy to determine the packets came from your network just not clear from which device exactly much like current NAT setups lets say...

ive seen it few days ago while using the installer on the netinstall iso.. its an option to import keys from github while creating the regular user...

i wonder if i am allowed to transmit such signals, maybe with some ham license? also, i read "exposes the RF link as just another Ethernet interface" a little wrong. its not like this will demodulate ethernet somehow but extracts frames from the transport stream using usual DVB mechanisms (i.e referencing the data stream in the PAT and similars) or am i wrong?

> “To help you see that we are sincere, we would like you to check out the following”

really would like to know what this was about and what else the voices in her head told her, especially unrelated stuff. Also if she could talk to them and if so what it was like to have a conversation like that.

i guess i am more on the X-phobes side on this one as i also suspect this woman knew about her tumor and came up with that story because she had to avoid telling the full truth for whatever reason and "this is the easiest way I could think of". However reading more about what happened with these voices while they were active would likely help me to trust her story more...

i did not know about these[0] keywords so thanks for that :)

[0] https://docs.github.com/en/search-github/searching-on-github...

i wonder how many people were asymptomatic and thus weren't even aware. maybe those long-covid symptoms get diagnosed as something else if there is no known previous infection.

i am not entirely sure i fully agree. telecoms never sold us a service to authenticate us to 3rd parties. those 3rd parties did bolt it on-top of an arguably insecure message transmission system. it wasn't meant to be used like this and maybe its even a bad idea to use it like that. the assumption only you yourself could receive these codes because you are authenticated against your mobile network provider might just be wrong here.

of course, letting the actual sim swapping attack work is an issue they should be required to solve. but for entirely different reasons. once you are authenticated to their network you can cause substantial costs for the real owner of the contract for example and those costs would definitely be compensated to their clients if this happens without their involvement. but if your assumptions break because of this issue your assumptions are wrong in my opinion and you would be the one to blame.

a simple analogy here could be you park your car in front of a police station, because nobody would dare to steal your car right in front of the police right? but then your car still gets stolen and you think you should try to sue the police because that just happened.

on the other hand coinbase did made that assumption and has been proven wrong in this way. they did bet on using the telcos messaging systems being secure enough to be used for authentication. that did not work out and this caused people to lose money which should be compensated for, by coinbase, because they decided to do that and not the telecoms.