Twitter | Search | |
Justin Schuh 😷 12 Jun 19
We have two new posts out today addressing the confusion and misinformation surrounding what Chrome is doing with extensions. This first one gives context on the broader security, privacy and abuse considerations we're addressing.
Reply Retweet Like
Justin Schuh 😷 12 Jun 19
Replying to @justinschuh
The second post is a deeper technical dive into the Web Request and Declarative Net Request APIs, explaining the advantages and tradeoffs of the new API versus the old one.
Reply Retweet Like
Justin Schuh 😷
I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like "42% of malicious extensions use the Web Request API" when you're considering what we're trying to improve here.
Reply Retweet Like More
Dan Fabulich 12 Jun 19
Replying to @justinschuh
May I ask you to address this thread on HN? Is it true that webRequest will remain available to extensions but only the "blocking capabilities" of webRequest will be restricted? (If so, how would that help with the malware problem?)
Reply Retweet Like
Justin Schuh 😷 12 Jun 19
Replying to @dfabu
Yes, but network requests won't be observable without permission on the relevant hosts. And host permissions are changing significantly in Mv3 (e.g. they can't be granted as blanket install time permissions).
Reply Retweet Like
Pelle Wessman 12 Jun 19
Replying to @justinschuh
The new API sounds similar to what Apple introduced to iOS to allow ad blocking there? My perception is that ad blockers for iOS have been quite popular and successful. To me it sounds like you're making a very sensible change πŸ‘
Reply Retweet Like
Thomas Claburn 12 Jun 19
Replying to @justinschuh
What percentage, if any, of those malicious extensions are content/ad blocking extensions?
Reply Retweet Like