(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily reproduce this bug using those: "https://ا.pwr.wtf/?spoof= www.google.com ." We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
Bug 1925496 Comment 20 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily reproduce this bug using those: https://ا.pwr.wtf/?spoof= www.google.com . We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily reproduce this bug using those: `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily bypass the regex using those: `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because we do have a list of invisible chars already at https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because [we do have a list of invisible chars already](https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897)): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})`
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because [we do have a list of invisible chars already](https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897)): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})` (one examples of barely visible char: `\u0702`)
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, or invisible like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because [we do have a list of invisible chars already](https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897)): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})` (one examples of barely visible char: `\u0702`)
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, or invisible like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because [we do have a list of invisible chars already](https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897)): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})` (one examples of barely visible char: [`\u0702`](https://ا.pwr.wtf/?spoo%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20www.google.com%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20.))
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, or invisible like `\u00AD`, `\u061C`. I can easily bypass the regex using those (though they are encoded in the urlbar because [we do have a list of invisible chars already](https://searchfox.org/mozilla-central/rev/aecb006bbb135d707ca4b8cea7572dd8abab6817/browser/components/urlbar/UrlbarInput.sys.mjs#4897)): `https://ا.pwr.wtf/?spoof= www.google.com .` We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})` (one examples of using barely visible char: [`\u0702`](https://ا.pwr.wtf/?spoo%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20www.google.com%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20.))
(In reply to Daniel Veditz [:dveditz] from comment #19) > > I think we should just encode any %20 that is not followed by a printable ASCII. That is more aggressive than the current method, whose primary scope was to try to preserve some URL readability. > > That seems overly aggressive. It would look a bit ugly to have a random %20 here or here in a Latin-based URL: yeah, it is aggressive. My fear is that this becomes a whac-a-mole run after characters that are barely visible, or invisible. We can try to find a set of chars a bit larger than ASCII but still made up of visible characters, or maybe go for `\u0020(?!\p{L})` (one examples of using barely visible char: [`\u0702`](https://ا.pwr.wtf/?spoo%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20www.google.com%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20%DC%82%20.))