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

Massive spying on users of Google's Chrome shows new security weakness

reuters.com

Post reply on HN
Print view View original

241–250 of 270 posts

Re: Massive spying on users of Google's Chrome shows new security weakness

#241

Post by livre »

driverdan wrote: post #226
matheusmoreira wrote: post #117

Earlier quoted context omitted.

The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables. Honestly, uBlock Origin and Privacy Badger are so important at this point they should just become part of the browser itself. They're already in a league of their own.

Also HTTPS Everywhere and, in Firefox, NoScript.

I stopped considering NoScript something I can trust when this happened[1]. Many years have passed, the Tor project trusts it but I'm still cautious.

[1] http://www.schillmania.com/content/entries/2009/adblock-vs-n...

Re: Massive spying on users of Google's Chrome shows new security weakness

#242

Post by pornel »

AznHisoka wrote: post #147
Thorrez wrote: post #122

Earlier quoted context omitted.

One thing extensions commonly do is modify the page. If an extension can modify the page, it can insert an which will cause a network request to happen. How do you plan to prevent this? Prevent extensions from modifying the page?

Same suggestion applies. Show users the warning that extensions can modify your page and have users explicitly approve of it.

And they already do that. The problem is, almost every extension has a legitimate need to read and/or modify the page, so people click through this permission warning like Vista's UAC.

Re: Massive spying on users of Google's Chrome shows new security weakness

#243

Post by kyboren »

yjftsjthsd-h wrote: post #237
willvarfar wrote: post #177

Earlier quoted context omitted.

Why I specified "fixed URLs", to close that loophole

My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo.

Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests.

If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key.

Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy.

[1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)

Re: Massive spying on users of Google's Chrome shows new security weakness

#244

Post by IncRnd »

bgdam wrote: post #119
IncRnd wrote: post #104

Earlier quoted context omitted.

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.

There is a lot more to the DNS protocol and packet structure than you are aware.

DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.

Re: Massive spying on users of Google's Chrome shows new security weakness

#245

Post by pdkl95 »

dhimes wrote: post #205
imrelaxed wrote: post #184

Earlier quoted context omitted.

It would be awesome if there was a volunteer financed code review group to review popular open source projects. I think I’m not the only one who would happily donate money to such a group for code reviews for various OSS projects. Initial code reviews would require a lot of effort, unless somehow automated, but after that it would be fairly easy to monitor and verify updates and changes to the code.

I wonder if EFF or somebody could issue a "verified" badge that apps could apply for, with a small fee to finance the devs doing the audits?

A prerequisite of that type of badge that I really wish existed is a standardized, interoperable protocol for curation. Instead of trying to solve the problem of malicious software with a walled garden app store, anyone should be able to publish their own curated list of software (or any type of project?). The core component is a crypto-signed statement like:

    { "curator": {
         name="Alice",
         pubkey="...",
         url="..."
      },
      "artifact": {
         type="software",
         name="Bob's App",
         version="1.2.3",
         published_file="bobapp-1.2.3.zip",
         published_file_sha256="...",
         published_file_url="..."
      },
      "statements": [
         { "type": "member_of_collection",
           "name": "Recommended Apps" },
         { "type": "attestation",
           "name": "Passed Audit FOO",
           ...audit info... }
       ]
    }
Publish lists of these (maybe RSS-ish style?), with sort of browsable/searchable/app-store-ish UI.

A key feature is verification. A user should be able to easily inspect the known "curator statements" for an app for the curators the subscribe to, and be able to run a "git fsck"-style validation that proves "this app really is the version that: passed the EFF's 'No Tracking' audit, is on reviewer Carol's 'Recommended' list, was rated "Teen" by the ESRB, and is on my friend Dave's 'Cool stuff you should try' list.

With such a system, anyone can perform an audit, and people can make their own decisions about what they want to trust.

Re: Massive spying on users of Google's Chrome shows new security weakness

#246

Post by joshuamorton »

raxxorrax wrote: post #228
joshuamorton wrote: post #130

Earlier quoted context omitted.

You've contradicted yourself in the first 3 lines. > At the same time, back in 2016 a study at Princeton found almost 50% of all sites on the web had Doubleclick tracking on the Means that many people are going to doubleclick, via it's ads existing on other sites. If the extent of your concern is that I said "going to" instead of "makes requests to", valid and I apologise for not being precise in my use of language.…

I hope there is generally less rationalization at Google towards privacy practices to be honest. I think the behavior on display is pretty sneaky, undermines privacy and users aren't really informed about Google doing "research" on them.

