From my reading, it looks they're considering this for only non HTTPS downloads initiated from an HTTPS page
Relevant quotes:
> ... we will likely start by treating certain high-risk downloads initiated from secure contexts as active mixed content and block them.
> We're not planning to focus on non-secure downloads initiated from non-secure contexts at the moment, because users at least see the "Not Secure" omnibox badge on those pages.
Clever. This means users won't be able to easily download software from websites not plugged into CA tree. One more step towards eradicating the ability of people to independently host websites altogether.
Increasingly, I see that the web no longer fulfills any of its original goals. On the other hand, if I look at it as a software delivery/execution platform I see a horrible mess that could have been designed a zillion times better if that was the goal to begin with.
Couldn't you add additional certificate authorities to your browser at will?
The CA system is decentralized by nature. If the existing authorities start trying to manipulate your internet by controlling who they verify, which hasn't really happened that I'm aware of, you can always add a new root certificate. Or consumer browsers can offer new CA roots out of box.
The point isn't what you can do as a user. The point is that Google adds more and more hurdles to running a website without plugging into the CA chain.
CA chain is centralized. Plus, it requires you to have a domain name. DNS is also centralized (although to a somewhat lesser extent).
Effectively, we're seeing yet another step in hyper-centralization of the web.
How many websites do you actually use don't have a domain name?
also, as above, there is no one root CA. you can add and remove any ca from your system. most users don't because why would you trust a random ca from some random site.
That's not how I read it. The nonsecure download from a secure page is their starting point. The end goal is to block all unsecure downloads of high risk types.
Locally-installed root CAs are allowed by HSTS, so if you added the HTTPS proxy to the root store, this would work without warning, unless you manually checked the certificate.
Of course, this only works on machines you're the admin of, which is why it's allowed.
So what happens if a hacker hacks company A and uses their server as a jump box to hack company B? Is company B allowed to hack A since their machine was used in an attack?
Or even worse, what if company B is mistaken as to who attacked them? If they "hack back" as advocated, but against the wrong target, are they liable?
Seems like quite a likely outcome to me also, I imagine most serious attackers understand the concept of covering their tracks and aren't exactly going to be sending packets straight from their home computer without protection.
Just take a look on any of the numerous cybercrime forums at any one time there are hundreds of "VPS"s available for rent which are are just compromised PCs of innocent folk.
> log in with some criteria more than just a username/password
The problem there is that captive portals don't add any extra link-layer security. The network is open, so literally anyone can sniff packets.
It's uncommon, but a network using WPA2-Enterprise and user/pass uses different keys for each person (not sure if per device or per user), so you don't have to trust everyone in the room.
Now you don’t have to trust the other customers, only the bar you’re at, their ISP and a million other parties between you and the site you’re visiting.
That's a reasonable point, but I'm speaking from the perspective of the bar owner - I feel I have a duty to provide better security even if the patrons have no reason to trust me.
Like a bar is going to run account administration.. at most they’re going to set a proper password with WPA2-PSK which provides protection against outsiders. But it can’t provide protection against an active attacker that has the password.
Using WPA-Enterprise, as I understand it, requires devices to be preconfigured to authenticate with the radius server, which makes it a non-starter for the kinds of networks that use a captive portal.
No, there's no preconfiguration needed, it's just a username/password account. You choose the network, then the OS asks you for your user/pass, then you're connected.
It's the router that connects to the RADIUS server, not the device directly. And some routers have one embedded, so you don't even need to configure that, it "just works".
Wouldn't it be nice if there was an encryption mode for Wifi that ensures integrity without requiring authentication? At CCC events, the workaround is to have a WPA2-Enterprise network that accepts every username/password combination, but that's going to be hard to explain to non-technical users.
I took a differential equations class last semester, where the easy part of quite a few problems was to solve a quadratic equation. And it was easy, because my algebra classes had correctly required me to practice that skill (and memorize the quadratic formula).
So, you say, I'm never going to take differential equations. And you very well might not. I have two responses to that:
1) That's true, you might not, but the guy sitting next to you will, and he doesn't even know it yet. If you were allowed to opt out of that subject, you both would, and he wouldn't even have a chance to make up for it later.
2) There are plenty of other subjects where the easy part is an algebra concept, and it's only easy because you practiced it years before.
You can do something similar with bash. If you set PROMPT_COMMAND='history -a', it'll append to the history file right after the command completes (because the prompt command is run as the prompt is printed).
Disassembly is a much easier task than decompilation, since it's a mostly mechanical process. Decompilation requires you to undo the optimizations/transformations the compiler did as it generated the binary, which is much harder.
That said radare2 is still cool, and a GUI (Cutter) is in the works.
I don't know about working as well as it does in VirtualBox, but with the QXL guest driver to do screen resizing and clipboard sharing, it's not too bad.
Relevant quotes:
> ... we will likely start by treating certain high-risk downloads initiated from secure contexts as active mixed content and block them.
> We're not planning to focus on non-secure downloads initiated from non-secure contexts at the moment, because users at least see the "Not Secure" omnibox badge on those pages.