Apps impersonating other apps

Development
1

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?

10 Likes
2

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
3

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.

2 Likes
4

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
5

Been thinking about this lately from a slightly different point of view to the OP, but thought I’d post some thoughts here because it seems similar enough.

I know a lot of people have mentioned SAFE being a suitable platform for a communal, distributed gathering of information. That’s perhaps just a description of the basics of the network, but I’m thinking a little bit more specifically here, for example a public Appendable Data object that people can add to.

However, as things stand, this sort of arrangement would be very open to spam, because for it to work, the Appendable Data object would have to be open to everyone, or the contributions would have to be funnelled through a single account that was somehow vetting all the contributions, which would defeat the purpose on all kinds of levels.

One way I think could work to aid this type of workflow would be for an Appendable Data to have the ability to only allow contributions from a certain, certified app (that could be authorised and run by any account.) This would at the very least force the data submitted to be in a certain format, limiting the amount of damage a spammer could do, or putting a minimum price on it. If the app was in fact an autonomous app that was just set in motion by the contributor, then this could eliminate the possibility of spam altogether.

The example I’m thinking of is creating a decentralised index of sites on the SAFE Network. The way I’m imagining it would work would be for there to be an app, let’s call it “Indexer” that (for example) the creator of a website puts in motion to scrape their site, and deposit the resulting data in the index. Thus both computing and payment for the entry are decentralised, and website creators have an easy way to add their site to the index, without worrying too much about SEO.

The index would be held on Appendable Data objects, the permissions of which would of course have to be open to anyone, so as things stand, anyone could write their own programme to meddle with the Index.

However, if the logic of the AD could ask for proof that the attempt to edit it came from the official certified “Indexer” app, then we can ensure that all data deposited is data returned from scraping a SAFE site, and therefore something that we want to have in the index.

Is this something that has been thought about as a useful feature for the network? Does anyone have any good ideas about if and how it could work in practice?

(Or am I just looking at things all tangled up again?!)

4 Likes
6

Good exploration David. I’ve not thought much about this, but when I have is always puzzled me and I’m not alone!

They’ve had similar conversations about a related use case in the Solid forum: how to handle social actions such as ‘liking’ a post on somebody else’s pod. The architecture is different but the problem is the same I think, or at least very similar. One answer is for the information to be stored in data owned by the person generating the like, but that a notification is sent to the owner of the thing being liked. Your use case is different, but a notification solution probably exists for it.

This is of course complicated by the fact we don’t have notifications yet, or much idea of how that will work!

2 Likes
7

So in my use case you would be thinking along the lines of:

1 - The app scrapes the site (or whatever)

2 - stores the information in the owner’s account

3 - sends a notification to the index of all that information

I’ve thought along those lines, but if I’m understanding you right, that has the disadvantage of duplicating the data possibly needlessly, and doesn’t really solve the permissions problem - the index AD is still open for a rogue app to write whatever it wants to it.

I was more thinking along the lines of the AD requiring a password that is set by the writer of the app (who is the same person that sets up the AD,) and the official app being the only thing that knows this password, though it would have to be encrypted in some way of course. Seems kind of simplistic though.

3 Likes
8

I’m not sure duplication will be a problem, but maybe.

I’d be thinking more in terms of speed when the index grows in size, but I have a hunch that you could design this in a way that scales well even if the information that is indexed is not all in one AD.

Instead you would need to know how to search the index for the best matches known so far. I’m not sure how, but maybe you could construct an index based in part on hashes of search terms, with references added ad hoc to different AD owned by different people, more like a web of knowledge than say a tree.

That’s all very hand wavey sorry, and there may be nothing in it. But that’s how I’d start thinking about creating an index - to see if there are any solutions that fit within the constraints we have.

2 Likes
9

Yeah, was thinking of this certainly in the context of an index held on multiple ADs, potentially quite a sophisticated and efficient database, (ie. potentially millions of ADs) though I don’t actually know anything about how to design that…

What I can’t get past though is that either there is a centralised point of ‘truth’ (controlled by one account with permissions to write the data) which as much as anything creates a computing bottleneck and a financial issue, or it is decentralised, in which case it is based on trust and therefore open to abuse.

My current implementation is based on trust, but I have a manual ability to ‘verify’ or ‘hide’ an entry which is not available on the normal dashboard, though even that can be easily enough overridden by someone writing their own app and connecting it to the AD. The fact that it’s all manual (including data input) obviously makes it unsustainable too.

As I say, I think the above idea of a particular app being able to have permissions on an AD, in the same way that a particular account does, could open up a lot of possibilities for collaborative, decentralised working. I’m just not sure how workable it is in terms of securely verifying that the data submitted comes from a particular app.

10

What if each person keeps both their own index, and an index of other indexes it knows about, and a measure of trust for each.

An app can hop from one person’s index to the next based on how much you trust them and how much they trust each index they know about.

If we all put a little effort into marking indexes as helpful or unhelpful, we crowdsource a web of trust/indexes. Hope about that?

I think this may be something similar to what project decorum is doing.

2 Likes
11

Quite a long time ago I suggested that an app has a token stored in the meta data (with the PtD address) and the node/section can validate a request from the APP to write to an AD that it owns. For this when the APP writes to an AD it owns then there is checking to ensure its valid.