This is a fair comment. I'm not saying that there couldn't be better privacy practices in place (while I think Google is better than average here, we aren' perfect and to your point I think a lot of people within Google recognize that).

But the question here is what part of this is sneaky? Is including a weird tracking header sneaky? Perhaps. Is making requests to doubleclick sneaky? In the context of those requests being made as part of a page load? Not on the part of Google, which is my point.

The original complaint was that the header was being sent

> That Google need to send "experimental headers" to a hardcoded domain for an advertising company they bought a decade or so back - because of course the results of web browser experiments should go to an advertising company

And the reason why is simple: that's the domain people are already making requests to.

Re: Massive spying on users of Google's Chrome shows new security weakness

#247

Post by joshuamorton »

0xy wrote: post #174
joshuamorton wrote: post #97

Earlier quoted context omitted.

> Hence the ambiguous PR statement. There's nothing ambiguous about "is not used to identify or track individual users.". Any form of personalized ad tracking would require tracking individual users, by definition. So there's your answer. Your attempts to create weaseling where there isn't any, so that you can continue to exclaim about the potentials for tracking don't actually change the ambiguity of the statement.…

If Google can't keep things quiet, where can I find a rough list of factors DoubleClick uses in order to track users? Has any of those factors leaked in the past? Would anyone on the ad team at Google jeopardize their $350k per year to leak unethical behavior in that division? There's plenty ambiguous about that statement. Firstly, it doesn't cover past or future. Room for weaseling there. Secondly, it specifically s…

> If Google can't keep things quiet, where can I find a rough list of factors DoubleClick uses in order to track users?

Do you mean like, categories into which it divides users (age, gender, interest), in which case a reasonable answer is https://adssettings.google.com/ or do you mean what request attributes it uses to make these determinations initially and tie them to particular users? In which case the answer is primarily cookies: https://policies.google.com/technologies/types?hl=en-US.

You're asking me to prove a negative, and you're starting from the assumption that Google must be lying.

> In fact, it doesn't even say it isn't a factor in ad targeting algorithms.

How can something be a factor in ad targeting without being used to target individuals?

Re: Massive spying on users of Google's Chrome shows new security weakness

#248

Post by sergeykish »

michaelbazos wrote: post #219
matheusmoreira wrote: post #117

Earlier quoted context omitted.

The only trustworthy extensions are uBlock Origin and EFF's Privacy Badger. Everything else is best viewed as potential malware, no different than random downloadable executables. Honestly, uBlock Origin and Privacy Badger are so important at this point they should just become part of the browser itself. They're already in a league of their own.

There are often other extensions that we find too precious to delete them, however we need them only at specific occasions. For those, I came up with a “meta-extension” to easily disable or enable them: https://chrome.google.com/webstore/detail/extension-manager/...

This is great! But it is minified and there is no link to source. Why?

Re: Massive spying on users of Google's Chrome shows new security weakness

#249

Post by criley2 »

sergeykish wrote: post #214
criley2 wrote: post #201

Earlier quoted context omitted.

1. "Recommended" extensions are a subset of all extensions, so to narrow the comparison from "Extensions" to "A limited subset" feels dishonest. Not all Firefox extensions are Recommended. 2. Firefox took years and years to lock down extensions like Chrome, and people were legitimately upset that they turned extensions into basically privileged webpages in the name of security. They used to be more like software. It…

1. I just said it is good if at least subset can be trusted. It would be nice to have such feature in Chrome. 2. Sorry, could you please make your point clear (edit)? Firefox third party extensions used to access internal constructs. I think most of what is Firefox on top of Gecko is privileged extensions. 3. Yes, Firefox had addons with review process.

2. I'm talking about the switch to WebExtensions, https://wiki.mozilla.org/WebExtensions/FAQ, which every major browser followed Chrome in doing, which was largely done for security reasons

3. Firefox does not manually review every extension, they perform some cursory virus/malware scans, same as Google. I think you're really overplaying the idea that Firefox has some manual review process ensuring only quality and safe extensions are uploaded. The best way to demonstrate this is to point out that Firefox must frequently ban released extensions -- extensions which passed these so called reviews.

Re: Massive spying on users of Google's Chrome shows new security weakness

#250

Post by pdkl95 »

kyboren wrote: post #243
yjftsjthsd-h wrote: post #237

Earlier quoted context omitted.

My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.

This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the reques…

> The bandwidth of the side channel can be dramatically reduced

In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour.

That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model.

> e.g. IP address or browser user agent string)

Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number).

Security is hard... ~sigh~

[1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua...

[2] https://nmap.org/book/man-os-detection.html

[3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

Post reply on HN