Streaming live at 10am (PST)

Final Deletion of a File in the Asset Manager

#1

Hey guys,

you really need to fix this: If I delete a file in the asset manager it is still available under it’s old URL.
So this means: I can’t really delete a file from the asset manager, you still have it saved, right?
I’m sorry but if I delete something I want it to be gone, especially when it’s still available for Google in this case and this shouldn’t be – it should be gone.

Same occurred to me when I was duplicating a project:
When I downloaded the HTML file of the website, even if I had deleted the assets and not used it in the project – the files were still in the same image folder. I haven’t checked this and accidentally sent confidential data to the wrong client. Please fix this!

Thanks a lot for your great service in every other aspect.
David

#2

Havent noticed this behavior myself - but maybe it is a cache thing in your browser?
Do you happen to have an old link, so I can test it from here. :+1:

#3

Hi @davidk77

When you delete assets they are removed from your project, but not entirely removed from our servers. They aren’t permanently removed just in case you need to restore to a backup version of your project — you’d be able to get those assets back. If we didn’t keep them, there’d be no way to have them on previous backup versions.

If you need assets permanently removed from our servers, you can always contact us directly and we’d be happy to help.

Regarding the export issue — if an asset is still being used on the canvas somewhere it will be included in export. I’d recommend checking to ensure you aren’t still using the asset anywhere on the canvas to be sure. And as @new_work_city, it may also be due a browser cache error. Would you be able to clear cache and test in incognito mode after confirming there is no reference to this asset on the canvas?

#4

@Brando Clear explanation, but it raises the question how long exactly the files are ‘saved’ before they are permanently deleted then.

#5

We also deal with time-dependent business files and did not realize this was an issue. Why not add a simple “Remove from site” or “Delete Permanently” popup option? That would be strongly preferred over the current behavior. I can’t think of many examples when a site owner would consciously want to delete a downloadable file yet still leave it on the server available to google going forwards?

#6

Thanks for the explanation. This is definitely logical. But yeah, gonna remember to never use my nude photos as a placeholder items anymore, haha!

3 Likes
#7

@Brando shouldn’t any asset stored for historical backup purposes be securely stored within a non-publicly accessible bucket within Webflow’s AWS environment rather than remain on the public server? The current method could lead to all types of security concerns and undesired problems:

  • Outdated pricing charts and information being accessible through google
  • Old versions of corporate contracts remaining publicly accessible and bot searchable
  • Unlicensed images included in webflow templates or used during site design stages still being associated with a client against the policy of stock warehouses.

Really seems to me a permanently delete option should exist here, and items that aren’t should be stored behind the wall.

3 Likes
#8

@Mike, I totally agree. This should be managed more securely. Didn’t even realize that all these kinds of problems could arrise. I sometimes completely rebuilding websites just for practice, would that cause an issue?

#9

Let’s make something on the wishlist for this? The Most easy solution would Be: Delete – vs. Delete Permanently @Brando ?

1 Like
#10

Hi @Mike @VladyRahn

Great points — thanks so much for sharing your thoughts on this. I can definitely see the benefit of having these delete options.

Agreed with you @davidk77 that a wishlist item is a great next step. I’m also happy to pass along the Wishlist item once it’s created to our product managers and backend team to get the conversation started internally :slight_smile:

1 Like
#11

Hi Brando,

Thank you very much for your reply. I sincerely appreciate your investigation of the issue. Once again though however, it deeply saddens me that Webflow’s policy has gone much too far down the path of addressing security concerns with wishlist request items. I can’t overstate enough that I don’t think this is right and believe you guys need to start taking security much more seriously before it bites the company or your users.

There are probably a whole world of ex-wordpress users in webflows subscription base that have absolutely no idea the hosting behaves in this manner and will never discover this forum thread or the wishlist item.

I stand by my opinion Webflow needs to conduct a real 3rd party audit and either act on items of concern immediately, or share the unaddressed results openly, through an email and dedicated security page with its users. Each time these issues come up I’m more afraid of what’s still left lurking unpublicized and how many things I haven’t stumbled upon in my infrequent visits to the forum.

I don’t expect it to get 1,000 votes anytime soon, but here’s the request (I’d already created it as I presumed this would be the response). Please get this resolved and communicated with your users. Thank you again for taking the time.

https://wishlist.webflow.com/ideas/WEBFLOW-I-1757

1 Like
#12

To be honest wishlist is not an ideal solution for really important things. It is just a popularity contest - the amount of wishlist items is too damn high (with 128 pages to browse through) to hope that this one will be noticed by someone without trying to “advertise it” somehow which is plain silly.

I agree that WF will have to tackle security problems like this and GDPR more seriously soon.

1 Like
#13

I 100% agree with Mike, sooner or later some ones popular or unpopular imagine (or even worse file) will get missused and someone will have to pay for it. Especially now when we have cross side copy and paste…

1 Like
closed #14

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.