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

201–210 of 320 posts

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

#201

Post by withinboredom »

dcow wrote: post #59
ClumsyPilot wrote: post #31

Earlier quoted context omitted.

> uBlock Origin and other ad blockers Router based adblockers work well, Flint by GL.net comes with nice UI and adhlock and VPN built in. Some people complain about its chinese origin but at least I know only 1 government is spying on me - my provider supplies a router with a linux kernel older than this house. There could be an entire ensemble of Trojans partying there

Not with encrypted DNS (DoH and DoT).

Your router can proxy encrypted DNS (if you have some decent firmware) or you can set up your own DNS server. There are also things like nextdns.io which can do all the work that a pihole does but works outside your home network.

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

#202

Post by panda888888 »

dcow wrote: post #45

This is a spicy essay for sure but what is the author's actual point? If the user grants you permission to do all these things, then you have permission to do all these things. If you can't be trusted and abuse that permission then you are not ethical. If you aren't ethical someone will find out and your extension will be removed in the worst case and simply not approved in the common case. The author even admits as…

It's very early for users to not understand and for apps to ask for a bunch of permissions. One great example is Grammarly, which is a keylogger that helps users with grammar. I don't think Grammarly has bad intentions, but still, millions of users are giving it access to everything they type.

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

#203

Post by jsnell »

dmitriid wrote: post #156
metadat wrote: post #148

Earlier quoted context omitted.

Privacy is bundled under Trust & Security. I don't have precise numbers or estimates, but basically every Google product area has a team of Technical Privacy Engineers, TPMs, TPgMs, and VPs. They are the arbiters who can block a production release if privacy and security issues are discovered and not remedied. No other company I can think of has invested in such a rigorous Privacy review and support structure in an a…

> No other company I can think of has invested in such a rigorous Privacy review and support structure in an attempt to reduce risk. 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. 80-90% of Google's revenue comes from online ads. There's a huge conflict of interest between Go…

> 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?

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

#204

Post by froggit »

bigfudge wrote: post #180
kibwen wrote: post #89

Earlier quoted context omitted.

> I would hope somebody sees this now and prioritzes a Chromium bug for it. Rather, one would hope that Apple sees it realizes that their short-sighted, bone-headed, pea-brained idea to eliminate scroll bars should be rolled back. Of course, I'm not holding my breath. Yet another example of their crusade to prioritize form over function, exemplifying why I find their products to be infuriating to deal with.

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?

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

#205

Post by crashmat »

ClumsyPilot wrote: post #71
Sebb767 wrote: post #39

Earlier quoted context omitted.

Well, you can get a full refund. I see where you are coming from, but increasing liability for free software does not feel like a good idea to me at all. There's basically no way you could extract money protected by Googles lawyers army, but any small open-source project or even medium sized company will be extremely vary of releasing anything. I'm not saying you should never go there - GDPR does and it's a net impro…

> Well, you can get a full refund Suppose developers of smart locks make an error, and all smartslock unlock on Fridays. When users ask the Company, they lie and claim their locks are flawless and users are to blame. Millions of houses are robbed, people loose their life possesions, and home robbers kill some grandma. Should the Grandma's family get just a $100 refund (price of the lock)? > There's basically no way y…

[flagged]

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

#206

Post by froggit »

odysseus wrote: post #123
crazygringo wrote: post #50

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…

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.

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

#207

Post by aboodman »

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.

Sure but it's still possible to install non-sandboxed software. What Chrome would need is protection from _other_ software, not limits on itself.

It's true that as MacOS continues to discourage non-sandboxed software, Chrome can make sideloading more cumbersome to match.

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

#208

Post by dmitriid »

jsnell wrote: post #203
dmitriid wrote: post #156

Earlier quoted context omitted.

> No other company I can think of has invested in such a rigorous Privacy review and support structure in an attempt to reduce risk. 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. 80-90% of Google's revenue comes from online ads. There's a huge conflict of interest between Go…

> 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 trail by setting their home and work addresses as some other random locations.

Jen Chai, a Google senior product manager in charge of location services, didn't know how the company's complex web of privacy settings interacted with each other, according to the documents.

--- end quote ---

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

#210

Post by pcthrowaway »

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…

> 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 repo (without an additional build/compile step - the repo should reflect the exact code being shipped in the extension). This way prospective users can inspect the code of an extension without installing the extension first and mucking about in dev tools.

> Ability to fix and deploy bugs is important for extensions just like any other software.

Ability to fix bugs, sure. Ability to deploy bugs (without user consent or knowledge) is an antipattern ;P Third-party browser code should never be shipped to the user without their consent and full transparency into what is being shipped. Users who don't intend to inspect the updates can opt-in to automatic updates, sure.

> Obfuscated code is already disallowed

This is great! Though they distinguish between minification and obfuscation, which is bizarre. Intentionally obfuscated code is hard to detect. I was suggesting they also disallow any form of minification (or at least require extensions to distribute with minified and unminified options, and have minified bundles verified)

> It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png. This is a better level of observability than what you describe because once an extension has access to a page, there is no way to prevent it from exfiltrating data from that page. The communication with background page is not relevant. There are myriad ways to exfiltrate just given access to normal DOM, unfortunately.

This is true, but even background scripts which don't have access to the DOM can communicate with the content script through sendMessage.

A user looking at the network panel on the page might not see a network request sending their password to a strange server if the message is being sent to the background script and the request is being made from there. All communication in and out of the sandboxed extension environments should be logged and inspectable from any page where the extension contexts are being communicated with.

Post reply on HN