Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mattfrisbie.substack.com

Post reply on HN
Print view View original

211–220 of 320 posts

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

#211

Post by silvestrov »

aboodman wrote: post #196
pcthrowaway wrote: post #185

Earlier quoted context omitted.

Perhaps I'm missing something, or things have changed in the last couple of years, but when I last took a look there were a few main issues with the extension security model that would have been dead-simple to implement. My understanding at the time (I realize I could be mistaken about any of these): * Users have no idea what code they're installing. Extensions aren't required to be open source, where the community c…

> Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github. I love this idea fwiw. Browser vendors should totally do this. Requiring OSS seems like a fair tradeof…

Chrome need a "view source" equivalent for extensions.

If should be just as easy to inspect extensions as it is for web pages, including all the network requests they have made.

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

#212

Post by jackdh »

alooPotato wrote: post #22

Now try actually distributing it. My guess is this wouldn't even get close to getting through the review process for the Chrome Webstore. From our experience with Streak, this would def get picked up in review. Seeing other comments in the thread pointing to this article as a reason why MV3 is bad I think misses the point. Personally I think MV3 is a step in the right direction (even though it negatively affects us!)…

He mentions this in the article, the heading is "Publishing to the Chrome Web Store"

"This extension would be laughed out of the review queue."

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

#213

Post by eitland »

froggit wrote: post #204
bigfudge wrote: post #180

Earlier quoted context omitted.

Having less visual clutter -is- function to me. I really don’t miss permanent scroll bars and hope they don’t bring them back. Most Macs ship with a trackpad, which means I can’t remember when I last deliberately gripped a scroll bar. They are just a waste of space most of the time, even as an affordance/reminder that scrolling is possible.

Wouldn't it be cool if apple had some kind of menu called like "display settings" or something, and in that menu there was like a checkbox labeled "use invisible scrollbars", and when the checkbox was checked, scrollbars would be invisible, then when it was unchecked, and I know this'll sound crazy, the scollbars would be visible, and people could just make it look the way they like?

Exactly. So much is broken because of misunderstood UX design.

Today I was again reminded that many years ago some UX designer thought it would be a great idea to remove back/forward buttons from the context menu in Firefox if I accidentally select some text on a page I visit.

No one was asked and when someone filed a bug it was ignored because ux designers had already decided.

Result:

- a few times every month back/ forward buttons are missing

- the look and feel of the context menu changes for no good reason

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

#214

Post by pcthrowaway »

silvestrov wrote: post #211
aboodman wrote: post #196

Earlier quoted context omitted.

> Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github. I love this idea fwiw. Browser vendors should totally do this. Requiring OSS seems like a fair tradeof…

Chrome need a "view source" equivalent for extensions. If should be just as easy to inspect extensions as it is for web pages, including all the network requests they have made.

"view source" doesn't really even work for regular pages now, since the DOM is often very different from what is in the HTML page the user receives

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

#215

Post by jsnell »

dmitriid wrote: post #208
jsnell wrote: post #203

Earlier quoted context omitted.

> In recent court cases Google employees admitted they have no idea where user data is stored (specifically location data), which systems have access to it, and how to fully turn tracking off. Really? Do you happen to have a source for that?

https://www.theverge.com/2020/8/26/21403202/google-engineers... Edit: a better article https://www.businessinsider.com/unredacted-google-lawsuit-do... Short quote: --- start quote --- Jack Menzel, a former vice president overseeing Google Maps, admitted during a deposition that the only way Google wouldn't be able to figure out a user's home and work locations is if that person intentionally threw Google off the trai…

Thanks. But neither of those sources matches your initial description.

The first is not anyone "admitting" anything in a "court case". Nor does it discuss "where user data is stored" or "what systems have access to it". It is quotes from an email discussion on some article, about the behavior of a UI toggle, with no indication that these are people working on that system who would be expected to know where data is stored but don't.

In the second link you've at least got a deposition, but how is either of those paraphrases relevant to your claim about "not knowing where user data is stored" or "what systems have access to it"?

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

#216

Post by sanitycheck »

froggit wrote: post #206
odysseus wrote: post #123

Earlier quoted context omitted.

Fortunately, you can override Apple's choice: Settings > Appearance > Scroll bar behavior > Show scroll bars > Always If I were in charge of fixing this bug for Chromium, I might start by prioritizing which permissions are the most nefarious, list them first, perhaps in red. Then ensure the entire dialog expands vertically to fit as much content as possible.

