Solved URL Shortcut dragged to desktop is blocked by default
-
@pathduck A little more on this... I just tried using Edge to download a file and it retained the ADS stream for that file, too. Everything in my user/downloads directory shows the same ADS file.
Yet, a shortcut dragged from Edge to the Desktop does not do this, nor the other browsers I tried earlier. So, does that mean there is a difference between the download process of Vivaldi versus the others depending on whether it's a "normal" download or a dragged download?
-
@joeduffus Hmm, good question. I wonder if the Downloads directory has some special settings, possibly causing all files ending up there to get the Zone data?
I just tried here with a test folder, and files dragged there do no inherit the data from the folder.
If you do a
dir /r
of your Downloads folder does it show any data entries for the.
(folder itself) entry?So, does that mean there is a difference between the download process of Vivaldi versus the others depending on whether it's a "normal" download or a dragged download?
I don't think you can create .url files from a regular download, it has to be a drag operation. I guess you could always test with a regular download and see if the same data is applied, depending on whether the file is saved to Desktop or Downloads maybe.
Would be interesting if others can reproduce this, I'm assuming @iAN-CooG has seen this before since the script file was made at some point.
-
I don't see any entries for the . or .. <DIR> entries. Only for the files within the directory, all downloaded from the internet.
It must be related to Vivaldi's handling of the drag operation then. Agreed?
-
@joeduffus said in URL Shortcut dragged to desktop is blocked by default:
It must be related to Vivaldi's handling of the drag operation then. Agreed?
If all the files in Downloads have the data, and assuming you don't drag downloads there, then it seems more like files saved by Vivaldi in general and not just for .url files.
I was starting to wonder about your Webroot as well, could be worth an investigation. Maybe other browsers are "whitelisted" or "excluded" while Vivaldi is not, so it marks all files saved to disk by it is marked as "insecure"?
-
I thought about that too and shutdown Webroot before a drag operation. No difference.
-
@Pathduck Here's something. From a webpage I just tried dragging an image file to the desktop, then right-clicking and choosing save Image As.
It created different files, but only the one dragged from the page to the desktop had an ADS file. -
@joeduffus And does that also happen with other browsers? Also if you drag to the Downloads folder?
Something is really strange on your system, and apparently no-one else is seeing this so far... I have no idea what it could be at this point.
Did you check the GPedit stuff I asked about? Just start searching for
gpedit
and you will find it. -
My machine is Win10 Home edition, so there's no gpedit.msc.
-
Just thought I should report on this thread that with today's Snapshot release (5.4.2718.3 (Official Build) (64-bit) ) I can drag a shortcut to the Windows desktop from a Private Window and it will then open with NO security warning!
However, doing the same thing from a normal window still brings me to the same Windows security warning as I'm used to.
I count this as progress!
I guess.
-
@joeduffus Nope, I don't believe that there has been any progress in this area. 5.3.2679.58 (current "stable" releasse) behaves the same way: a .url file created from a normal window includes an ADS of "Zone.Identifier", while a .url file created from a private window does not.
Check it yourself with PowerShell:
get-item *.url -stream * | ft filename,stream
-
@rr2squared Thanks for confirming that on the Stable channel. I tend to stay on the Snapshot channel just cuz I'm a "breaking news" kinda guy
So, if a Private window is not copying the zone.Identifier info, but a normal window is, why would that be? Any ideas?
-
@joeduffus Hi,
I think I might've stumbled upon something, possibly a solution to this mystery. I've had to do a repair install of my Win10 machine, and after setting it up, I started getting the same warnings, that I never saw on the old install.And as expected, the EXE file had the
Zone.Identifier
data. Tried the same with a URL dragged from the browser, same thing. Then tested in other browsers, and EXE files did haveZone.Identifier
. But URL files did not, so that's really strange for sure, only Vivaldi had this.I've always suspected Defender SmartScreen on this, but I always disable it first thing, because I use Avast (and SmartScreen is pretty st00pid...)
But since the warning you get looks like "old Windows" like Win7, I've also suspected the old IE Internet Options in some way. IE is still very much a part of Win10, just hidden. So I started digging there, and found this setting:
Setting that to Enable, you will get Security warnings, and a notification to reset your settings to default. These warnings might come again, so you might have to turn off notifications from Win Security.
But with that set, EXE and URL files no longer contain
Zone.Identifier
and you no longer get warnings when trying to launch files even if they have it. Note also that the warnings only applies to files considered "Unsafe", i.e. EXE files from unknown publishers, and I guess URL files are considered "unsafe" no matter what. If the EXE is signed by a publisher, there is no warning even with the setting to "Prompt", but theZone.Identifier
is still added to the file.Since it would be strange if this behaviour was standard in Windows, so I suspect that using a 3rd-party AV and disabling Defender causes this in some way. That setting should not matter at all, it's just a remnant from older Win versions, but possibly Defender SmartScreen uses it, and if disabled, it falls back to the old Internet Options-based security setting.
So, that's a solution for me at least. And a confirm on the
Zone.Identifier
thing for URL files from Vivaldi.Still no idea why Vivaldi actually saves
Zone.Identifier
data, so that's probably a strange bug that seems to affect very few users, possibly with 3rd-party AV and possibly SmartScreen disabled. Does that apply to you? -
@Pathduck That's a good thought. I recently switched AV software, from Webroot to BitDefender, but Windows Defender was always disabled.
The maddening aspect of this is that only Vivaldi does this, not Brave, Chrome, or Edge. And, as I mentioned above, a shortcut link dragged to the Windows desktop from a Private window in Vivaldi does not have this issue either.
-
Some more investigation:
With Defender SmartScreen set to On and the IE Option set back to default "Prompt" - there is no warning when opening EXE, only standard yellow UAC prompt for unsigned files. But URL files still give the warning, I guess URL files with
Zone.Identifier
set to 3 (Internet) are considered really insecure...I think in my old install I had done so much tweaking over the years, that I was unable to reproduce Vivaldi creating
Zone.Identifier
data in URL files. And I rarely use URL files anyway.And, as I mentioned above, a shortcut link dragged to the Windows desktop from a Private window in Vivaldi does not have this issue either.
I have no theory about that. I tested and it did create the zone identifier data also in from a private window.
Did you test my solution?
EDIT: To be clear - IF a URL file already has a
Zone.Identifier
it will still warn. But the "Enabled (Not Secure)" setting will stop it from being created in new ones. -
@Pathduck Thought I should report something new:
In Snapshot 5.4.2763.3 (Official Build) (64-bit) I have noticed a change.
A dragged shortcut from Vivaldi to the desktop now saves as a file named "url.pro" with no Windows file association.
When I try to open this file using Vivaldi.exe (found in my AppData\Local\Vivaldi\Application folder) it merely outputs the contents of that text file to a browser tab.
So, something has changed. I tried changing the extension of the url.pro file to url.url and it behaves as before, throwing up the usual security warning.
Perhaps we're in the midst of an experiment?
-
@joeduffus Good find.
In my case the fiel name says:url.txt
.Please report bug to Vivaldi tracker and leave VB-xxxx bugnumber rof report here.
-
@DoctorG VB-91068
-
@joeduffus I just confirmed it.
-
This bug is now fixed in Vivaldi 5.6.
-
Ppafflick marked this topic as a question on
-
Ppafflick has marked this topic as solved on