Why? The user agent will still be able to choose what to display, and protocol improvements don't prevent you choosing an agent that has your interests at heart.
Using secure transport means nobody else gets to decide, and I certainly have a long list of people I don't want deciding whether I see things, so that helps.
I choose Dillo or Netsurf. Now how can I still use sites it can't even render because the developers have drunk the Google-aid and used some trendy framework that requires the latest version of Chrome and JS just to display some static text and images?
Fuck Google and its creeping control over the Internet.
Once these practices become sufficiently spread, the majority of developers and content producers will never understand that an alternative is possible.
Or maybe he will need it: those same developers can perfectly be contractors for a government agency whose site the user has to access.
Trends slowly creep everywhere, independently on technical merit.
It's mostly radio buttons (with a loading screen and a pile of js/css to make it pretty of course.) You fill it out, click submit and a matching suit gets shipped to your house. I couldn't get some of the controls to work and sent the support people an email. It turns out the form they built uses some special chrome only API and doesn't work in Firefox.
Ditto when I submitted my rental application for my current apartment (how can you screw up a single page with a file form that badly?)
The trends are definitely going the wrong way.
history repeats itself (or more exactly we humans repeatedly step upon the same pile of stuff) Back then it was IE only APIs. Those APIs of course were for better and richer functionality and user experience. And we all know how it ended.
Isn't one of the biggest advantages of ad blocking that it can cut your bandwidth use? I mean, if you aren't going to show the ads, why download them in the first place?
Well, that's a depressing sentence to read. The vultures may be circling, but Firefox isn't dead yet.
I thought it's unmaintained since the recent Mozilla layoffs?
I don’t like this any more than you, but it’s the truth.
- doesn't update via a sketchy background process (Google Updater, or whatever they've renamed it to this month to avoid scrutiny)
- allows me to customize the UI to fit my needs (tree style tabs are an absolute must for me)
- allows me to use a full ad blocker like uBlock Origin instead of arbitrarily limiting the ad blocker API to advance the interests of advertisers
Of course, Firefox's management is an enormous problem, from the way they've prioritized features to the recent layoffs to the enormously stupid decisions (letting a certificate expire that disabled almost all add-ons, the Mr. Robot tie-in "experiment", pushing pocket, default disabling userChrome.css, forcing auto-updates) they've made in the past 5 years. But the core of Firefox is good.
I would love a startup that builds an entire business off of a fork of Firefox that's completely based on privacy, perhaps with some non-invasive monetization like:
- a $5-20 one-time fee to use (with weak enforcement, a la Sublime Text's "annoy you every 5 saves" model)
- a paid vs. free split where the free version of the browser adblocks ads but replaces them with in-network, verified safe ads
- Linux kernel donation-style only model, with no parent corporation
Because of all of the Firefox devs floating around who just got laid off, you could even snatch up some guaranteed capable talent already familiar with the code base. And the best part? They're already vetted to not be part of the management-industrial complex that's taken over Firefox these days.
It's enough of a skew that when rendering errors crop up, product managers have to decide how many eng-hours it's worth to chase down the small implementation difference between Chromium and Gecko to snag 1 in 10 potential lost visitors, instead of throwing a UA-sniffing "best viewed in Chrome" banner on the page and calling it a day.
Being a rarely-used browser is a negative feedback loop for compatibility, regardless of what standards say (because standards are often too loose to guarantee full interoperability in all corner cases; they rarely give performance constraints and often don't consider all possible combinations of feature use).
your ideal privacy focused firefox comes with a conflict of interest built in
Don't know if this is 100% accurate, but Tor?
You probably meant "Tor Browser". Changes from there were backported, and last time I checked plan was to have it entirely backported within Mozilla Firefox.
We're literally discussing this on a post where Chrome is switching from a proprietary protocol (Google QUIC) to a standardized protocol (IETF QUIC).
(Disclosure: I work for Google, speaking only for myself)
What websites are Chrome-only?
So if you now want to spoof as Chrome to your bank, you spoof as Chrome to all websites.
Rather a foot-gun from Mozilla but on par for their recent choices.
This is the real clincher - websites discriminating against Firefox often don't know why. I assume it's because they don't want to be liable for using their software on a browser they haven't tested on. Or it's just the good ol' Google search on Firefox mobile thing, i.e. "we'll gimp it for no particular reason!"
As an early Linux user, I still remember running a Windows VM with IE installed, for years, just to do online banking. Heck, at my current corporate job all the Mac users (mostly the web designers) are given VMs to run IE11 to fill out their timecards, and use product management software. This is absurd, but real.
I'm no stranger to having to use VMs to do basic stuff online, but not everyone else is. And, to be honest, no one should have to set up a VM to use a browser they cannot trust, just to protect themselves from stupid drive-by malware.
Will it? Even on Mozilla Firefox (which fewer and fewer sites are tested against) you're pretty limited in controlling this. I have zero faith that google will keep that working in chrome
Admittedly sites could switch to rendering everything in JavaScript using canvas or WebGL. But so far no one is resorting to this, because you have to effectively reimplement big chunks of the browser. Maybe one day there will be a JS framework that does this, but then it will be easy for adblockers to target that specific framework.
Encryption is what allows user choice rather than leaving you at the mercy of your ISP.
I'd much rather take away the choice to screw with what I see from my ISP.
But I do think it makes much more sense to make the browser just do the job directly, rather than delegating that to a separate device.
Firefox continues to block ads just fine, and it'll keep doing so in a QUIC world, while protecting me even more from malicious local DNS servers. The average person is much more likely to encounter a hostile DNS server than a "helpful" one.
Google only ever shows you ads you want, never "unwanted content". Are you suggesting Google could do even better if they just knew a little more about you?
I'm not saying I'll be giving them unfettered access to my browsing habits so that they can give me some perceived monetary benefit in return. But even if that were the case, so long as they didn't do anything fraudulent or violate my privacy by giving my personal data out, then I'm 100% fine with it. This is no different than Google having algorithmic access to all my personal emails. Once we figure out the two scenarios are the same, we'll quickly realize this whole "protect me from my ISP", "privacy" movement is just a front for taking away people's right to control their own hardware.
DNS-over-HTTPS can actually be useful. I can do bulk DNS lookups from DOH servers using HTTP/1.1 pipelining, retrieving thousands of names at a time over a single TCP connection. I can look up every name for every HN item in one go, store this data in zone file served by a localhost DNS server and generally never have to use remote DNS when browsing HN. This makes for fast browsing with a text-only browser.
The issue I am surprised more people are not raising is the decision of Google to encourage Golang developers to use a "built-in" DNS resolver in their applications rather than relying the system resolver and submitting to traditional user controls like resolv.conf, nsswitch.conf and HOSTS. Regardless of the motivation behind this choice, IMO it tips the scales toward developers instead of (non-Windows) users in terms of ease of control over DNS lookups, not to mention the privacy issue (shared by DOH) of enabling a third party DNS provider to segregate lookups by device.
I don't see them even when searching for commercial things, so I guess they are blockable (I just have uBlock Origin).
Is that built-in resolver somehow configurable? (env vars?)
Ad blocking extensions are really a "last defense" and can be slowly lobotomised as they are under browser vendors' control.
HOSTS files may also be simplest (I totally disagree btw), but I can't imagine they're anywhere near the most common.
That's exactly how DoH is being implemented, and it's why it has caused so much controversy.
That is correct, the IPv6 probes are embedded in the Chromium source, and are removed by the Ungoogled Chromium and/or Inox patchset [1].
[1] https://github.com/Eloston/ungoogled-chromium/tree/master/pa...
That's also a major difference to Ungoogled Chromium, where UC will request "https://..." by default if you just enter the domain.
So in the case of Enterprise Proxies that have no locally force-installed cert to sniff on internet traffic will likely end up with HTTP-everywhere being used. But usually employers that encourage such bad practices also install their snakeoil MITM certificates locally.
You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).
Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.
there is such a poisonous mentality that has taken root, that is popular. no one at the ietf shares these delusional fears, & it's not because the ietf is a bought out shadow puppet. it's because in reality http3 brings what http2 brought but technically better which brought what http1 brought but technically better.
Did you have a good look at how the internet evolved in the last 15 years?
The IETF can invent HTTP/23 with DNS-over-whatever tomorrow, that doesn't change anything about the general state of the internet, which can best be summarized as a "burning pile of poop".
Do you really need any examples of how broken everything is? Do you really wonder that people have "grimdark fantasies" about what the "next cool web feature" will bring to us?
It's about HTTP/3.
Of course, this makes it more annoying to deal with user-hostile user agents such as some kinds of appliances and other locked-down devices; in which case I would suggest "don't buy user-hostile devices".
Such as the Chromebooks many on this site like to rave about.
The only downside to this is that rogue IoT devices or hacked IoT devices can easily get around DNS filtering, but that was already possible before DoH by using or running some benign free public http api for dns lookups.
And better tracking. In DoH RFC [0], 8. Privacy Considerations, 8.2. In the Server:
"HTTP's feature set can also be used for identification and tracking in a number of different ways. For example, Authentication request header fields explicitly identify profiles in use, and HTTP cookies are designed as an explicit state-tracking mechanism .."
"Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP. HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case."
I will stick to DoT.
Also, it isn't like one couldn't be tracked by DNS resolvers without cookies: https://news.ycombinator.com/item?id=20219878 and https://news.ycombinator.com/item?id=19828702
I cannot imagine it happening, it has to be blanket ban. Real life examples, excluding China?
> tracked by DNS resolvers without cookies
Thats Very clever :)) Safari fixed similar thing that was using HSTS, but I bet they'll kill this one too.
I'm sorry but this is very much going to happen since nearly 1B Androids are now DoT capable. ESNI may also be blocked for same reasons once it is widely deployed.
> Safari fixed similar thing that was using HSTS, but I bet they'll kill this one too.
Safari cannot cover for apps sending DNS requests.
That's prediction, not facts I asked for.
In the end, limiting IFrame depth would probably do more than many things for stopping some of the bad actors.
I use uBlock Origin and EFF Privacy Badger for most surfing, which does a decent enough job. I don't think that the enhancements to the protocol really do that much... though I also don't know that some of the tradeoffs are worth losing a human-readable protocol.
You will lose performance, but you’ll gain control.
I don't think we'll ever have unblockable adverts. It would give users a huge incentive to change browser. Google get a great deal of value from people using Chrome and I don't see them giving that up just to serve ads to people that want to block them.
More information here: https://discourse.pi-hole.net/t/how-do-i-block-ads-on-youtub...
I don't think this is a good idea... about a decade ago... as a research project I ran honeypot farm of 13 machines to learn more about malware. The honeypot machines were autonomously surfing the net, parsing the DOM and choosing random links. I ran them in a sandbox and was getting weekly malware hits.
Much to my surprise... most of the malware was coming over advertisement networks on shady websites.