1. With the new system, would uBlock Origin work as well as it does now? 2. What are the concrete security problems that v3 attempts to address? 3. What is the threat model that the designs are being evaluated against?
-
-
Replying to @BRIAN_____
1.) Depends on where the (evolving) design lands, but I want to say "probably" because I trust the team is listening 2.) Too many extensions can log too much of what you do 3.) Experience
1 reply 0 retweets 1 like -
Replying to @slightlylate @BRIAN_____
And I understand that #3 sounds glib, but it's how Chrome Extensions initially came to be different from Firefox (and BHO/ActiveX-baesd) extensions and how most systems iterate. We're not predicatively more clever than all possible folks preying on users.
2 replies 0 retweets 3 likes -
Replying to @slightlylate @BRIAN_____
I think it's that experience revealed there were certain threats that needed to be included in the threat model. I'm not on the team, but I think an example is, "extension pretends to be an ad blocker, but actually sells your browsing history."
3 replies 0 retweets 2 likes -
Replying to @jyasskin @slightlylate
I think there are alternative ways of addressing that risk that don't handicap good extensions. For example, in the JS context (worker, whatever) in the extension that has more access to view/change requests/responses, limit API surface area to block storage, networking, etc.
2 replies 0 retweets 1 like -
Replying to @BRIAN_____ @jyasskin
These are APIs that *do networking*. Do you have a concrete proposal?
1 reply 0 retweets 0 likes -
-
Replying to @BRIAN_____ @jyasskin
True! At the same time, the offered suggestion is facially unworkable. I'm asking for a detailed set of suggestions because that's how we improve APIs; and I want to stress, we're *absolutely listening* and I'm happy to advocate for anything good to the team.
2 replies 0 retweets 1 like -
Replying to @slightlylate @jyasskin
FWIW, regarding whether the suggestion is unworkable, I think it would take a lot of effort to determine, after the details are fleshed out, whether it would work. I think you saying "facially unworkable" demonstrates the closed-mindedness that is fueling the PR disaster.
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @jyasskin
Sorry, your suggestion was "limit networking" in a turning-complete environment (workers) about an API that *does networking*. We can limit networking in, e.g., Animation Worklets and some other contexts (and do!) because they don't accept or affect networking at all.
1 reply 0 retweets 1 like
One can imagine a worklet style solution where some small amount of code is run with a narrow API -- I've suggested a "loading worklet" for documents -- but the constraints look substantially like what's proposed thus far (assuming proposed extensions like redirects)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.