Forum Discussion
How the new Edge will handle file:// URI ?
This is also the most important feature for our company's intranet ! In the past, we used IE as our main browser. Now, we use Firefox with an extension, but we still have some issue when the file link is inside an iframe. In the futur, we plan to use the new Edge browser if the file link are supported.
Many users see a security problem with file link, but this can easily mitigate with options like "open only non-applicative files" or "open only files from theses secures servers : ___", etc.
We've just started the first round of internal testing and this was one of the first issues pointed out.
We have a lot of file:// links to our central fileserver on our intranet website and not having them work at all is a big problem.
I've worked around the issue for now by adding our intranet server to the Enterprise Sitelist and having Edge render the website in IE Mode. That way the file:// links are working again. But this should definitely not "become a thing".
A whitelist of sorts would be nice. File:// links to any server/location listed on that whitelist would work, while all other file:// links would behave like usual - not do anything. That would be nice. It would allow us to whitelist our central fileserver while keeping "security high".
I've also opened a case about this, lets see if it leads somewhere.
- narutards- You have mentioned that you have logged a case for this issue. Have you received any response from Microsoft? If yes, could you please share?
SoumyaRaju - See the full resolution of the case below:
Cause:
The deprecation of file:// protocol links in Edge is by design. It has been inherited from the Chromium project and it is an expected behaviour that file protocol links are not open in Edge, for security reasons. There are other implementations that also allow the sharing and access of files without resorting to the File protocol, which has security risks associated with it: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftextslashplain.com%2F2019%2F10%2F09%2Fnavigating-to-file-urls%2F&data=02%7C01%7Cdamatos%40microsoft.com%7C7fd6364cc7254cd987d208d7ec483d88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637237667351409534&sdata=JA%2Bj4%2FOGMbYmyMmJZawxXoLKNXyzi5aZLrvURLaSkBw%3D&reserved=0.The lack of a warning or error message from Edge to the user when such a navigation is blocked has been acknowledged as a bad user experience which can lead to confusion and misunderstanding of this as an expected behaviour. As such, it has been flagged a bug that should be fixed in the future.
Resolution:
The short-term solution is to render the affected page in IEMode, where the issue does not occur. The longer term solution is to replace the URLs on the page or fully replace the page with Sharepoint, given that it is particularly geared towards this type of implementation.
JeffOwens My contact got back to me with an update on the issue by now. They are not going to implement anything that will make file:// links work again besides what already exists - IEMode.
But I told them that I'd like them to at least implement something that tells the user why/that file:// links aren't working. Currently Edge simply does nothing when you click a file:// link. They seemed kind of receptive to my idea to at least show an error/warning MsgBox or something along those lines when a user clicks on such a link. No idea when they are going to add that though .. if they are.
JeffOwens I just got an update yesterday. They are goig to raise awareness about this issue with the product team soon-ish. Whether or not they will implement anything in regards to this issue is unclear at this point though.
For now the suggestion seems to be to either change all your links, use IE or configure Edge so that it uses IEMode for the entire website you have your file:// links on.
Thanks narutards
For anyone else interested, we changed all our file:// link references to localfile:// and implemented a new protocol handler in the registry.
For example:
localfile://open?data=\\NASORL1\EngData\MAVIS\ProjectTickets\13092\Engineering-Data\Prototype\
Since this issue only applies to our intranet web application that we've developed internally, it was an easy thing to deploy (you might be able to do it via group policy if you're running AD or via an easy EXE to make those if not).
Also, since this is a registry edit, the protocol will be recognized on any browser.
That's our work-around for now.
