Firefox and Fastly take another step toward a privacy upgrade for the internet | Hacker News Reader

Firefox and Fastly take another step toward a privacy upgrade for the internet

fastly.com

Missing from this article is: How do I disable this.

My initial thoughts are: I don't have any reason to trust fastly or their motivations. I certainly don't have any desire to use them as a proxy server for all of my HTTP traffic.

I'll review the OHTTP spec carefully, which seems to have been put forward by mozilla (who I have limited faith in) and Cloudflare (whose motivations are suspect), and evaluate this in depth, but for now I just don't want to worry that a browser update is going to cause firefox to start sending my data to a third party.

If the concern is that websites know what our IP is due to HTTP requests, we already have some solutions for that, a VPN being a good one. Mozilla already offers a VPN.

Without going into trust / motivation / etc. of various organizations, OHTTP is not used for general purpose web browsing. This Fastly service is used by Mozilla in conjunction with their own origins, not to random origins on the Internet.

Sadly neither the Fastly nor the Mozilla blog clearly states this out, or lists down the origins/services for which this is enabled.

This Fastly blog post is really meant to announce the working relationship.

It's not my place to say specifically what this is for (although I imagine Mozilla may announce it themselves), but as of now it's a single use case.

OHTTP is designed for low latency or lightweight applications. A VPN (or MASQUE, to later comments) requires that you do two handshakes before making a request: one with the VPN and one with the server you want to talk to. OHTTP does away with the second and, where where you are making multiple requests, lets the first handshake only occur once (a VPN/MASQUE can do this too).

Now, this has very little to do with what you might trust Firefox or Mozilla to do. OHTTP only provides a degree of anonymity. If you don't want to share the data that is carried in the message, then you might want to disable the request, not the privacy protections that OHTTP provides. Firefox will use OHTTP for different purposes, so you need to look at each in turn.

You can disable the configuration in the `network.trr.use_ohttp` field. It's already disabled on my Firefox 118.0.1 (NixOS 23.05)

Now just do native vertical tabs and I'll have 0 problems with FF

I’d settle for being able to turn off the unreasonably huge pane header that comes with extensions that implement vertical tabs via the sidebar.

Yes it can be hidden with userchrome mods, but it shouldn’t be necessary to resort to that, plus we don’t know how long userchrome mods will continue to work…

It took me a decent amount of work to finally get my sidebery visually config’d in a way that I found acceptable. I haven’t worked that hard on setting up an extension in a long time!

A little bit of userchrome.css magic fixes this. I use treestyle tabs and for mine I simply added:

#TabsToolbar {visibility: collapse;} #sidebar-header {visibility:collapse;}

Native would be great, but for my use case the Tab Center Reborn extension for Firefox is the best implementation of vertical tabs I've used on any browser, native or otherwise. There's other extensions like Sidebery and Tree Style Tabs, but I haven't really tried them.

So you think TCR is the best one, but you haven't really tried the other ones? How can you know?

GP is clearly comparing their experience of FF+TCR with other browsers that implement vertical tabs (either natively or via extensions).

You're arguing against a strawman.

Apparently Mozilla is working on that for over a year now (announced in Feb '22).

How does this compare to Apple Private Relay?

I was thinking exactly the same…

Apple private relay uses Fastly as one of the providers so I wouldn't be surprised if this is implemented the same way.

would that be true for providers that aren't Fastly? why would there be a different implementation for non-fastly? or are they the sole providers for private relay?

There are other providers of the second hop proxy for iCloud Private Relay, Fastly is one of them.

These services are implemented in different parts of Fastly's production stack, but they share the same global infrastructure footprint and a lot of the same people/teams are involved with both.

This service with Mozilla utilizes OHTTP, whereas iCloud Private Relay uses MASQUE.

OHTTP is ideally suited for privacy enablement of APIs, whereas MASQUE is more for general purpose traffic.

OHTTP has similarities to MASQUE in that it uses a two hop proxy design where each proxy only knows part of the total requestor / request information. And in both cases these proxies must be operated by separate entities that do not collude.

However, the key difference is that in OHTTP the end destination is known, because there is a 1-1-1 mapping between OHTTP Relay -> OHTTP Gateway -> Target. This could become more generalized in future revisions to OHTTP, but right now it's all hardcoded behavior.

For more about OHTTP at Fastly, I wrote a blog post a while back at [1]. There is also the IETF draft spec at [2].

[1] https://www.fastly.com/blog/enabling-privacy-on-the-internet...

[2] https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp

>However, the key difference is that in OHTTP the end destination is known, because there is a 1-1-1 mapping between OHTTP Relay -> OHTTP Gateway -> Target. This could become more generalized in future revisions to OHTTP, but right now it's all hardcoded behavior.

So the Relay knows the requested URL? That’s not masked by the client?

OHTTP encapsulates a complete request, so the 1-1-1 mapping isn't right. The target can be any resource, but it generally should be on the same host/origin as the gateway. The gateway sees the request and the response, so there are very few cases where you would trust it to handle requests for any URL.

Thanks

Yes, that's true. However in practice most deployments that I've worked on are a relay which maps all requests to a gateway which maps all requests to a target. It's not an inherent property of the protocol, and I expect that to evolve over time.

The Relay doesn't know the requested URL or the request body -- but it does know the next-hop destination (the OHTTP Gateway), and by virtue of the way most OHTTP services are currently deployed this tells you the destination service. It does not tell you the specific details of what is being asked for / returned by that service.

Thanks

So correct me if i'm wrong, this mean that it basically is man in middle relay sitting between you and resource you are trying to access, and knows things you want. Basically an aggregator of data under guise of privacy.

Mozilla and The Tor Project have been collaborating for years. Mozilla does not have the backbone to implement Tor Browser as Private Browser mode in Firefox. Do better, Mozilla.

brave did what mozillouldnt

There's a reasonable case that Private Browsing and Tor serve different enough use cases that they're not interchangeable.

Private Browsing: The goal is to prevent embarrassment. I'm looking at porn or shopping for gifts for my spouse, and I don't want it showing up in the autocomplete/history/remarketing ads as much as possible.

Tor: The goal is to prevent imprisonment. I'm accessing stuff that's politically sensitive and either inaccessible or likely to trigger consequences if it's detected by local ISP infrastructure.

Obviously, Tor offers a higher overall security profile, but tends to break things (services using IP blacklists, services that don't do well with its performance characteristics, etc.) that people expect to work with today's Private Browsing.

ISTR when one implementation of it came out (not sure if it was Firefox's or the original Chrome Incongito mode) the launch page said point blank "this will not hide your movements from your ISP, governments, site hosts, etc."

Damn, I misread Fastly as Fastmail and thought Mozilla had partnered with them too provide a paid email-hosting service.

Reply on news.ycombinator.com