Why do sheets not use request signing?


Afternoon folks.

I’ve been playing with Sheets this afternoon, and the first thing which struck me is the use of an encrypted user payload, rather than a request signature like all the other flows.

It’s extra leg-work to decrypt and verify the user, especially when we already have a different mechanism for handling configuration/initialisation/canvases, which we now can’t reuse.

What’s the reasoning behind this? Are there specific benefits to doing it this way?

Look forward to learning more.




That’s something we can improve, so that you can verify if the sheet request was a legit one coming from Intercom.

The user would remain encrypted (security reasons), but that can be an optional step only in the case you’d need the user context .

1 Like


@hellojeanpierre sure thing, would certainly be nice to have continuity access all the flows. :smile:

What are the specific security concerns which mean the user has to be encrypted for sheet flows but not for the others?

I see why encrypting the user data might make sense (although it’s sent over Https anyway) - but if that’s the case why not apply that approach with all the flows?



I don’t know fully the details, but it has to do with sheet requests being the only ones sent by the browser.

It was a hard requirement from our security team so I doubt this will change :sweat_smile:

1 Like


Gotcha, that makes sense. :smile:

Security teams; the tax accountants of the engineering world. :joy: