DNS security should be detailed in site information panel
Categories
(Firefox :: Site Identity, enhancement, P3)
Tracking
()
People
(Reporter: grover, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [trr])
Attachments
(1 file, 2 obsolete files)
I think the status of the security of the DNS requests that went into fetching a page should be listed in the site information panel.
Our solution to protect the privacy of DNS requests, DNS over HTTPS (DoH), when enabled in Network Settings, has no visible way for the user to know if it's doing anything, other than about:networking->DNS TRR column.
Especially since we are looking at ways to conditionally enable DoH on a per-site basis to avoid some issues, having visibility into whether a given site caused an insecure DNS request on the network would be very valuable for users.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
- Are we showing it's DNS encrypted once the top-level document is resolved by DoH? What if some sub-resources are not?
- Cached resource are flagged as non-DoH, do we want to point this state out?
Comment 2•5 years ago
|
||
Comment 3•5 years ago
|
||
Comment 4•5 years ago
|
||
Wayne, could you help find someone to work on the UX please?
Comment 5•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
(In reply to Nhi Nguyen (:nhi) from comment #4)
Wayne, could you help find someone to work on the UX please?
Bryan Bell is working on this.
Updated•5 years ago
|
Comment 8•5 years ago
|
||
I’m not working on this...
Updated•3 years ago
|
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Boo, phab, you're not helpful.
Comment 10•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:pbz, since the bug has high priority and recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 11•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Description
•