For web compat and reduced security surface, I suggest we stop allowing moz-icon URLs on the web.
The ftp directory listing uses moz-icon.
To what degree is this still web-exposed post bug 1173214 ?
I have no idea - do the observations in https://blog.mozilla.org/nnethercote/2015/11/05/moz-icon-a-curious-corner-of-firefox/ still work?
(In reply to Bobby Holley (busy) from comment #3) > I have no idea - do the observations in > https://blog.mozilla.org/nnethercote/2015/11/05/moz-icon-a-curious-corner-of- > firefox/ still work? Yes. http://jsbin.com/fivudigoqe/edit?html,output I'd forgotten I only changed a subset of moz-icon to be unusable from the web. This helps with the ftp file listing issue described in comment #1. We could work around that somehow, though I'm not sure offhand exactly how we would... In principle the file listing page itself is just a page "like any other". We could display the same set of icons as before and pass the data some other way, but if we use blob URIs or data URIs to accomplish this somehow, it seems we'd be likely to give a same-origin web page access to the actual image data, which would be worse than the status quo. Looking at it the other way, we could start treating such directory listings as "different" and make them non-same-origin with other things using the same protocol, but that likewise makes me uneasy - it feels like just shifting the problem around, and it might break existing users, maybe? A third solution would be accepting the loss of icons and just using generic file/folder icons (or potentially shipping icons for a particular set of files and hardcoding those). Finally, of course, we could decide to do nothing... It feels to me like I'm missing a more trivial solution. Thoughts, Bobby?
I guess as another option, we could make moz-icon inaccessible from ftp but not from file: or chrome:, which would only break the icons on ftp, which I'm less bothered about than file: or chrome: (though I'm not sure how bothered I am even about those, I think other people will feel differently).
(In reply to :Gijs Kruitbosch from comment #5) > I guess as another option, we could make moz-icon inaccessible from ftp but > not from file: or chrome:, which would only break the icons on ftp, which > I'm less bothered about than file: or chrome: (though I'm not sure how > bothered I am even about those, I think other people will feel differently). Yes, this is what I was going to propose - making it file://, resource://, and chrome:// only, which seems like good bang for our buck. Boris, do you think that would be acceptable?
I guess I can live with that, yeah.
Mildly sad as a user at the loss of icons in ftp, which I still do in fact use periodically. I guess ftp directory listings are considered remote web pages, which explains why NoScript breaks sorting on them. But, oh well, I understand it is yet another protocol fading just as fast as gopher. One question though. Firefox *does* support sftp:// and rather nicely too. sftp I would think is used a bit more by devs. Firefox sftp:// also suffers from the NoScript blocking of sorting (although presumably if you can sftp to a site you trust it to run scripts in documents) which makes me think that maybe moz-icon would end up being broken there too? Would you consider adding that protocol to your whitelist? I mean, you're going to auth anyway to an sftp site.
Shame, a few years ago when icon: was being drafted I opened Bug 599904 to track it because I thought it would be *really* useful. There is still a benefit —imo— for being able to show the user an icon they would recognise for a file type.
2 months ago
2 months ago
Arthur, we would like to remove this bug from our MVP. Do you agree? Did the Tor Browser have a fix for this?
We don't yet have a fix for this, unfortunately. But it's a good reminder and I can work on it soon. I opened a tor ticket: https://trac.torproject.org/projects/tor/ticket/23424