ah ok, I’m sorry I misunderstood that, but then why would you route reqs trough such app if it’s not to be able to intervene, then such app is doing the same OP proposes the network (vault/client-handler) to do (but just enforcing the user to be online)?
For constrained environment where it isn’t possible to run an authenticator in parallel to validate macaroons and sign requests, there is still the possibility to give the application its own direct credentials to the network.
Well, this is possible in theory, but how easy is it in practice? For example, is it possible to develop an application using the ffi but without an authenticator? I mean, connected directly to the network with its own credentials but still benefiting from high level functions provided by ffi.
-
Absolute security when user is offline
-
Possibility to visualize the application usage of resources like rate of requests and just a big red button to stop everything immediately if something looks suddenly suspicious (with a simple caveat that controls the state of this button)
-
Programmatic control thanks to the richer set of caveats provided by macaroons. An unlimited set is possible because caveats can be programmed in an ad hoc way client side (I mean not programmed in core). I already mentioned several possibilities, but I would like to mention another one: the application could be provided a safekey with safecoins, the authenticator could refill it periodically, and a caveat could be defined that validates the rate at which the application consumes its balance.
3 Likes
I see what you are imagining now, sounds good, but I’d say that’s just an app to be created and separate from main/core logic, in fact such gateway app can just be authorised by the authenticator once, as any other app, and do all that with macaroon attenuations and so on.
3 Likes
Hi all, happy new year!
Apologies for the slight digression, just got a question about specific use cases rather than technicalities of implementation, but keen to ask it as it affects my immediate next steps!
If I’m following right, this proposal allows Data to be permissioned according to the app that is reading/writing/editing it, rather than the account. Therefore, we have the possibility of communally owned and edited Data objects which can be fairly strictly regulated by the inherent limitations of the permissioned app.
If this is case, I think that particular use case would be hugely useful for a lot of ideas for apps that I’ve had, and it in effect enables a form of decentralised computing.
As an example, without wishing to hijack the thread, referring to the earlier conversation we had about a search app @joshuef, it would potentially enable a single set of search index ADs to be communally owned and updated, which I think would tick all the boxes for both efficiency and decentralisation.
Would this seem to be a correct understanding?
2 Likes
Happy new year @david-beinn!
Right. A label is made per-app. That can be applied at a specific permission level to data.
The permissions on the data don’t have to be tied to an app. You can just make a label communal-data and apply that to the data you want to share, at the permission level you want to allow. Then share the token/LabelKeyShare (however that ends up working, that part is most in flux, but definitely possible, however the impl), among those you want to grant access.
I think so yeh! 
1 Like
Thanks Josh, that’s great news. I’ll post an update over on the search app thread later in the week cos I think it makes a lot of useful things possible in that respect. In fact I think this whole labels thing makes a lot of great things possible full stop, and all in one fell swoop!
Just to be clear, I was suggesting that having the permissions tied to an app was actually what I was looking for. If the identity and security of an app can be verified, then we can trust anyone to run that app to write to a piece of data, because the nature of the app will be such that they can’t just add spam, or meddle with the data in a destructive way, or whatever. Therefore we open the door for everyone to contribute to the sum of knowledge etc etc.
1 Like
Aha. That’s probably getting into tying permissions to versions of data. Which is something that should be possible in certain environments (eg the browser). We just haven’t got anything nailed down there yet
1 Like
Hmmm. That wasn’t necessarily my first thought as being a problem, but maybe it’s a good example of what I was thinking of.
Say it’s written into the logic of the app that it always writes to the latest version of a piece of data. My worry would be whether it’s easy for someone to somehow circumvent or change that logic, whilst still using the app’s security credentials. Does that make sense? Would the macaroons idea take care of that? Would the potential for malice be easier to control in a web app?
The idea above could tie tokens to an app’s running version eg. But that’s only as secure as the environment it runs in. Generally, you’d want to make your app resilient against bad/corrupt data always, as there’s no guarantee, if folk really want to extract a token from a valid app, it’s probbably going to be possible.
As far as ‘always write to the latest version’, well that would be a form of appendable / sequenced data, which will prevent any writes to earlier versions of data for you. And that is guaranteed.
1 Like
Yeah, that’s what I was figuring.
I think it should be good enough to proceed for now though along the lines I was thinking of (I mean good enough for the medium term - I’m aware it’s not even built yet!)
Perhaps the time restriction/tokens expiring would also help quite a lot in making the system more difficult to extract tokens from.
Just now I was thinking along the lines of web apps anyway, but would the browser be considered a relatively secure environment (subject to the js running within it being secure?)
Ufff, yes. And no. Nothing stopping someone building it themselves. Secure for a person yeh, if they download an official version. Secure in terms of data put via the browser to the network can be guaranteed… Less.
I think out apps will have to work with the idea of spam at some point. If you’re enabling anyone to write, I’d wager we’ll see some nonsense. Hopefully with there being a cost associated with that, such spam will be minimal…
We’re probably getting reasonably off-topic here, @david-beinn, so perhaps we should make a thread for this?
1 Like
Yeah, no worries, sorry, just wanted to explore what the labels idea could enable.
Certainly really helpful for me to realise the possibilities and limitations security-wise, and I think you’re confirming what I’d originally guessed that it’s hard to make the sort of thing I had in mind watertight even with labelled data/macaroons, but I didn’t have the knowledge to confirm that.
Thanks for the pointers, really appreciate your taking the time!
1 Like
Was chatting with @lionel.faber this morning and he pointed out something that’s not specified above:
Apps will still need sign keys to ensure requests are not tampered with en route to CH and to vaults.
Ill add this to OP on my next pass through.
1 Like
Not in my proposal. Instead apps only have macaroons and requests are signed by the local authenticator daemon (when macaroons pass verification).
But then apps using this gateway app wouldn’t be standard apps! Furthermore this is not a gateway that I imagine but just a validating/signing daemon (to avoid the bottleneck of earlier authenticator mentioned by @joshuef).
All requests (from who knows how many apps) going through one application. That sounds like a bottleneck to me…
If that daemon crashes? Stalls? Is malicious?
@tfa, With the OP RFC, such a bottleneck / all-signing-application is not required. Plus we get all the benefits of macroons with our asymmetric key macaroon-like implementation. I’m not sure why you’re so keen on the pure-macaroon, auth-daemon-signer approach, with the limitations it has? You said above that the RFC flow / my update post wasn’t clear to you, so can you elaborate on what’s unclear/what problems you’re seeing in the RFC? I think it’ll be helpful in getting us in the same page.
1 Like
Is there a possibility that you put links to info on all required topics in “Assumptions” section?
1 Like
I’ve updated with a couple of links. A lot is not concrete though, so would be a mix of the safe-primer, and forum reading.
Eg, I dont think we’ve a concrete explanation or RFC for the ‘containers’ idea. But the general background was that there was preiviously a fixed set of mutable data, ‘containers’ (for photos, documents, eg), in the accounts root. And that apps could request permission to store things in these, but otherwise there was no method of sharing/discovering data between apps. Apps also had their own, exclusive, unshareable container too.
Hope that helps @loziniak, any more Qs just shout and I’ll do my best to answer
2 Likes
Thanks very much, @joshuef! Probably a little late, but starting to digest that 
1 Like
@joshuef, you mention ClientHandler , DataHandler and Authenticator in “Assumptions” section, but there is no mention about them in the Primer. What are they, actually? Are these class names from a source code?
2 Likes
ClientHandler , DataHandler are modules of a vault when it is an Elder/
Authenticator is a service and app in itself.
4 Likes