This is good and clever work, and I applaud the author for looking at a boring feature and seeing in it a potential attack vector that probably wouldn't have occurred to most people. Kudos! That said, I think the security implications are pretty minimal.
(FWIW, iOS and MacOS do the exact same thing, opening captive.apple.com and showing whatever it redirects to if you're on a captive portal network.)
This behavior does incur a security risk, but using public wifi networks is basically impossible without doing this check either automatically or manually, and most users would be completely bewildered if the OS did nothing to prompt them when they needed to click through a page to make the internet work.
Moreover, if you can MITM the network and they're not tunneling their connection, you have lots of great ways to send them hostile code already! You can use classic SSL stripping to just send them whatever you want! (Granted, a lot of traffic goes straight to HTTPS these days, and browsers are getting wiser about this with HSTS and things like the new automatic HTTPS upgrade in Safari).
If you're paranoid enough not to want to run untrusted javascript (fair enough), you shouldn't be connecting to weird public wifi networks anyway.
I believe NCSI probes are also purposefully HTTP because captive portals MITM all traffic to force authentication. If it was HTTPS the probe would fail with a certificate error. The whole point is that the url can be hijacked. This is not really a vulnerability, they have just independently discovered this feature.
The certificate error is of itself diagnostic of a portal rather than a proxy. The reason to use HTTP, is that some portal systems just drop TLS connections until authenticated. (Which is the correct behavior, rather than MITM.)
Opening the browser automatically is a big bug, that should be easy to fix.
A very similar thing happened when the folks at flathub tried to package MultiMC. Unfortunately the author threatened to sue for trademark infringement and they backed down.
Huh, I'd been pretty happily using MultiMC for some time and even thought they were in the right of the Forge dispute. Might have to look for alternatives next time I get back into Minecraft.
One of the recent phones (X or 11?) used Intel for part of its builds (as far as I remember you couldn’t tell from serial number). Apple had a lot of problems and swore off the Intel parts, which killed Intel’s wireless business.
I assumed Apple bought the Intel product line for IP, especially after that episode.
Apple used Intel modems for many generations - the iPhone 7, X/8, XS, 11. For some generations they used Qualcomm chips in the models for CDMA regions since Intel didn't make a CDMA modem. So you could tell which chip you'd get from the iPhone model number.
Apple ditched Intel due to Intel being at least a year behind on 5G.
These modems were all LTE modems though. They've always used separate Broadcom chips for WiFi/Bluetooth.
> "For some generations they used Qualcomm chips in the models for CDMA regions since Intel didn't make a CDMA modem."
Yeah. The Qualcomm-equipped international version of the iPhone X notoriously got significantly better LTE speeds compared to the Intel-modem version sold in UK/Europe.
the iPhone 7 used the intel wireless chip. it was a major downgrade for me from my iPhone 6 at the time: speeds were lower for data transfers, and reception was less (could be attributed to an antenna change?)
overall, I was very happy to get a phone that didn't use the intel chips.
I was under the impression that modern laptops ship with intel WiFi cards (I think I saw some Lenovo laptop use it). Do you mean it killed their modems ?
Wait, this just looks like cryptographically signing pictures. What's so scary about that? You can do it today from your terminal if you feel like it.
I guess I agree that the 'trusted computing' stuff it seems like they're trying to do is a little scary, but the tech isn't really there yet, at least not on the desktop (look at the fiasco that is Intel SGX) and it's happening with or without whatever this CAI thing is.
I guess a world where your iPhone's camera sends signed frames to the processor's secure enclave which processes them and signs them with a key signed by Apple is... a little different from today? They do basically this for Face ID today.
If it's a simple proxy tunneling HTTPS traffic to Google, Apple probably doesn't know anything about the content of the queries, and Google doesn't know who sent them. If each kept records, they could get together and combine them to get the hashed URLs, but still a much better situation than directly querying a single endpoint.
AFAIK the fundraising done by actual elected officials is not highly automated, but tools for phone banking, canvassing, and that sort of organizing are definitely partisan (see for example https://act.ngpvan.com/paid-phones on the Dem side).
>From those cases, we distill two general rules in analyzing authorization under the CFAA. ... Second, a violation of the terms of use of a website--without more--cannot be the basis for liability under the CFAA.
They say this because (Id. at 1076):
>"Not only are the terms of service vague and generally unknown . . . but website owners retain the right to change the terms at any time and without notice." [676 F.3d 854 (9th Cir. 2012)] at 862. As a result, imposing criminal liability for violations of the terms of use of a website could criminalize many daily activities. Accordingly, "the phrase 'exceeds authorized access' in the CFAA does not extend to violations of use restrictions. If Congress wants to incorporate misappropriation liability into the CFAA, it must speak more clearly." Id. at 863.
Interesting. TOS can't be a 'catch all'. There needs to be another criminal intent. But, wouldn't using the plugin to avoid paying for the service be the other crime? Seems like two crimes? Which would satisfy?
(FWIW, iOS and MacOS do the exact same thing, opening captive.apple.com and showing whatever it redirects to if you're on a captive portal network.)
This behavior does incur a security risk, but using public wifi networks is basically impossible without doing this check either automatically or manually, and most users would be completely bewildered if the OS did nothing to prompt them when they needed to click through a page to make the internet work.
Moreover, if you can MITM the network and they're not tunneling their connection, you have lots of great ways to send them hostile code already! You can use classic SSL stripping to just send them whatever you want! (Granted, a lot of traffic goes straight to HTTPS these days, and browsers are getting wiser about this with HSTS and things like the new automatic HTTPS upgrade in Safari).
If you're paranoid enough not to want to run untrusted javascript (fair enough), you shouldn't be connecting to weird public wifi networks anyway.