Live data from Hacker News

Let's build a Chrome extension that steals as much data as possible

mattfrisbie.substack.com

111–120 of 320 posts

Re: Let's build a Chrome extension that steals as much data as possible

#111
post #4

And this is why I am hesitant to install any and all Chrome extensions. Well done!

At the office we maintain a policy which restricts any extension installs but ones explicitly vetted by IT. I would go so far as to suggest any company that doesn't do this is negligently irresponsible with computer security at this point.

Re: Let's build a Chrome extension that steals as much data as possible

#112
Look, I hate MV3 as much as the next guy. I've even wasted part of my life porting a large extension to it, so I might hate it MORE than the next guy. But I don't draw any security conclusions from this article.

For every permission in your manifest you need to provide the chrome web store reviewer with a written justification for why your extension needs that permission. Even the ones that don't prompt the user. And they definitely read it, and your code.

Shipping malicious extensions is almost entirely a social engineering problem and not a technical one.

Re: Let's build a Chrome extension that steals as much data as possible

#114

Earlier quoted context omitted.

> An egregious and nearly unbelievable oversight on Google's part. :-\ I agree it's egregious, but it's quite easy to believe. It's surely just using a standard modal and passing a string. The thing is, this is on a Mac that has scroll bars that are invisible until you scroll. It's easy to imagine testing was done other OS's where the scroll bars are obvious and the bottom line might be only partially hidden which ma…

> nearly unbelievable I don't get why people say something like this, especially on HN where lots of people are SDE themselves. Every single feature is hand-crafted by a/some real person(s), and is usually only reviewed by a handful people. It only makes sense sometimes it has serious oversight.

It's true. However, the orgs in question have billions of money. They can afford more than a handful of people to address these things.

Eight person startup? Sure. But not these folk who "only hire the best"

Re: Let's build a Chrome extension that steals as much data as possible

#115
post #68

Earlier quoted context omitted.

>this is on a Mac that has scroll bars that are invisible until you scroll. What modern UI even has visible scroll bars by default? And assuming it's even visible (either by default or user-configured after the fact if that's even possible), what modern UI even has scroll bars wider than 1px?

> What modern UI even has visible scroll bars by default? Pretty much all of them except Mac. Can speak personally for KDE, Sway, GNOME, and Windows 10. And when they are invisible, they usually show up on mouse motion/window interaction, so it's still not as egregious.

Xfce4.18 (GTK) has them. Has for 15+ years.

Shout out to Xfce for being so boring/consistent for more than a decade.

Re: Let's build a Chrome extension that steals as much data as possible

#116
post #51

Earlier quoted context omitted.

The naivety of innocence is rather blissful, isn't it?

Care to provide an example of an ios app which can read the data from other apps when they shouldn't?

I don't think it goes that far but a while ago the Twitter app was somehow polling for registered request handlers and discovering what other apps were installed. Not their data, but their presence, to profile their own users.

Re: Let's build a Chrome extension that steals as much data as possible

#117
post #10
post #3

This is an excellent accidental rebuttal to the entire Manifest v3 project. The stated reason for the new major version and breaking changes is officially: > Manifest V3 represents one of the most significant shifts in the extensions platform since it launched a decade ago. Manifest V3 extensions enjoy enhancements in security, privacy, and performance... https://developer.chrome.com/docs/extensions/mv3/intro/ Web de…

It's good that it doesn't pretend to be a rebuttal, because it'd be a bad one. I'm pretty sure the point of making a declarative content blocking API for adblockers is not to block all possible ways of writing a malware extension. It is just to make the most popular category of extensions safe by design. Once that has been done, it's then much easier to improve the situation with the remaining niche use cases. What w…

The ad blockers this affects are popular because they do more than declarative black lists. It may make them safe by design, but it also makes them something completely different and less capable than what they are today. There's some room to be suspicious about that.

Re: Let's build a Chrome extension that steals as much data as possible

#118

Earlier quoted context omitted.

> nearly unbelievable I don't get why people say something like this, especially on HN where lots of people are SDE themselves. Every single feature is hand-crafted by a/some real person(s), and is usually only reviewed by a handful people. It only makes sense sometimes it has serious oversight.

It's true. However, the orgs in question have billions of money. They can afford more than a handful of people to address these things. Eight person startup? Sure. But not these folk who "only hire the best"

But the more people you hire, the more bugs there are to address!

Re: Let's build a Chrome extension that steals as much data as possible

#119

Earlier quoted context omitted.

This introduces an especially silly attack vector: if you expect that asking for a specific permission might alarm users, and if you can push it below the fold, just ask for more innocuous or plausible permissions than you need! Besides the oversight of hiding some permission requests, this highlights that the order they’re presented matters too. Even if it weren’t scrollable with ~invisible indication of that, peopl…

In general, for the most part, it looks like the permissions shown higher in the list are the more dangerous ones. In particular, "read and change all your data on websites" is by far the most dangerous permission, and it always appears first or second. ("Access the page debugger backend", which is above it, sounds technical and opaque to most users, but the permission that it gates also triggers the "read and change…

There are several below the fold that I’d consider more dangerous than “show notifications”, but I suppose that one is enough of a nuisance to most people that it gets sorted up. Either way, having this kind of design is an opportunity for it to be gamed. Probably a better design would be more annoying over time (prompting for permissions as needed), but I’m the oddball who’d prefer that annoyance over this kind of approve-and-forget scheme.

Re: Let's build a Chrome extension that steals as much data as possible

#120
post #117
post #10

Earlier quoted context omitted.

It's good that it doesn't pretend to be a rebuttal, because it'd be a bad one. I'm pretty sure the point of making a declarative content blocking API for adblockers is not to block all possible ways of writing a malware extension. It is just to make the most popular category of extensions safe by design. Once that has been done, it's then much easier to improve the situation with the remaining niche use cases. What w…

The ad blockers this affects are popular because they do more than declarative black lists. It may make them safe by design, but it also makes them something completely different and less capable than what they are today. There's some room to be suspicious about that.

That's totally fair. Nobody except the people who proposed / approved the project know what the main motive was. It could be trying to hinder adblocking, could be security, it could be performance, or it could be that somebody just wanted to copy Apple.

If we as outsiders try to reason about that decision, it makes sense to pick the strongest version of those motives, not just strawmen. There's a good security argument to be made, and a silly security argument. If you pick the latter one to argue against, of course it will look like a bad excuse, leaving the more venal explanations as the only possibilities.

Post reply on HN