6 ms·

A few years back, one of our (Twilio SendGrid's) developer evangelists created an open source Chrome extension to show the icon of the ESP who sent a message in

A few years back, one of our (Twilio SendGrid's) developer evangelists created an open source Chrome extension to show the icon of the ESP who sent a message in Gmail. The last big Gmail UI update broke it, but most of the ESP identification strategies probably still work: https://github.com/nquinlan/Email-Intelligence/blob/master/content.js https://github.com/nquinlan/Email-Intelligence/blob/master/c...

kehers 7y ago
This is nice. Shows a different approach to getting the ESP from the mail header.
pingec 7y ago
This is a brilliant idea, if only it were updated for the latest gmail UI
- mbrameld 7y ago
  https://www.inboxsdk.com/ https://www.inboxsdk.com/ lets you pretty easily manipulate the Gmail UI if you want to have a crack at it.
  - alooPotato 7y ago
    We (Streak) made the InboxSDK. Great for projects like this because we autoupdate so you can write the extension against our high level api and not have to worry about gmail changes going forward. Let me know if we can help.
- nquinlan 7y ago
  Chrome extension author here: make a PR and I'll accept it and publish it.
paulmendoza 7y ago
OMG, this sounds like a massive security risk. That nice developer could easily siphon off all the email to his backend server with this little extension. I install almost no extensions because they are too risky.
- fiddlerwoaroof 7y ago
  Chrome sandboxes fetch requests from extensions and tells the user what permissions the app is requesting, so it’s not actually that bad (barring bugs in the sandbox)
  - jannes 7y ago
    What do you mean with "sandboxes fetch requests"? That's not a valid countermeasure at all... The grandparent was worried about the extension stealing his email's contents.
    - iudqnolq 7y ago
      Absolutely. If the extension injects JavaScript into the page to examine the email it can run a fetch in the context of that page. I think the app store should warn that a page can send data to any website if it has permission to modify any page.
      - fiddlerwoaroof 7y ago
        It’s been a while, but I’m pretty sure the permissions dialog explicitly calls this out.
- runlevel1 7y ago
  All Chrome extensions require trust. That should factor into your decision to install any of them. This is no more risky than any other extension whose permissions include `https://mail.google.com/` https://mail.google.com/`. Anecdotally, that probably includes most extensions seeing as how most of the ones I come across request `<all_urls>` whether or not they need it (not that that's okay). In any case it's open source, so you can download it, audit the code, and install it locally to prevent auto-updating.
  - throwanem 7y ago
    Or use an email client that runs outside your browser, and reduce your threat surface considerably - yes, you still have to worry about other things you do in the browser, but compromising your email compromises all those too via password resets, which isn't the case for anything else if your password discipline is good. Yes, Gmail makes it harder than it should be to use the email client of your choice. But that's not a problem with email clients. That's a problem with Gmail. It's far from the only one.

kehers 7y ago

This is nice. Shows a different approach to getting the ESP from the mail header.

pingec 7y ago

This is a brilliant idea, if only it were updated for the latest gmail UI

mbrameld 7y ago
https://www.inboxsdk.com/ https://www.inboxsdk.com/ lets you pretty easily manipulate the Gmail UI if you want to have a crack at it.
- alooPotato 7y ago
  We (Streak) made the InboxSDK. Great for projects like this because we autoupdate so you can write the extension against our high level api and not have to worry about gmail changes going forward. Let me know if we can help.
nquinlan 7y ago
Chrome extension author here: make a PR and I'll accept it and publish it.

paulmendoza 7y ago

OMG, this sounds like a massive security risk. That nice developer could easily siphon off all the email to his backend server with this little extension. I install almost no extensions because they are too risky.

fiddlerwoaroof 7y ago
Chrome sandboxes fetch requests from extensions and tells the user what permissions the app is requesting, so it’s not actually that bad (barring bugs in the sandbox)
- jannes 7y ago
  What do you mean with "sandboxes fetch requests"? That's not a valid countermeasure at all... The grandparent was worried about the extension stealing his email's contents.
  - iudqnolq 7y ago
    Absolutely. If the extension injects JavaScript into the page to examine the email it can run a fetch in the context of that page. I think the app store should warn that a page can send data to any website if it has permission to modify any page.
    - fiddlerwoaroof 7y ago
      It’s been a while, but I’m pretty sure the permissions dialog explicitly calls this out.
runlevel1 7y ago
All Chrome extensions require trust. That should factor into your decision to install any of them. This is no more risky than any other extension whose permissions include `https://mail.google.com/` https://mail.google.com/`. Anecdotally, that probably includes most extensions seeing as how most of the ones I come across request `<all_urls>` whether or not they need it (not that that's okay). In any case it's open source, so you can download it, audit the code, and install it locally to prevent auto-updating.
- throwanem 7y ago
  Or use an email client that runs outside your browser, and reduce your threat surface considerably - yes, you still have to worry about other things you do in the browser, but compromising your email compromises all those too via password resets, which isn't the case for anything else if your password discipline is good. Yes, Gmail makes it harder than it should be to use the email client of your choice. But that's not a problem with email clients. That's a problem with Gmail. It's far from the only one.