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

Tor at the Heart: Firefox

blog.torproject.org

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Tor at the Heart: Firefox

#51

Post by simcop2387 »

kibwen wrote: post #48
sintaxi wrote: post #18

Earlier quoted context omitted.

why don't browsers just ship with its own fonts?

Few (none?) of the ancient "web-safe fonts" are permissively licensed. And nice-looking fonts that look good on all OSes and that have a large set of glyph coverage are quite expensive to make (though I'm sure Google/Microsoft/Apple could afford it).

Google does sort of do this with the Droid family of fonts. https://fonts.google.com/specimen/Droid+Sans They're not perfect though, but it is a start. I think one or two of Apple's might be permissively licensed also but I'm not certain.

Re: Tor at the Heart: Firefox

#52

Post by gnodar »

cryptarch wrote: post #38
swiley wrote: post #33

Why use firefox at all? why not something based on libcurl that absolutely does not talk back to the server after reciving the document unless the user clicks on a link or submits a form?

I wish you good luck doing online banking that way :')

Are people doing online banking using Tor?

Re: Tor at the Heart: Firefox

#53

Post by eslaught »

kibwen wrote: post #47
MR4D wrote: post #41

Earlier quoted context omitted.

On mine, the System Fonts give 17 bits of info (1 in roughly 200,000 computers). User-Agent is next with only 8 bits. Based on that alone, it seems that just replying back with either a blank font list or the minimal standard font list (e.g. only Times & Arial) would solve most of this problem. I'd love to see the Firefox team fix that first.

Unless every browser in the world adopts the same list, replying with a fixed list of fonts would make users of a given browser immediately recognizable (especially for low-marketshare browsers like Tor). Seems like you'd want a system where the response to a list-of-fonts query would be semi-random and likely to overlap with the lists that are naturally produced by other browsers.

But user agents already identify the browser, right?

I agree that implementing this first in Tor is probably not a good idea, but if Firefox were to do it first, then I don't see the problem. "They're a Firefox user" isn't nearly as specific information.

Re: Tor at the Heart: Firefox

#54

Post by jgraham »

btown wrote: post #50
bzbarsky wrote: post #24

Earlier quoted context omitted.

That's not the same thing. "uplift" for that page means "backport from development trunk to a more-stable branch".

Theoretically Tor Browser's fork is just another development branch of Firefox, just like Mozilla's primary development branch, and they are "uplifting/backporting" individual patches into stable the same way Mozilla might backport crucial dev-branch improvements/bugfixes into stable.

But they aren't landing patches on "stable", but on the upstream development branch (i.e. mozilla-inbound/central). Since it seems more reasonable to view tor browser as a release branch of firefox than as a development branch, it seems like they are using "uplift" in the opposite sense to the normal Mozilla usage i.e. they are taking a patch from a product branch and moving it to a development branch. In that context "upstream" might indeed be a less confusing choice of words.

On the other hand I think it's clear what they actually mean here, so probably not worth worry about too much.

Re: Tor at the Heart: Firefox

#55

Post by MR4D »

kibwen wrote: post #47
MR4D wrote: post #41

Earlier quoted context omitted.

On mine, the System Fonts give 17 bits of info (1 in roughly 200,000 computers). User-Agent is next with only 8 bits. Based on that alone, it seems that just replying back with either a blank font list or the minimal standard font list (e.g. only Times & Arial) would solve most of this problem. I'd love to see the Firefox team fix that first.

Unless every browser in the world adopts the same list, replying with a fixed list of fonts would make users of a given browser immediately recognizable (especially for low-marketshare browsers like Tor). Seems like you'd want a system where the response to a list-of-fonts query would be semi-random and likely to overlap with the lists that are naturally produced by other browsers.

It would reduce the variability. 1 in 200,000 is reasonably unique. But if all Firefox browsers reported the same result for fonts, then it would provide no more information than the spying website already has (i.e. the user is using Firefox).

I'd bet that Chrome would follow quickly, which would put pressure on Apple to do the same. If that happened, we'd have a minor victory.

All I'm trying to do is reduce information that is needlessly leaked out by a browser. True privacy still requires more.

Re: Tor at the Heart: Firefox

#56

Post by ta3434343434 »

kibwen wrote: post #47
MR4D wrote: post #41

Earlier quoted context omitted.

On mine, the System Fonts give 17 bits of info (1 in roughly 200,000 computers). User-Agent is next with only 8 bits. Based on that alone, it seems that just replying back with either a blank font list or the minimal standard font list (e.g. only Times & Arial) would solve most of this problem. I'd love to see the Firefox team fix that first.

Unless every browser in the world adopts the same list, replying with a fixed list of fonts would make users of a given browser immediately recognizable (especially for low-marketshare browsers like Tor). Seems like you'd want a system where the response to a list-of-fonts query would be semi-random and likely to overlap with the lists that are naturally produced by other browsers.

Generally speaking, you have two approaches (that I'm aware of) for addressing fingerprints: one is to "hide in the crowd", i.e., return values that are common across the browsers population. The second is to create unique value for each separate session (like incognito and cookies). See: https://www.microsoft.com/en-us/research/wp-content/uploads/... [PDF!]

Re: Tor at the Heart: Firefox

#57

Post by dexterdog »

eslaught wrote: post #53
kibwen wrote: post #47

Earlier quoted context omitted.

Unless every browser in the world adopts the same list, replying with a fixed list of fonts would make users of a given browser immediately recognizable (especially for low-marketshare browsers like Tor). Seems like you'd want a system where the response to a list-of-fonts query would be semi-random and likely to overlap with the lists that are naturally produced by other browsers.

But user agents already identify the browser, right? I agree that implementing this first in Tor is probably not a good idea, but if Firefox were to do it first, then I don't see the problem. "They're a Firefox user" isn't nearly as specific information.

User agent gives the browser version and platform version. Two macs with the same OS version and the latest version of Chrome will have the same user agent.

Re: Tor at the Heart: Firefox

#58

Post by dexterdog »

cobbzilla wrote: post #39
swiley wrote: post #33

Why use firefox at all? why not something based on libcurl that absolutely does not talk back to the server after reciving the document unless the user clicks on a link or submits a form?

that's the Richard Stallman approach: https://stallman.org/stallman-computing.html he has a script that he can poke to download the content and email it to himself. then he reads it with emacs or maybe lynx with no networking enabled.

At least he doesn't print it out.

Re: Tor at the Heart: Firefox

#59

Post by nsgi »

dexterdog wrote: post #57
eslaught wrote: post #53

Earlier quoted context omitted.

But user agents already identify the browser, right? I agree that implementing this first in Tor is probably not a good idea, but if Firefox were to do it first, then I don't see the problem. "They're a Firefox user" isn't nearly as specific information.

User agent gives the browser version and platform version. Two macs with the same OS version and the latest version of Chrome will have the same user agent.

That's the point. With this feature, two computers with the latest version of Firefox would have the same font list.

Re: Tor at the Heart: Firefox

#60

Post by gsnedders »

MR4D wrote: post #41
noja wrote: post #19

Earlier quoted context omitted.

Someone else can answer better than me, but https://panopticlick.eff.org claims the canvas fingerprint provides 17 bits of identifying information (click detailed results after testing)

On mine, the System Fonts give 17 bits of info (1 in roughly 200,000 computers). User-Agent is next with only 8 bits. Based on that alone, it seems that just replying back with either a blank font list or the minimal standard font list (e.g. only Times & Arial) would solve most of this problem. I'd love to see the Firefox team fix that first.

A blank font list where? There's no way to get a direct list of fonts: you just try rendering text with a given font and look at the metrics of it versus the fallback. Font lists are done using side-channels (and you also therefore have to have a list of fonts to sniff in the first place).

The only way to stop font-based side-channels is to limit the web to a fixed set of fonts: and that will horribly break the web in some linguistic communities where there's a fair amount of web content that relies on specific fonts (that typically map old Windows codespaces to other characters for support for their language, often before Unicode covered those characters).

You also need identical fonts for a given user agent, and that's very hard to guarantee short of shipping your own fonts (e.g., consider an OS update that changes a font!), and that becomes expensive fast.

Post reply on HN