The key for writing to an AD it owns could be hacked out of an APP so there has to be knowledge kept by the network that the APP running does not have in its code.

But It has always been played down because its the wrong way to think about distributed data.

Another aspect is that SPAM is always possible for public data no matter who owns it. And the spammer could write their own ADs. It will cost the spammer and thus there is some limit.

1 Like
12

This is the kind of thing I was thinking about - as you say, in some way needs to utilise knowledge stored by the network so a key can’t just be hacked out of the code (I don’t know much about it, but I do know iloks exist for a reason!)

In what sense wrong?

I think I maybe see what you mean - in an ideal world perhaps everyone would scrape their website, keep the results in a pod that they then made public to be searched? As I’m seeing it, this would be unworkable for an index in terms of efficiency - on some level, when I search for ‘apple’ I need to go straight to the place where all the records of pages containing ‘apple’ are, instead of looking through every page (or even a concise version of every page.)

I think a couple of people including Josh had this sort of thing in mind when I was discussing it on my search app thread. It’s maybe the way to go, and perhaps a more correct way to look at the problem in terms of what Neo was saying, but I’m not quite at a stage where I can see how it would work in practice, for this use case at least. I’ll see if I can explore this sort of idea further though.

3 Likes
13

Thanks for the replies, @happybeing and @neo it’s certainly a tricky problem, even to find a half solution, which is all I’m after just at the moment to be honest - enough to make it feel worthwhile for myself and others to build other apps. Not much use if no one can find them!

From a UX point of view there are already so many things to balance in terms of quality/comprehensive/fast results that I think keeping it genuinely decentralised might require compromises in UX that are too big for people’s expectations.

Conceptually at least, I felt my original suggestion was a reasonable blend of compromises to generate an efficiently organised index that was collaboratively computed and paid for, and could be open to apps to search in whatever way they felt best. As a tool, the ability of an app to have a secure signature would also be really useful I think.

One thing I’m quite wary of is who is being expected to pay. I feel it’s no accident that advertising is what pays for so much of the internet - it is producers who have most incentive to be found. Asking consumers to compile indexes on anything like the scale necessary would be a hard sell I think.

The idea of community based network traversal is really interesting though, and maybe could radically change the way we interact with the web in a positive way. On the other hand maybe it would just entrench our divisions within bubbles.

It was actually the computational network thread that got me really thinking about this, and maybe that could ultimately be the answer. Just ask the network itself to index your site, and pay the cost of the resulting data. Arguably that would be centralised in a sense, but for me that would be an acceptable level, necessary for people to actually find what they want.

I don’t know, it’s such a simple thing in a way, but so quickly you run up against both practical and philosophical problems. I’ll at least keep trying to see if there’s an easy temporary halfway house though!

1 Like
14

One of the ways to solve the issues like who creates the index is for each of us to share our learning in the most effort free way possible.

For example, how many of us have collected bookmarks of sites which interest us? I’m guessing everyone.

Generally those are going to be sites we found value in, so if those indexes were public they could all be used to contribute an opinion towards an index with a quality measure for each site (eg number of times it was bookmarked).

From there you could also get a second level usefulness for stores linked to by those sites (a bit like Google’s original ‘page rank’ algorithm), and as users we’ve had to do zero extra work. Although I can imagine identifying this process with micropayments rewards for higher quality indexing, and other techniques.

That leaves other issues unsolved. My point is that there may be original solutions to the problems we create by thinking in the old centralised ways.

2 Likes
15

Thats the sort of thing I was thinking of when I was talking about who pays. If I’ve gone to the trouble of making a website, I’d be happy for a bit extra time and effort to add it to an index. As you say, bookmarks is a nice easy way of getting a quality rating.

2 Likes
16

If you look specifically to search indexing which you seemed to use above as an example.

My suggestion elsewhere was to have the user creating their site to use a standard (for ease) APP that spiders their site (or anyone) creating the indexing for the site. This would follow the pattern (protocol) for the data, then something like

An entry is made to the register of site indexing (set of ADs) for an APP you run that updates the master index with an appropriate set of pointers to the site.

Your income is the PayTheDev reward for them 1st using your indexing APP and secondly others using your APP for the searching.

If the pattern/protocol is developed properly then it could even become a standard and various search algos could be built by different people allow multiple differing APPs use the same underlying dataset, but apply their flavour for searching/categorisation

Who pays?

  • The major part of the indexing and machine time is done by the site owner themselves in creating ADs that index their site according to the various categories and terms usage.
    • the site owner can rerun this anytime they feel a better way to spider their site would work better. This implies that the spider APP has parameters. For example “educational site” and other tags the owner wants to specifically indexed
  • The smaller secondary cost is the APP owner to build the master indexing

By doing this then SPAM only causes a minor increase in the APP owners processing to skip those spam entries in the register. Yes it may be a pain but it is minor compared to other ways where the spammer can spam all the search ADs that users need to search through. Site owners can only affect their own ADs, so if they spam those then it only affects their site or removes them from the master indexes.

2 Likes
17

This sounds pretty similar to my original idea, I think the difference is that I was thinking the person running the spider app would directly be writing to the master index, which was where my security concern came in.

2 Likes