Block subresource requests whose URLs include credentials
Categories
(Core :: Networking, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox54 | --- | affected |
People
(Reporter: valentin, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: sec-want, Whiteboard: [necko-triaged][necko-priority-new])
Attachments
(1 obsolete file)
| Reporter | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Comment 3•9 years ago
|
||
Comment 4•7 years ago
|
||
Comment 5•7 years ago
|
||
| Reporter | ||
Updated•7 years ago
|
| Reporter | ||
Comment 6•7 years ago
|
||
| Reporter | ||
Comment 7•7 years ago
|
||
| Reporter | ||
Comment 9•6 years ago
|
||
There doesn't seem to be any browser consensus on doing this yet.
Updated•6 years ago
|
Comment 10•5 years ago
|
||
It seems the regression against Chrome is closed and this would remove confusing user-facing dialogs. I suspect Johann et al would appreciate it if we did this. If that's the case I'd be happy to get that Fetch PR moving again.
Comment 11•5 years ago
|
||
Sorry, I may be missing something, are we showing any dialogs for sub-resources with credentials? :)
Comment 12•5 years ago
|
||
Sorry, yes, those are indeed different things. What I was thinking of is tracked by bug 647010 I think.
The focus here is primarily reducing opportunities for dictionary attacks. And I think we agree that this would be good, but we were afraid of web compatibility. Now that Chrome has been shipping this for a number of years and the regressions haven't piled up, we should follow I think, unless I'm missing something.
Comment 13•5 years ago
|
||
FWIW I agree though I don't see this as a top priority (but I'll leave that to Necko folks).
Comment 14•2 years ago
|
||
Landed by Chrome in ?59? (2017). Flag to still use it anyways removed in 2021. We should probably follow suit.
Comment 15•2 years ago
|
||
This is duplicate of 479038.
Description
•