Solved URL Shortcut dragged to desktop is blocked by default

[Pathduck]

@joeduffus

It shows with a LF character at the end of the first line and nothing after the end of the URL on the second line.

I think this shows that whether the file uses CRLF or LF line endings is not the problem. The problem is Vivaldi for some reason inserting NTFS Alternate Data Stream data into the file. While other browsers do not... ?

A little more investigation into ADS, 'cause once I get started...

You can use dir /r to find if a file contains ADS:

04.06.2022  00:37               114 test2.url
                                 26 test2.url:Zone.Identifier:$DATA

I was able to recreate the same by adding Zone.Identifier data to the file in Powershell:

> Set-Content -Path .\test2.url -Stream Zone.Identifier -Value '[ZoneTransfer]','ZoneId=3'

> Get-Content -Path .\test2.url -stream Zone.Identifier
[ZoneTransfer]
ZoneId=3

ZoneId=3 means the "Internet" security zone and marks the file as "downloaded" and "insecure".
Source: https://superuser.com/questions/1342990/how-can-i-make-windows-think-a-file-came-from-another-computer

But again, none of my browsers here insert ADS data into url files, and no idea why only Vivaldi on your system seems to do it. If controlled by GPO it should be all browsers doing this.

[joeduffus]

@Pathduck said in URL Shortcut dragged to desktop is blocked by default:

But again, none of my browsers here insert ADS data into url files, and no idea why only Vivaldi on your system seems to do it. If controlled by GPO it should be all browsers doing this.

And that's why I've concluded it's a Vivaldi issue, rather than a Windows security setting Vivaldi is simply a victim of. I have Chrome, Edge, Edge (DEV), and Brave installed on the same machine and none of them has this problem with a dragged shortcut file.

[Pathduck]

@joeduffus Are you able to check if url files saved from other browsers contain ADS data? Using the dir /r or PS Get-Content examples I posted?

Also, are you able to check in GPEdit:
User Configuration > Administrative Templates > Windows Components > Attachment Manager
What the "Do not preserve zone information in file attachments" policy is set to?

Mine is set "Not Configured" which should mean the default is to not save zone info in downloads.

[joeduffus]

@Pathduck I created the shortcuts from Chrome, Edge(DEV), Brave, and Vivaldi, then copied them into a new folder on my desktop and ran the dir /r command.

[Pathduck]

@joeduffus OK so Vivaldi is the only one saving url files with ADS data. Really strange.

Have you set any Group Policies for Vivaldi? In Regedit, check:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies

If you open chrome://settings do you see a heading of "Your browser is managed by your organization"?

PS you know win CMD is just plain text right, you don't need to make an image, you can just copy the relevant text output and paste it

[joeduffus]

@Pathduck

1. Checked registry, and no, there's no entry for Vivaldi.
2. No. I do see that in Edge, but not Vivaldi. I think it relates to my anti-virus software (Webroot).
3. Yeah, I know, but pasting screen screen snips is more eye-catching.

[joeduffus]

@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?

[Pathduck]

@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.

[joeduffus]

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?

[Pathduck]

@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"?

[joeduffus]

I thought about that too and shutdown Webroot before a drag operation. No difference.

[joeduffus]

@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.

[Pathduck]

@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.

[joeduffus]

My machine is Win10 Home edition, so there's no gpedit.msc.

[joeduffus]

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.

[rr2squared]

@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

[joeduffus]

@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?

[Pathduck]

@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 have Zone.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 the Zone.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?

[joeduffus]

@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.

[Pathduck]

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.