Nice! Check out new website and onboarding

Well done so far. I liked the more blueish a bit better, but it is fine to go with.

Onboarding including test account seems to go smoothly. Where to report bugs or feature requests?

Fly-in video player does not seem to work:

In the regular share link it does work:

Question: It seems that for every file uploaded an Access Grant gets created:

This leads to 3 questions:

  1. How can automatic creation of Access Grants prevented, if the user don’t want them to be created?
  2. How can the user check what permissions these Access Grants have been assigned to?
  3. How can user manage/change permissions for these automatic Access Grants?

When entering a bucket, I am requested to enter the passphrase. Even with correct passphrase I get following message and I wonder because the passphrase is correct and of course I have used it before in the browser to upload files. So I don’t know if this message should be displayed here.

Your access grant question should have been a different topic under different category. As of now I think, “site feedback” should be the right place to report any website related bugs.

Last one for now:

When accessing objects, following message gets displayed:

Now if I don’t want server side encryption, where to go? How to skip server side encryption and continue with end-to-end encryption. This is not clear for me.

inside the Ideas & Suggestions category

Weird issue: The website keeps creating new Access Grants for the same file:

I don’t know why there is 2 Access Grants for the same file now.

It is not per file. It happens if you share a file. If you upload and download files without sharing them you would not see additional access grants.

Currently, you just don’t need to click on file sharing. You can also delete all these additional access grants.

There is no screen for file sharing permissions. I assume these access grants have full permissions. They might be restricted to a path but I haven’t checked that so I better assume they are unrestricted for now.

That is not possible at the moment.

Let me answer that question as well and ignore for a moment that the UI could be better on this point.

We offer 3 levels of security:

  1. Generate an access grant with uplink cli. Most secure.
  2. Generate an access grant in the browser but don’t register it on gateway mt. Access grant will not leave your browser but you know your browser could be on a phising site and that where this gets less secure than the cli option.
  3. Access grant registered on gateway-mt. This includes the new file browser. This is now server side encryption. We still offer more security than other compinies but if you care you should better not trust us and use option 1 or 2.

Yes you are right!
The share links confused me because then there is obviously no way to show an already generated link again.

So each time I pressed it to look up the link, it in fact generated a new one.

There is a nother thing confusing me: What is the difference between the download link:
and the share link:

The question I mean is, why should a user generate a share link, if he can (and probably will) easily use the download link and share that one.

The share link is shorter and can be send via email. The long version would also fit into an email but other applications will start to cutoff the url if it gets too long.

I also noticed that the gateway link expires after a while:

Shouldn’t sharing default to read only? Usually you don’t want the receiving end to be able to delete or modify.

Here is something else I have just noticed and I think it is not right:

  1. Go to a file in a bucket with no Access Grants.
  2. Click on Details
  3. In the flyout click the map
  4. Copy map image address (It looks something like:
  5. Change ‘map=1’ from the address to ‘download’
  6. Submit copied and modified URL in browser.

Result: File gets downloaded!!!

How can this be? When I click the ‘Access’ menu there are still no Access Grants shown. So from my understanding the file should not be shared? But it seems that a share link gets created in the background without the user being notified about.

I am a test engeneer. I always expect the worst possible outcome. That would be unrestricted in this case. So yes there might be a difference between what it should do and what it currently does. I haven’t looked into this specific topic and so I stick with the worst possible assumption for the moment.


Operations inside the file browser are handled by that one “Web file browser API key” that you had on your screenshot.

Which means every file in every bucket gets shared by default through this?

That is what the first warning should tell you. This is all server side encrypted. I would not say you share all files but it does come with additional risks that you wouldn’t have with client side encryption.

But from the map URL you can tell that a full link share is in place. I can not tell at what point this gets generated but it is not just displaying the map, it is a share that can be used for download as well. For me that is a bit surprising honestly. Even more as there is no place to look up the permissions that are associated with this/any share.

Look I was just curious, if it would be safe to pass the map URL to a 3rd party or even post it. As it is a nice way to show the decentralization of the storage. But by modifying the link anybody could download the file, so it is not safe at all to pass this link to somebody else if sharing is not intended.