Apps impersonating other apps

Hello,

Have been wondering for a while how to stop apps from impersonating other apps…

As far as I have read it seems as though an app requests permissions from the SAFE Authenticator by providing its name and perhaps a GUID to identify the app, and the user gets prompted to grant permissions based on that name…

When I run the current version - it doesn’t tell me much information about the requesting app… What is to stop another app from using another app’s name and another app’s GUID and requesting access? The user would see a request for permissions that is misleading, and if they grant it then the rogue app would have access to the other app’s data.

Is this a problem? I guess it’s a problem we have today - any app has access to any other app’s data in Windows… but I thought one of SAFE’s stated goals was to avoid this.

Would it be helpful if the SAFE Authenticator were to display the code-sign certificate of the program when it requests access? That might give people more confidence in the integrity of the publisher etc…

Also I think it’d be useful to be able to see a “Details” section showing the specific containers and access types the program would get access to, instead of a high level container permission. Will the current implementation change?

Also are there any plans to allow the user to permit/deny container permissions on an individual basis? e.g. allow read-access to certain folders but deny write-access to others?

9 Likes

Hey @stuzor, sorry had missed this thread!

Most definitely.

It’s one we’re aware of though, and looking at various options. It’s hopefully something we’ll be tackling in an upcoming RFC.

This is an option, certainly. But how could we make best use of this? and what if you have two apps with the same name eg? (does this require a trusted third party?)

How could we make it so the user isn’t just having to compare a certificate on each req for example…

Another similar idea could be tying auth reqs to code via the content xorUrls perhaps. (Which in the perpetual web would not change). Not sure if there’s some other thing to consider there though

I’d certainly like to see this.

7 Likes

Just like we see the Windows smart screen pop up when we go to install software in Windows… I wouldn’t want to rely solely on this certificate, but at least it gives me the best possible assurance that the code running is actually published by the publisher.

I suppose I don’t know enough about it to answer whether or not it’d need to rely on a third party. I suppose Microsoft would be doing that when assessing and categorizing code sign certs - some have EV with a certificate authority, others just standard validation, others are self-signed etc…

My concern is that I install program X, and then the next time program X runs it claims that it’s actually program Y, supposedly released by a different company, and requesting data that it shouldn’t have access to.

Maybe publishers/developers could create a profile and publish their public-key, and publically associate themselves with the products they’re releasing… so at least the users can see that the App requesting permission is signed with the correct key associated with the website from where they got it…

Great. Just like Android apps let you pick and choose what permissions apps need, and also as-needed.

1 Like

Publishing the public key on safe where it can be verified by the authenticator and only altered by the creator :thinking:

If linking with a Web id and connecting to it in your address book with tag ‘program name’ that would enable the authenticator to verify if the source is valid and didn’t change :thinking:

2 Likes