1369162 - New Sentry projects for Screenshots

Status: RESOLVED FIXED

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Ian Bicking (:ianbicking)]

I'd like to create 3 new Sentry projects for Screenshots:

1. screenshots-addon-prod
2. screenshots-addon-stage
3. screenshots-addon-dev

Additionally, to get the add-on to submit to Sentry I have to provide it with the Private DSN (with authentication key), because requests from the add-on do not have any Referer or Origin header.  This means Firefox will ship with the Private DSN, and the Private DSN will be included in the Firefox source tree.

From what I read on https://docs.sentry.io/clients/javascript/config/ (under allowSecretKey) and my own experimentation, this appears the only way to handle this.  So the ticket also is to discuss the distribution of the Private DSN.

Comment 1

[Ian Bicking (:ianbicking)]

I found a change to Sentry that I thought was applicable: https://github.com/getsentry/sentry/commit/9e5ecfe87f4ebd35b155f729d0f9ebb3b671fa15

If the allowed origins are exactly "*", then there's no origin check.  But when I actually try that (I modified pageshot-prod, though in retrospect I should have used pageshot-dev) it didn't work and I still get a 403 from the client with an error "Missing required attribute in authentication header: sentry_secret"

Comment 2

[Greg G]

Assuming we're not sending errors to the 3rd party hosted Sentry, this should be OK. It is the recommended way to use Sentry with native apps and binaries.

> There's not inherently anything more secure with the private key vs public key. Public key leverages Referer/Origin for auth, and secret key doesn't is pretty much it.

https://github.com/getsentry/sentry/issues/4353#issuecomment-253640086


I think it'd be worthwhile to know how to respond to potential abuse.

wei: How hard is it to deal with fraud on our sentry instance? Can we autoscale ingestion and block IPs?

ianb: How hard will it be to rotate a shipped DSN string? 


Also, how are errors handled from a privacy standpoint? Do we only report errors for users that opted in to sending other crash and perf data? If they haven't opted-in do we prompt them to send each specific error?

Comment 3

[Greg G]

wei also pointed out https://forum.sentry.io/t/sentry-public-dsn-using-raven-java-client/150/4 too and mentioned rate limiting the errors we receive from the screenshot sentry projects which I'm +1 on too.

Comment 4

[Ian Bicking (:ianbicking)]

> How hard will it be to rotate a shipped DSN string?

The Sentry DSN is hardcoded in the add-on.  We used to keep it on the server and update it there, but it meant we couldn't report errors until a successful server interaction happened.  So we can change the DSN with a release, but we have to support overlap, and I don't know if Sentry supports multiple active secrets.

> Also, how are errors handled from a privacy standpoint? Do we only report errors for users that opted in to sending other crash and perf data? If they haven't opted-in do we prompt them to send each specific error?

It's described here: https://github.com/mozilla-services/screenshots/blob/master/docs/METRICS.md#error-reporting-data

We've taken the error reporting through data/privacy review.

Comment 5

[Greg G]

Cool, I'm OK with distributing the full DSNs since they only allow someone to submit fake reports and worst case we can drop all incoming error reports.

I think wei can generate those projects.

Comment 6

[Ian Bicking (:ianbicking)]

I'm also +1 on rate limiting the projects

Comment 7

[Ian Bicking (:ianbicking)]

Reopening, as the Sentry projects still have to be created

Comment 8

[:wezhou]

Hi Ian,

I see that you're one of the admins for the Pageshot team, which means you should be able to create new projects under that team.

Please try it and see how it works.

Thanks!

Comment 9

[Ian Bicking (:ianbicking)]

Yes, I'm able to create them.