Attack Vector: App Updates?


#1

As I’m making apps, I keep testing through SAFE each time (since I can’t get the dang polyfill to work for the life of me @happybeing @joshuef), but I’ve noticed that if I authorize my web app, then I can make updates to it which go into effect upon refreshing the page, without having to authorize again.

An obvious attack is making an app that is just fine, then getting lots of users, and then adding a secret update that steals everyone’s safecoins automatically.

I hope that there will be some type of regular app hash check or something that notifies users that an update to the app has been made, and gives them the chance to accept or deny it.

Although maybe the team is already fixing this with the new authenticator paradigm coming out soon


#2

Every update needs to be treated as completely new code, there’s no question about that.

With that out of the way, I still think the whole authorization thing (together with a lot of other things on the network; we’ll need it!) will have to be supported by a generic “web of trust” kind of system, where people can pick trusted parties to whom they can delegate these checks:

If both TesterJoe and JimmyTheNerdest says this app (with hash fff420) really is SafeWallet 2.17.1, and they think it’s okay to give it access to my wallet, then I trust it is so.

This is both less bothersome and more secure than if I was always asked, and then had to do my own little investigation (which, let’s face it, most of us would not do after the first few times.)


#3

definitely agree, and hope that is one of the many harmoniously coexisting options that the free people of SAFE are allowed to choose from in the future :smiley:


#4

Safe is the ultimate phising and malware distribution platform for the same reasons that make it the ultimate privacy and content distribution platform. We’ll need to come up with ways to mitigate the nasty side of this equation, and that goes beyond just app installs or updates.

Trust is a social concept, so it can’t be solved (only helped) by means of technology; we’ll need to utilize relationships between actual humans. We won’t be able to live without one or more generic frameworks that express and work with trust between people, but probably also with “trust in trust” (“I trust that whom you trust is trustworthy.”)


Is censorship always bad?
#5

I’m curious how @Seneca’s work might come in at this interface. I know that he was building out those exact tools of WoT as part of the Decorum project.

What say, Harmen?


#6

I am refloating this thread because of an existing vectors in the clearnet, these type of side-channel attacks would in principle be exploitable on the safe browser:

The campaigns on these vectors are currently quite massive
This topic should be discussed, as the current problems of the existing app markets probably will be the same or maybe even worse on a completely anonymous app marketplace.

The main problem here is that we still leave the last decision to the user, by asking them if they allow certain permissions to their apps, and users either don’t give a crap or don’t have the knowledge to make an informed decision, so they default to pressing yes to everything.

How can we protect the users from themselves?


Web Apps and access control
#7

One way is to request permissions only when sharing data, rather than before allowing access. I think this is worth exploring because it can avoid the need for apps to have any restriction on access, so no permissions requests needed until exposing data. This abandons the Android app permissions model in favour of something more like a firewall - perhaps only one app is a ‘sharing / publishing’ app, which others invoke when sharing, or which the user can use directly to publish files, folders etc.

With this in place there’s an incentive for apps not to expose data unless necessary because asking permission unnecessarily will annoy the user and make the app less attractive. Many apps will be able to avoid asking permissions altogether, because they can do their work without exposing user data. This is a good thing!

We can then imagine that most apps will be just data analysis and mashing, and that a different app will be activated when the user wants to publish or share data.

This app could work like a firewall that prompts when needed, but can also have rules set, with suitable defaults depending on the data, such as MIME types, and for RDF the kinds of ontology it uses, even the semantic properties it contains, how much data is involved, which folder it is stored in etc. So the firewall might be relaxed about blog comments, cautious about spreadsheets, and strict about wallets and money, diaries etc.

I just invented the semantic firewall! :wink:

We had some discussion on this which established that it is feasible if implemented at the network level, but we have not yet discussed ways of making a good UX.

I think this is worth trying, because it could address the issues raised above by @piluso, and be generally more secure, avoiding the need for most apps to have any permissions settings at all - so long as all they do is read user or public data, and write data to the user’s storage.

Here’s the original post with discussion on implementation, but so far not on UX patterns:


Web Apps and access control