Hacker News new | past | comments | ask | show | jobs | submit login

Folks should know that this approach will not accommodate upcoming changes to Chrome extensions, which will disallow all remotely-hosted code: https://groups.google.com/a/chromium.org/d/msg/chromium-exte.... More up-to-date guide here https://developer.chrome.com/extensions/migrating_to_manifes..., with a timeline of 2020. I understand why

> one thing we wanted to prevent was developers including the stock SDK directly in the extension

(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.




Cross posting from another comment:

It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: