Hacker News new | ask | show | jobs
by awinter-py 1306 days ago
> All you need is to have the Single Emoji browser extension, which connects to your Slack workspace and enables you to use your favorite Emoji on your favorite tools, by making the smallest patches possible to how these tools work. Nothing too fancy, nothing too suspicious.

all you need is to connect random javascript to a major channel for social engineering and then run it inside major channel for software supply chain risk

4 comments

Back during the Yahoo and MSN chat days (remember Windows executables?), there were also "Download custom smiley packs" ads all over the Internet. I never tried them because they were probably malware. I have the same skepticism for this extension, or how easy extensions auto-updates can turn it into one.

Are the other responses in here non-ironic?

Hey there! I plan to open source this soon so the source will be available and you can read it. It is really doing nothing but adding the emoji to GitHub.

But I understand that the shadiest people say they are legit, so I’ll prioritize open sourcing the extension so others can review it :) sounds good?

That is a nice thing to do, but I think people will still be hesitant because there is no way to know whether that code you open-sourced is actually what's in the Chrome Store, or that the Chrome Store listing won't change ownership in the future. (Chrome extensions auto-update, so it's easy to ship users code that does something "new and exciting", and when dealing with software supply chain risk, "new and exciting" is something many people don't want.)

I get that you just wanted to make something cool, and it is very cool, but people are also right to be paranoid here. Compare the value between having a certain tiny image in your PRs versus being able to check code into any organization's Git repo as a trusted engineer at that organization, and how much someone would pay you on the black market for either of those things.

Not to mention that even the data being requested and stored is also organizationally sensitivite if leaked. Everyone's got some problem customer emoji or frustration with their cloud provider in there, which maybe wouldn't look great externally.
FWIW, I suspect Telegram animated stickers (or whatever it's called these days) may be Turing-complete.
I don't think they are. TGS is basically a subset of Lottie, which looks too simple to be able to do arbitrary computations: https://github.com/lottie-animation-community/docs/blob/main...
But it gives you custom emoji!
I mean, you’re not wrong, but I’d bet the Venn diagram of…

- people who use both a Web Extensions-supporting browser and Slack

- people who install extensions with permissions to run arbitrary JS on every page

- people who install or use Slack bots/etc with excessive access to Slack data

… is likely very nearly a circle. The emoji use case isn’t one for which I’d personally take that combination of risks. But I can imagine a wide variety of more appealing/risk worthy and likely even higher risk “use [CLOUD_SERVICE_FOO_RESOURCES] seamlessly in GitHub” use cases where I’d pause to at least consider it.

> - people who use both a Web Extensions-supporting browser and Slack

This is just basically everyone using Slack, as Firefox, Chrome, and Safari support web extensions API

> - people who install extensions with permissions to run arbitrary JS on every page

I would bet that most people who use Chrome or Firefox install extensions that can run arbitrary JS on every page, like ad blockers, full page screenshot, or “nifty” discount-coupon-code extensions.

> This is just basically everyone using Slack, as Firefox, Chrome, and Safari support web extensions API

~Basically my point. I made allowances for people who use neither, but they’re a vanishingly small user share.

> I would bet that most people who use Chrome or Firefox install extensions that can run arbitrary JS on every page, like ad blockers, full page screenshot, or “nifty” discount-coupon-code extensions.

Pretty much my point. Along with the former point, the Venn diagram is roughly all Slack users.

yes -- browser permission model needs to be much more granular

would be great if something like ublock is only able to disable dom elements, not insert them, for example, and has strong guarantees about not doing IO

users are much more able to audit permissions than to audit changing code

but permissions need to be 'shaped like' APIs or else they are too broad to provide power + safety together

It should start with access permissions being limited to user-specified (even if prefilled) list of sites/domains. There are extensions clearly meant for a single page (e.g. improving the UX), or a class of pages. I never install them, because even if those pages are not critical, the permission request is always scoped to "all data, every site", which means that e.g. this nice plugin decluttering YouTube could also exfil data from my bank's webapp.
pretty sure chrome provides this? or at least whatever build of chromium I am on, at least for local-unbundled extensions
Millions of developers run random javascript on their computers on a daily basis. It's called npm. How is this any less trustworthy?
It isn't, but those millions of developers are why software supply chain security is a topic now (and why it causes me no ends of headaches, even though I do C++!).