Have users view and approve each permission individually. First permission is listed, buttons for "deny" and "approve", user clicks "approve", next permission is listed, etc. Clicking stuff is a lot of work for users and some of those permissions sound pretty intimidating, so I suspect either extensions would start getting by using fewer permissions or users would start getting by using fewer extensions.

Either of those outcomes would be a win for security and privacy.

Users _should_ understand what an extension having access to this stuff implies, and if that means they only use "official" extensions or stop using them that's fine.

Also "clicking stuff is a lot of work for users" made me laugh a little. How many damn cookie consent buttons do users have to click every day? An extension should be orders of magnitude more "work" to allow than that.

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

#217

Post by mafuy »

eitland wrote: post #213
froggit wrote: post #204

Earlier quoted context omitted.

Wouldn't it be cool if apple had some kind of menu called like "display settings" or something, and in that menu there was like a checkbox labeled "use invisible scrollbars", and when the checkbox was checked, scrollbars would be invisible, then when it was unchecked, and I know this'll sound crazy, the scollbars would be visible, and people could just make it look the way they like?

Exactly. So much is broken because of misunderstood UX design. Today I was again reminded that many years ago some UX designer thought it would be a great idea to remove back/forward buttons from the context menu in Firefox if I accidentally select some text on a page I visit. No one was asked and when someone filed a bug it was ignored because ux designers had already decided. Result: - a few times every month back/…

If I understand you correctly, then I asked for this. Text is often selected by accident, so the top item in the menu would go Back instead of Open in new tab, as that is in the same place in the context menu. The opposite of what I want, and infuriating to use.

https://superuser.com/questions/1074338/disable-back-in-chro...

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

#218

Post by iggldiggl »

yywwbbn wrote: post #198
aboodman wrote: post #181

Earlier quoted context omitted.

I guess it depends on what you mean by "difficult". Chrome is unfortunately limited here by the security of the OS. No popular desktop OSes have application isolation: all apps have the same permissions. Any app can write to any other apps' storage. This means that if Chrome makes sideloading too difficult, developers will just tell users to run their native code which will hack into Chrome, making even understanding…

macOS clearly has file system isolation though. Sandboxes apps can’t write/read anything outside without an explicit permission.

For some programs sandboxing can work perfectly fine, but for others it can result in anything between noticable UX degradation and a major PITA, because there are enough workflows out there that can't really be sensibly made to work with an "every file access must go through an official 'File open'/'File save' dialogue (or something comparable, like drag-and-drop, or launching a certain program with a certain file)" model.

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

#219

Post by wartijn_ »

interpol_p wrote: post #132
metadat wrote: post #9

> Chrome scrolls the permission warning message container, so more than half of the warning messages don’t even show up. I’d bet most users wouldn’t think twice about installing an extension that appears to ask for just 5 permissions. An egregious and nearly unbelievable oversight on Google's part. :-\ As a developer, it's unimaginable to me to not test the extreme high and low numbers of inputs cases to ensure thing…

Even if they were to somehow show everything up-front, it would be user hostile design. No one wants to read and consider every possible permission prior to granting it to the thing they want to use Even if there were 20 items in the list, people would hit "OK," it's like accepting terms and conditions. Most people won't read them, they're trained to hit "Agree" The whole model needs an overhaul. Extensions should be…

That would make the password manager plugin I use extremely annoying to use. I want that plugin to read every page I visit so it can detect username and password fields. The same goes for many other extensions, like ad blockers. They should block all ads they can find, without constantly needing to annoy users with permission prompts.

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

#220

Post by aboodman »

pcthrowaway wrote: post #210
aboodman wrote: post #196

Earlier quoted context omitted.

> Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github. I love this idea fwiw. Browser vendors should totally do this. Requiring OSS seems like a fair tradeof…

> Requiring OSS seems like a fair tradeoff for the power that extensions wield To be precise, I wasn't advocating requiring OSS, just source-availability. Extensions should have at a minimum a visible repository displaying the source code, where users and auditors can publicly comment or leave issues (ideally, which the maintainers can't remove). Chrome should verify that the extension code matches the code in the re…

Funny story, the original version of the web store had a button you could press to see the source of an extension.

> Ability to deploy bugs is an antipattern

Disagree then. One doesn't come without the other.

> even background scripts which don't have access to the DOM can communicate with the content script through sendMessage

If by "content script" you mean the web page script, then this is true, but in that case the web page is collaborating with the extension. Whatever the web page is sending to the extension it could just as easily send anywhere on the internet.

>

Post reply on HN