Natanael

Keep in mind that because few residential users max out capacity simultaneously the ISPs "overbook" capacity, and usually this works out because they have solid stats on average use and usually few people need the max capacity simultaneously.

Of course some ISPs are greedier than others and do it to the extreme where the uplink/downlink is regularly maxed out without giving anything near the promised bandwidth to a significant fraction of customers. The latter part should be disincentivized.

Force the ISPs to keep stats on peak load and how frequently their customers are unable to get advertised bandwidth, and if it's above some threshold it should be considered comparable to excess downtime, and then they should be forced to pay back the affected customers. The only way they can avoid losing money is by either changing their plans to make a realistic offer or by building out capacity.

I'm tech support so I've seen some stuff, sooo many intranet sites on internal servers don't have HTTPS, almost only the stuff built to be accessible from the outside has it. Anything important with automatic login could be spoofed if the attacker knows the address and protocol (which is likely to leak as soon as the DHCP hijack is applied, as the browser continues to send requests to these intranet sites until it times out). Plaintext session cookies are also really easy to steal this way.

Chrome has a setting which I bet many orgs have a policy for;

https://chromeenterprise.google/policies/#OverrideSecurityRestrictionsOnInsecureOrigin

Of course they should set up TLS terminators in front of anything which doesn't support TLS directly, but they won't get that done for everything

These types of attacks would likely be implemented via DHCP spoofing / poisoning, unless you're on a malicious network

Plaintext connections inside corporate networks can still be MITM'ed if the adversary knows what they're targeting, while they can't connect to the corporate network they can still steal credentials

Hilariously enough, Windows users can use WSL to run a Linux VPN (but only applications running in WSL are safe if I understand the attack right)

Yeah, it's like a fake traffic cop basically, sending your (network) traffic down the wrong route

Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface. This is intended functionality that isn’t clearly stated in the RFC. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.

Ok, so double encrypted and authenticated traffic (TLS inside the VPN) would still be safe, and some stuff requiring an internal network origin via the VPN is safe (because the attacker can't break into the VPN connection and your client won't get the right response), but a ton of other traffic is exposed (especially unencrypted internal traffic on corporate networks, especially if it's also reachable without a VPN or if anything sends credentials in plaintext)

When the oil industry doesn't have to pay to clean up their externalities we already don't have a free market. You break it you pay. Fixing the externalities by incentivizing better technology is at minimum a correction to the market.

Something something legal precedence. This hasn't gone through court yet, has it?

It doesn't matter if there's patches to make it work specifically, if they don't contain Nintendo's code. At most they could accuse whoever contributed the patch with piracy / breach of NDA or similar for having downloaded the ROM prior to release (couldn't have purchased it) but that doesn't impact the emulator itself

That's not code and Texas Instruments already lost on that one

With DMCA get uploader is supposed to get notified and get a chance to file a counter claim