I'm no expert on Google OAuth, so this could be wrong, but my understanding is that this is totally fine.
The client secret is, despite its name, not necessarily intended to be secret. Client ID / secret pairs can be locked down to only work with specific referer headers or Application IDs. Also, they are only useful for purposes of quota and don't provide authentication. A malicious entity could make calls against the quota of this app (which is true for any app), but they couldn't easily distribute the key or use it for other purposes very well.
Yeah I debated this quite a lot and came to the conclusion that it was ok to include. I put a comment in the source where I describe my understanding of the threat model (though not sure if it makes it to the bundled extension?) Here it is for reference:
// I know this shouldn't be here but I've concluded based on a fair amount of
// research that it is *impossible* to make a chrome extension that:
// 1. Allows you to use accounts besides the default browser account
// 2. Doesn't prompt for token/account renewal every hour
// 3. Doesn't have any server-side code.
// without including it here.
// I figured I could obfuscate it, but no matter what it's going to be readily available
// in the network tab anyways so I decided not to bother.
// Here is some information about the threat model this exposes:
// https://tools.ietf.org/html/rfc6819#section-4.1.1
// In summary, the most dangerous thing is that people can use the renewal token
// to get more access tokens to access your photos, if you've already approved this
// and they get access to those things.
// You can always revoke access via google at any time.
If it seemed worth it I could set up a server side proxy to keep the secret a secret at which point I could revoke the existing secret (which would break everyone's installed apps but whatever). However it didn't seem necessary based on my read and definitely not until I had validated that anyone wanted to use it.
Which can only be accessed by an installed Chrome Extension with that ID. So no one should be able to authorize anything besides this app using that information.
The client secret is, despite its name, not necessarily intended to be secret. Client ID / secret pairs can be locked down to only work with specific referer headers or Application IDs. Also, they are only useful for purposes of quota and don't provide authentication. A malicious entity could make calls against the quota of this app (which is true for any app), but they couldn't easily distribute the key or use it for other purposes very well.