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

Firefox about:config privacy settings

gist.github.com

Post reply on HN
Print view View original

81–90 of 154 posts

Re: Firefox about:config privacy settings

#81

Post by Uplink »

Who do I tell my brand new, bright idea about IDN attack prevention?

It goes like this:

Display characters that are out of range of your selected language's character set in a different colour than the characters of your language.

That way, when you go to раураӏ.com that last character shows up in red.

Homework: select two languages (e.g. Chinese and English), and use three colours. Make the colour scheme colour-blind-friendly.

(it just came to me, I haven't thought it through; I'd rather read different coloured characters than punycode)

Re: Firefox about:config privacy settings

#82

Post by ztoben »

thiht wrote: post #55
all_factz wrote: post #16

One thing that's frustrated me about FF (and kept me using Chrome) is that local development is a pain in general... for example, when I type `localhost` in my nav bar, Chrome autofills the port; FF doesn't (it just puts `localhost/`, which is useless). Next, FF interacts oddly with NGINX, telling me `The plain HTTP request was sent to HTTPS port`, whereas Chrome just passes me right along, giving me a little `Not Se…

>for example, when I type `localhost` in my nav bar, Chrome autofills the port; FF doesn't (it just puts `localhost/`, which is useless). What? Isn't it the opposite? I have the exact opposite experience with Firefox and Chrome, FF autofills the ports and Chrome doesn't oO I just checked it right now to be sure I reminded correctly

Not sure about firefox, but localhost definitely autofills localhost for me in chrome.

Re: Firefox about:config privacy settings

#83

Post by krn »

phyzome wrote: post #60

This list is somewhere between worthless and dangerous. Chesterton's Fence: Presumably Mozilla has already optimized the privacy and performance of Firefox as much as they've felt comfortable doing. If they could change each of those settings as recommended without tradeoffs to help the user, they would have done so. Without listing the tradeoffs for each one, this list cannot be relied upon.

What Mozilla did in the default Firefox configuration, is made the trade-offs on behalf of an average browser user. It's neither worthless, nor dangerous for a savvy browser user to make the trade-offs for himself. That's exactly what software configurations are for.

Re: Firefox about:config privacy settings

#84

Post by A2017U1 »

Uplink wrote: post #81

Who do I tell my brand new, bright idea about IDN attack prevention? It goes like this: Display characters that are out of range of your selected language's character set in a different colour than the characters of your language. That way, when you go to раураӏ.com that last character shows up in red. Homework: select two languages (e.g. Chinese and English), and use three colours. Make the colour scheme colour-blin…

Punycode renders as ascii in chrome (not sure about ff), people will notice the malformed url and that something is wrong.

Re: Firefox about:config privacy settings

#85

Post by OzzyB »

Somewhat tangental but can someone explain why Firefox users need to explicitly enable new Streams API support? [1]

Safari, Chrome implement these APIs out-of-the-box but FF wants users to open `about:config` (and ignore the ominous warning) and set `dom.streams.enabled` and `javascript.options.streams` to `true`.

It seems a little backwards to me since this has been available since version 57 and their webpage is the first result when searching for this documentation!

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStr...

Re: Firefox about:config privacy settings

#86

Post by sciurus »

all_factz wrote: post #16

One thing that's frustrated me about FF (and kept me using Chrome) is that local development is a pain in general... for example, when I type `localhost` in my nav bar, Chrome autofills the port; FF doesn't (it just puts `localhost/`, which is useless). Next, FF interacts oddly with NGINX, telling me `The plain HTTP request was sent to HTTPS port`, whereas Chrome just passes me right along, giving me a little `Not Se…

Firefox definitely autofills ports based on your history. Below is a screenshot of it doing it for me.

https://imgur.com/a/VRXsyUf

I don't know what is going on with your nginx setup. Most likely you've configured it differently than you think you have, or are making different requests in Firefox and Chome without realizing it. Both firefox and chrome behave the same for me when I make an http request to to a server using https (e.g. http://www.example.com:443/)

Re: Firefox about:config privacy settings

#87

Post by [deleted] »

floatingatoll wrote: post #74

Seriously, again? Applying all of the changes at this list will harm users and increase the chances of threats compromising the browser. Don’t be shortsighted and use this blindly. Especially do not punish some poor unwary non-tech user by altering these settings on their behalf.

[deleted]

Re: Firefox about:config privacy settings

#88

Post by myfonj »

thiht wrote: post #55
all_factz wrote: post #16

One thing that's frustrated me about FF (and kept me using Chrome) is that local development is a pain in general... for example, when I type `localhost` in my nav bar, Chrome autofills the port; FF doesn't (it just puts `localhost/`, which is useless). Next, FF interacts oddly with NGINX, telling me `The plain HTTP request was sent to HTTPS port`, whereas Chrome just passes me right along, giving me a little `Not Se…

>for example, when I type `localhost` in my nav bar, Chrome autofills the port; FF doesn't (it just puts `localhost/`, which is useless). What? Isn't it the opposite? I have the exact opposite experience with Firefox and Chrome, FF autofills the ports and Chrome doesn't oO I just checked it right now to be sure I reminded correctly

I have opposite experience with Chrome as well: I like when URL bar behaves just like URL bar and does nothing extra. I worked in company that used custom TLD for all sites in internal network, and every single time I entered such `site.tld` in Chrome's URL bar it insisted on _searching_ for that instead of just appending protocol, '/' path and visiting it like reasonable browser.

To be honest, Firefox likes to mess with input too, but it can be easily tamed with few prefs, namely:

    keyword.enabled=false
    // no implicit searching from URL, must use explicit keyword or Searchbar
    browser.fixup.alternate.enabled=false
    // this prevents trying www. … .com or other configured suffixes when domain-like URL fails
    browser.urlbar.trimURLs=false
    // do not hide protocol and slash
    browser.urlbar.filter.javascript=false
    // bookmarklets FTW

Re: Firefox about:config privacy settings

#89

Post by tialaramex »

Uplink wrote: post #81

Who do I tell my brand new, bright idea about IDN attack prevention? It goes like this: Display characters that are out of range of your selected language's character set in a different colour than the characters of your language. That way, when you go to раураӏ.com that last character shows up in red. Homework: select two languages (e.g. Chinese and English), and use three colours. Make the colour scheme colour-blin…

Colouring is not very universal, and so not generally a good choice. Browsers have taken different approaches to this, two popular ones are:

* Identify TLD registry operators who have a sane approach that prohibits or otherwise is effective for controlling homographs, whitelist their TLDs, default to showing punycode (the A-labels used by the DNS system which are always just ASCII). This has the effect that if your name looks "wrong" that's a problem to take up with your TLD registry. Note that com doesn't have such policies at all, it's a vast sleazy market and it remains interesting to me that huge global brands would rather be in that market, trying to shout over the crowd, than leave it to rot.

* Identify cases like you've described with "confusing" mixtures of scripts and display those as punycode.

Both have problems. The former requires that you effectively police TLD registry operators. Find out what their policies are, check they actually implement those policies effectively, and take action if this changes. The latter requires you figure out how all the world's language communities use different scripts, and how that interacts with Unicode, in order to avoid penalising combinations lots of people want, while still detecting attacks.

Post reply on HN