Federal employees have smart cards that include email encryption keys and certificates signed off the Federal PKI.

The problem is that SMIME is still hard to use. Thereâ(TM)s no place you can go to look up someoneâ(TM)s encryption certificate. It might be in Active Directory, but that only works within an agency. Plus, SMIME doesnâ(TM)t work with webmail, which is pretty common. And, you canâ(TM)t usually load your encryption private keys on a phone.

For what it's worth, I do agree with the change and more generally think that Google should be doing more about malicious/spyware extensions using powerful APIs. Some of that is policing their web store more, and some of that is pulling back on the more powerful APIs that have big security/privacy implications. WebRequest API is a great example of something that was simply too powerful and they should have known it would be abused.

Now, I say I support the change, but that's because I believe them when they say they're going to make declarativeNetRequest more useful. They already make some big changes from the original public version to this version. Doubling/tripling the limits is probably a 90% solution, but I hope they'll continue to listen to feedback from the extension developers to address other needs.

I also mostly trust Google to not abuse the restrictions they're placing on the API by, say, ignoring attempts to block Google ads. That sounds like anticompetitive behavior, and seems like a lawsuit waiting to happen.

Plus, if Google limits this too much, I'll just jump to a different browser for myself.

100 is how many URLs an extension can *whitelist* (which is why its called the max number of allowed pages).

The real limits are 30,000 static rules and 5,000 dynamic rules. Yes, both are too low, and Google has indicated that they'll raise them to yet-to-be-specified numbers. Don't kid yourself, though: 50,000 rules like the limit under Safari still works pretty well. Most of the rules in ad blocking lists are never used.

Considering those extensions are strictly less privileged than the Chrome engine, that's a strange position to take. You might trust them more, but whether you like it or not, if you're using Chrome, you're trusting the engine.

It's not a static list. You can update the dynamic rules, and updates to the extension can update the static rules.

And while you don't have full regular expression matching, you can match with wildcards. That should be sufficient in a lot of cases.

There are some stricter restrictions on how much you can modify requests under the declarativeNetRequest API. To be honest, I don't really understand how they're different than webRequest, that at first glance it sounds like it might be more problematic for some advanced content blocking cases.

The basic objections I've seen stem from two areas:
1) Currently, declarativeNetRequest has some pretty slow limits for how many rules an extension can add. It's currently at 30,000 static rules, and 5,000 dynamic rules. That's too low. How many are needed is a matter of debate. I've seen references to EasyList having about 75,000 rules, but studies have shown most of those don't get used. (and, before someone jumps on this, I'll add some lists have many more than 75,000 rules, but I strongly suspect most of those also aren't used). I don't know what the right number is. Safari imposes a 50,000 limit for their content blocker API, yet it still works pretty well. 30k/5k is too low, though, but Google is claiming that they're increase it to some unspecified number.

2) Matching Rules are limited: The rules that you can create are limited by the API. It's more complicated than this, but it's mostly URL matching with wildcards. Previously you could implement your own logic in Javascript, which meant you could create whatever complicated rules logic you could dream up. This will almost certainly break some things irrevocably. It's not clear to me whether it will break big things, or little-used things. It shouldn't be that big of a deal for ad-blocking, but as others have mentioned, you can do a lot more than ad-blocking with uBlock. Some of its power would go away with declarativeNetRequest.

The same thing that prevents them from having the current webRequest API ignore requests to block Google ads: backlash from users, engine customers, and governments.

I do agree that it seems like it would be a little more convenient architecturally to impose no-blocking rules under the new API. But I don't think its noticeably harder to do equivalently bad behavior under the old one.

You can read the following paper for some examples of the nasty things a malicious extension can do with the webRequest API:
Hulk: Eliciting Malicious Behaviorin Browser Extensions
https://www.usenix.org/system/...

webRequest API isn't just limited to viewing or blocking network requests; it can modify them as well.

Alternatively, it also sounds like you're interpreting the OP as claiming that the new declarativeNetRequest API would only be available to enterprise users. That's not the case. Blocking with the old webRequest API would only be available to enterprise users, but the new declarativeNetRequest API would be available to all.

I don't understand your statement here. I think you're assuming the declarativeNetRequest API would only be used by adblockers, so Google could more easily make changes (e.g., greater restrictions) down the line without fear of breaking other extensions. That's simply not true. The declarativeNetRequest API would completely replace the webRequest API as the method to block or modify requested URLs by all extensions that need that functionality.

No. Sorry, I must have explained that poorly. The ad blocking logic in extensions is implemented in javascript. That gives extension developers incredible control over what rules they create; they're limited by only whatever they can practically do within javascript.

The new declarativeNetRequest API moves the ad blocking logic into the browser engine itself. Extensions feed it glorified lists of things to block.

It's not that easy. HTTPS/TLS mean you can't simply modify requests/responses on-the-fly; at least, not without running a man-in-the-middle attack against yourself. We could argue about how bad that really is, since you can try to convince yourself that you trust your MitM software, but I wouldn't trust it to stay current.

To get around this problem, I think most Android ad blockers basically just do DNS-based blocking. That's fine, although DNS-based blocking is more error-prone. More significantly, though, it relies on DNS being an insecure protocol. If browsers start using their own DNS over HTTPS resolvers, you won't be able to do this sort of thing since (like the MitM proxy case described above), it's largely indistinguishable from an attack from the browser's perspective.

I'm not saying there isn't cause for concern, but the summary is misleading. Google isn't proposing a change that would kill ad blockers. They're removing the API used by current ad blockers, and replacing it with a different API that is less powerful. While that might sound troubling, you have to understand that the current webRequest API is incredibly powerful. While that's great for the "good guys" that want to do cool, useful stuff with it, it's also incredibly powerful for the "bad guys" creating malicious/spyware extensions.

The changes they described to the declarativeNetRequest API would support ad blockers, particularly as they reduce some limitations they've placed on them- which they're claiming they're going to do once they do some more research on what the right limits they should be.

What's the difference between the webRequest API and declarativeNetRequest API? Basically, webRequest API sends the URLs you're accessing to an extension to let javascript run whatever rules it wants to on it to decide what it will or won't block. So again, that's quite powerful. The declarativeNetRequest API would basically make the extension provide a formatted list of URLs to block/modify to the browser. In this case, the browser itself is processing the rules handed to it, rather than letting javascript in the extension handle that.

First, keep in mind the WiFi Alliance isn't developing standards. The standards are developed in IEEE 802.11. The WiFi Alliance is basically creating a profile of the 802.11 standards that they'll cover as part of their certification program. Dragonfly is used because that's what's specified in 802.11.

Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.

Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.

Honestly, I'm no expert in PAKEs, but a lot of them are built on Diffie-Hellman where this sort of check has been long known as needed depending on the group you're working in and whether its a static or ephemeral exchange. It seems disingenuous to call that a "flaw."

Some of the skepticism surrounding Dragonfly in practice seems to be more related to concerns with how the security review went down in the CFRG, and some connections to the NSA, than with the protocol itself. I understand there are other PAKEs that seem to have better security properties, like J-PAKE, but they all have other problems (JPAKE, for example, is rather slow). It's mostly a non-issue for the WiFi Alliance, as they have to work within what's supported in the IEEE specs (which basically means sticking with PSK or using Dragonfly), but I don't know why IEEE chose what they did.

I think you're greatly exaggerating the problems. If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away. Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.