If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.
5GHz certainly helps, but congestion/co-channel interference can still be an issue in high density environments, especially in a multi-user environment like an apartment complex where nothing is coordinated. The addition of 6GHz will help alleviate this problem too, but a lot of consumer gear seems to default to the widest channels possible.
Also, your glass door probably has Low-E glass which has a metallic coating.
> The future is probably just having multiple wifi APs wired up and then just running extremely fast but low range wifi.
This is somewhat the case, but it is limited. For example, in 5GHz there are 21x 20MHz channels available. In a highly dense environment, this can support roughly 30x devices per channel well and 50x devices per channel with some degradation.
Limiting the TX power on an AP can help, but it's not a panacea since clients always transmit their control frames at their default power (usually ~15dBm). There have been some improvements to this in .11ax, but depending on the spatial organization of the devices, it can only do so much.
The paper's claim for Dijkstra's is it's "a single algorithm performs as well as possible for every single graph topology". A* is an augmented version of Dijkstra's only applicable when there is a priori knowledge of a good heuristic for the topology (e.g. manhattan distance in a cartesian plane). Since there is almost certainly no heuristic that is universally optimal for all topologies, A* shouldn't be more universally optimal than Dijkstra's (and can probably perform worse given a bad heuristic).
802.1x allows for the client to validate the authentication server by way of X.509 certificates, although this normally does require manual configuration since there is no global namespace to tie an ESSID to like there is for domain names in normal TLS. Mutual asymmetric key auth is available through EAP-TLS as well, but I could see that being a rare feature on cameras.
Actually, why there is not? Company should be able to just get cert for wifi.company.com and then be allowed to just call its network wifi.company.com...
As of TLS 1.3, the ClientHello (which includes the Server Name Identification (SNI) extension) is still sent in plaintext. There is a current draft for encrypted client hellos[0], but I don't think its adoption is widespread. QUIC appears to encrypt the ClientHello; however, it does not protect from an attacker which can observe the initial connection packets[1].
It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.
MOSH already exists, and it is a proper ssh-like protocol over UDP that takes advantage of the properties of UDP. It's great for use when traveling and being forced to use horrible high latency wireless connections.
MOSH is really a on-purpose "horrible SSH" as far as SSH goes, but it is instead intended to be what you actually need for remote, unstable, unreliable slow connections: a somewhat reponsive experience, a kinda of remote desktop protocol but for terminals, you only send the input and output deltas; you intentionally don't block waiting at any side for precise confirmation of every single byte in or out of a remote terminal.
TLS doesn't matter / isn't needed here right?
The IP address is still in the header from what I understand. So the only thing https can hide is the content, such as a credit card or password that you enter into the site.
The fact that it's a plaintext website that doesn't change means that the exact same information is encoded in simply giving the IP address as there is in knowing that someone looked around the site - because there's nothing else to do?
I would like to learn more about how I am wrong, if I am wrong.
> So the only thing https can hide is the content, such as a credit card or password that you enter into the site.
TLS is not only for hiding the content, it's also for authentication: it ensures that no malicious middle party can modify the content, for instance to inject malicious Javascript (for an example of this happening, read about the "Great Cannon" attack on GitHub).
It also hides what URLs you visited. Depending how the hosting is implemented, just being able to see the IP, or even the domain name, wouldn't show what you were doing, but if it's in plaintext, they can see exactly what pages were visited and files downloaded
I had to look, but in the case of libgit2 yes they have. Like git they have a way to select SHA-1 backends, and the default is the SHA1DC library.
But, even supposing a libgit2 that didn't use SHA1DC I think most users would be protected in practice if the "git" they use used SHA1DC. Hosting providers, local editors etc. use libgit2 for a lot of things, but I think in most cases (certainly in the case of the popular hosting providers) it's some version of "/usr/bin/git" that's handling your push, and actually propagating your objects.
For stopping a colliding hash it's enough that any part of the chain of propagation is able to stop it.
I have found brave to be a decent chromium-based browser for android if the only addon needed is for ad blocking. It has a bottom toolbar provides a similar experience to the firefox bottom address bar.
reply