451–460 of 470 posts
Earlier quoted context omitted.
I don't know who to attribute this to but I've heard a saying: "Countries that trade with each other don't make war with each other." As we isolate countries and disrupt trade we definitely are increasing the risk of conflict.
Yes, who cares about the forced labor camps and suicide nets around factories. I want my cheap plastic consumer devices!!
Earlier quoted context omitted.
Also the Great Firewall isn't one box admin'd by a single actor. It's a set of network firewalls managed by different network entities to fulfill legal obligations. It could be one of them acting alone. Then there's the question of how separate the operating company is from the Party..
Acting alone? Yeah right. Do that in the PRC, and you'll probably be in a "reeducation camp" by the end of the week.
Earlier quoted context omitted.
Pretty sure they don't care. They're also directing lasers at helicopter pilots, which is much closer to a actual war than mere bits. https://www.abc.net.au/news/2019-12-06/chinese-fishing-vesse...
The protesters in Hong Kong were also directing lasers at police and police helicopters. I don’t think that should be considered an “act of war.”
Earlier quoted context omitted.
> The recent popularity of clipboard permissions, geolocation permissions, notification permissions, etc. would suggest otherwise. What popularity? Do you have data that users tend to click "yes" on such permission prompts? > What makes you so sure that web users care so much about the uptime of lihkg.com ? I'm not sure I understand what you're asking or what you're responding to.
> I'm not sure I understand what you're asking or what you're responding to. lihkg.com being down is the negative consequence of this code running, right?
https://web.archive.org/web/20191206074255/https://cybersecu...
Too often I cannot browse anonymously because people abuse Tor to aggressively scrape things. Don't do that!
Earlier quoted context omitted.
It is possible: De-peer AS4134 (China Telecom) and reject all of their routes. They are the only international ISP that lands into mainland China. They are extensively peered around the world.
It's not just them. AS4837 (China Unicom) and a few others who have intl permission to route in and out of China. That said, you're going to hurt a lot of non-china multinationals who operate there.
Not my problem. Figure out a better way than getting in bed with fascist countries and then complaining when the inevitable door swings shut due to rightful backlash.
Earlier quoted context omitted.
TLS should be required, but it seems likely to me that the Chinese government can issue TLS certificates for MITM purposes that their browsers will trust. As for the DoS aspect, maybe it's time to do a CORS preflight on ALL cross-origin requests, including images. (Webfonts, for whatever reason, already require a CORS preflight. Probably because Adobe is on the W3C and they sell a service where certain origins can le…
> But with evidence of the CA issuing fake certificates to DoS websites, browsers would probably stop trusting that CA entirely. "Hey Tim Apple/Microsoft/Google, if you want to do business in China you have to put our CA on your devices/software...". At least Firefox would still be free from that. And Apple already has China-specific iOS, so they'd just activate the bad CA on Chinese devices...
Earlier quoted context omitted.
> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol,…
Why do they have to use self-signed certs? Ship the device with a valid cert for $last_three_octets_of_mac_address.$vendor.com to the device, and print it clearly on the setup instructions. Typing in something like d63d15.ui.com isn't onerous. The CA/Browser Forum allows certs up to 27 months - do routers sit on store shelves for 27 months before being configured? Do they even sit for 12 months? (Once they're online,…
Browsers and the people who sit on these committees are understandably more focused on their own use cases, but there really does need to be a viable certificate solution for small embedded devices, preferably works with mDNS too. I'm not going to hold my breath, but until this happens any/all IOT devices will remain largely insecure. Big co's (like my employer) can develop and deploy a custom solution, most companies cannot.
Earlier quoted context omitted.
Could you expand on that a little? What do you mean? Won't my browser complain if the cert if self signed?
Yes, it will complain and for good reason: it has no way of knowing whether the kid next door is spoofing your router's IP or Mac address and presenting their own self-signed certificate. I wouldn't go as far as calling it «capricious constraints imposed by the system of "certificate authorities"» but at the same time, I agree that it's not a fundamental limitation of the technology. Better protocols could be develop…
- let companies register a wild card domain in the .local (or a newlocal) namespace: .acme.local
- designate the acme company with the ability to issue certs that never expire for any name in ".acme.local" but the browser will refuse to use certs signed with that key for anything outside "*.acme.local"
pros:
- the acme company can now make equipment that the users browser can connect to over an encrypted channel with zero config on the user's part
- the equipment can live off the internet indefinitely
- if the acme company is breached, and their signing key is stolen, the attackers can only use that key to impersonate acme company, it doesn't allow them to impersonate any other domains
cons:
- the browser manufacturers don't care about this use case so its never gonna happen
- the cert on the device never expires... and can never be replaced automatically somehow. I think the only workaround is acme could enable users to load their own certs if they are so inclined, but that shouldn't be required.