Live data from Hacker News

Firefox 90 supports Fetch Metadata Request Headers

blog.mozilla.org

71–80 of 109 posts

Re: Firefox 90 supports Fetch Metadata Request Headers

#71

Pardon my ignorance. I thought the way to deal with csrf was csrf tokens. It seems like you would still have to ignore the headers and rely on the token in your logic if ever they disagreed. I’m not sure how to use these new headers

CSRF tokens have overhead and they have to be implemented for all inputs which isn't trivial (judging by amount of CSRF related vulnerabilities disclosed in hacker one reports). I think the intention here is to make cross site requests stand out so that they can be dealt with in a more streamlined/uniform fashion.

Re: Firefox 90 supports Fetch Metadata Request Headers

#72

Earlier quoted context omitted.

You'll likely need a laptop CPU/GPU/APU, OS, browser, and site that natively support WebRTC and the media codec being used in hardware as much as possible. That's probably going to be AV1 support across the board for the foreseeable future. That's probably a couple years out. Real time AV codecs generally did not choose the "cheap" aspect of the "good / fast / cheap" triangle.

I hear this, but also it works fine in Safari... and even less bad in Chrome on a MBP. Not an expert, but that makes me think there's something the Firefox folks can do to improve this issue. If they wanted to. It's not like 2x, it's like 40x more power used. This makes the MBP super heat. Thing was never cool to start, but I suspect it's getting hot enough to shorten the battery life. It's really hot. Happens on eve…

Well, it's much easier for Apple to get the optimizations on their hardware, drivers, OS, and web browser to all line up. There are some benefits of the cathedral.

However, I agree with others that there may be an actual bug going on. There are definitely listings in Bugzilla for WebRTC bugs[0], the oldest of which is 7 years old.

I'm curious if you're just seeing high battery usage, or is there high CPU as well?

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1700778

Re: Firefox 90 supports Fetch Metadata Request Headers

#73
post #62
post #30

Earlier quoted context omitted.

This is a story that you can often hear on HN but I don't think it's correct. There were three correlated reasons for the bad reputation of IE some years ago: 1. it was largely dominant, so people thought they could develop just taking that browser in consideration 2. for the previous point, MS started to develop proprietary features (like ActiveX) 3. at a certain point its development was stopped for a long time Saf…

Right now but you can reasonably develop a website which will work in Chrome and Firefox even without testing (not talking about any supper modern features), but Safari is riddled with bugs you wouldn't expect. Recently I have encountered multiple bugs regarding svg clipping in safari. Safari 14 also broke localstorage and indexeddb it's almost funny how bad safari is at actually just working.

My homepage is tiny and absolutely nothing fancy, but I've still managed to immediately run into at least two Chrome bugs.

Re: Firefox 90 supports Fetch Metadata Request Headers

#74
Very happy to see this landing in Firefox!

For the people wondering what the motivation is, https://www.w3.org/TR/fetch-metadata/#intro has a good summary:

Interesting web applications generally end up with a large number of web-exposed endpoints that might reveal sensitive data about a user, or take action on a user’s behalf. Since users' browsers can be easily convinced to make requests to those endpoints, and to include the users' ambient credentials (cookies, privileged position on an intranet, etc), applications need to be very careful about the way those endpoints work in order to avoid abuse.

Being careful turns out to be hard in some cases ("simple" CSRF), and practically impossible in others (cross-site search, timing attacks, etc). The latter category includes timing attacks based on the server-side processing necessary to generate certain responses, and length measurements (both via web-facing timing attacks and passive network attackers).

It would be helpful if servers could make more intelligent decisions about whether or not to respond to a given request based on the way that it’s made in order to mitigate the latter category. For example, it seems pretty unlikely that a "Transfer all my money" endpoint on a bank’s server would expect to be referenced from an img tag, and likewise unlikely that evil.com is going to be making any legitimate requests whatsoever. Ideally, the server could reject these requests a priori rather than delivering them to the application backend.

Here, we describe a mechanism by which user agents can enable this kind of decision-making by adding additional context to outgoing requests. By delivering metadata to a server in a set of fetch metadata headers, we enable applications to quickly reject requests based on testing a set of preconditions. That work can even be lifted up above the application layer (to reverse proxies, CDNs, etc) if desired.

Re: Firefox 90 supports Fetch Metadata Request Headers

#75
post #5

Since Encrypted SNI was disabled in Firefox 85, all the hostnames are transferred in plaintext, even using HTTPS. It was also disabled from Firefox ESR 78 at one point around ESR 78.9 This Not only makes DNS over HTTPS absolutely useless, but it is also giving browsing information by duplicate, to the ISP, to the intermediaries and to the DNS providers. From the article, "If you aren’t a Firefox user yet, you can dow…

This article and accompanying discussion is not about ESNI or ECH, nor about concerns thereof; it is about the W3 `fetch-metadata` specification that Firefox is implementing:

https://www.w3.org/TR/fetch-metadata/

If you'd like to start a discussion about ESNI/ECH, please either write a blog post or find one about this, and submit that to HN for discussion.

Re: Firefox 90 supports Fetch Metadata Request Headers

#77

Does that mean that the quest of finding a working direct link to the image/video will soon become impossible?

Can you provide an example of such a "quest"?

The only speed bumps I have encountered are timestamps, i.e., links that "expire".

Re: Firefox 90 supports Fetch Metadata Request Headers

#78
post #62

Earlier quoted context omitted.

Right now but you can reasonably develop a website which will work in Chrome and Firefox even without testing (not talking about any supper modern features), but Safari is riddled with bugs you wouldn't expect. Recently I have encountered multiple bugs regarding svg clipping in safari. Safari 14 also broke localstorage and indexeddb it's almost funny how bad safari is at actually just working.

My homepage is tiny and absolutely nothing fancy, but I've still managed to immediately run into at least two Chrome bugs.

Well I found some chrome bugs, but here is the thing after I reported them, they have been immediately responded to and fixed and released in nearest version. Safari though you have to wait a year for bug fixes to be released, if they even acknowledge you at all inside their bug tracker the only way to get Webkit people attention is tag them on twitter.

Re: Firefox 90 supports Fetch Metadata Request Headers

#79
post #9

Earlier quoted context omitted.

If site producers want to it's already pretty much impossible today. At least without some "tricks", and nothing prevents your video-downloader from just adding a header which pretend it's origin is a website. (Or more funny you inject the downloading JS code into the website in question extending it with a download functionality ;=) ).

There's a difference between only allowing that behaviour, and explicitly creating features to enable it. This sounds like Referer, but worse.

(1) How is it like Referer? (2) How is Referer bad? Like it "tracks" you? Seems like the 1000th least bad tracker you probably run.

Re: Firefox 90 supports Fetch Metadata Request Headers

#80

Does that mean that the quest of finding a working direct link to the image/video will soon become impossible?

Exactly - why do I as a user want this? I already need an extension to fake the Referer...

Protect against cross-site vulnerabilities.
Post reply on HN