neue medienordnung plus - nmoplus@hub.freecommunication.org

Token for channel A make accesible not public webpage from channel B

Tue, 14 Nov 2017 08:06:39 +0100 last edited: Tue, 14 Nov 2017 08:59:07 +0100

I created webpage WPB http://dummy.org/page/wpb on channel B with [observer=1/0] protected content
I created Token TCA for channel A zat=tca
I open webpage WPB with token for channel A
I see protected content in webpage WPB

Hubzilla version 2.8.1

@Mike M. closed the issue https://github.com/redmatrix/hubzilla/issues/909 , but I mean, that is one bug, that Hubzilla display protected content in webpage WPB for visitor with Token TCA, that is legal for channel A. Because I created one token for access to channel A, not to channel B.

Similar to Login on Hubs:

one valid Login on hub https://hub.freecommunication.org/ be no permission for login on hub https://macgirvin.com/
I anticipate, that one valid token for https://hub.freecommunication.org/channel/nmoplus be no permission for https://hub.freecommunication.org/channel/wallzilla

I mean, The actuelle behavior of token solution is a danger for channel security:
malicious user from channel https://hub.freecommunication.org/channel/A can make one token TCB and get an access to token protected content on channel https://hub.freecommunication.org/channel/B

Token managament is located by channel owner A. This fact suggested, that the token from channel A is valide for channel A. I mean, that one average user assume, that the tokenized access to content protected their content. What mean you? Please vote pro or contra of this statement:

Token for channel A give no permission to access to via token accessible content from channel B

#tokenmanagement #token @Hubzilla Support Forum+ @Hubzilla Development+

token tokenmanagement permission security ACL

show all 9 comments

Mike Macgirvin

Tue, 14 Nov 2017 10:10:07 +0100

I mean, that one average user assume, that the tokenized access to content protected their content.

Sorry but no.

If you allow "anybody authenticated" to access a data item, you can't pick and choose how they authenticate. B's content is visilbe to anybody on Hubzilla that does remote auth, as well as anybody who logs into the site with openid, as well as anybody who authenticates with a token. If you want control of who can see your content, "anybody authenticated" is a poor choice. You really want "visible to specific connections", where B can choose *only* B's access token holders and block A's access tokens.

Privacy is hard. If you want to do it right, you'll use access control lists as Hubzilla was designed and stop trying to get tricky with observer tags. Observer tags have their purpose but access control is not it. Observer tags are designed for creating identity-aware content; which is an entirely different kettle of fish than access control.

neue medienordnung plus

Tue, 14 Nov 2017 10:27:52 +0100

@Mike Macgirvin Can you little more disclose about this solution approach:

You really want "visible to specific connections", where B can choose *only* B's access token holders and block A's access tokens.

Privacy is hard. If you want to do it right, you'll use access control lists

for this purpose: the selected area of webpage make "visible to specific connections", for example, for:

*only* B's access token holders?
only loggeduser XYZ?

Mario Vavti

Tue, 14 Nov 2017 10:44:58 +0100

@neue medienordnung plus the observer tag has nothing to do with permissions or protection as you call it.

observer=1 content will be visible to any authenticated channel and/or guest token allowed to see the content (in terms of is allowed to view your webpage from the acl).

observer=0 content will be visible to any not authenticated viewer.

observer=0/1 basically only works with public content since we need to be authenticated to see restricted content. So any channel viewing restricted content will always see the content of observer=1.

Mike Macgirvin

Tue, 14 Nov 2017 20:25:01 +0100

the selected area of webpage make "visible to specific connections"

That ability does not currently exist. I believe you asked for this as a feature request a while back, but realistically we can't implement it because bbcode is not and cannot ever be used as an access control mechanism. All somebody has to do is "view source" and they can see whatever it is you're trying to hide.

Hubzilla does not provide any access control at the paragraph level. It does provide some bbcode options to tailor paragraphs to the audience but these are not access control and were not designed with security in mind. They are more of a "parlour trick" or "novelty" than a privacy mechanism.

The channel permission limits provide access control at the resource level (who can see *any* of my webpages), and ACLs can restrict individual items (who can see *this* webpage). By adjusting these, one can implement most privacy mechanisms that are available to large centralised providers, but using a decentralised network. To my knowledge, no other decentralised web project provides this ability, though there is a crude and limited prototype of this ability in Friendica; which I wrote at an earlier stage in my life.

neue medienordnung plus

Wed, 15 Nov 2017 10:03:00 +0100

@Mike Macgirvin: Thank you for the detailed answer. I mean, this hack

All somebody has to do is "view source" and they can see whatever it is you're trying to hide.

is not suitable for viewing of with [observer=0/1][/observer] hided content. Can you see, what I hided in this demopage https://hub.libranet.de/page/wallzilla/vertrauliche-inhalte-freigeben-demoseite_de

?

I mean, that without the opportunity "access control at the paragraph level" is it for developer of hubzilla apps very difficult, attractive (killer) hubzilla app to develop.

Mike Macgirvin

Wed, 15 Nov 2017 11:30:42 +0100

That's funny. Challenging me on my own software? Too easy. Which version do you want? observer=0 or observer=1? Observer=0 is pretty much empty. observer=1 has a bunch or lorum ipsum and a zat password and a bunch of German text I'm not going to bother translating.

Steffen K9 🐙

Wed, 15 Nov 2017 19:56:52 +0100

Well, if I'm logged in I see the Loremipsum stuff and my name in the text. If I'm logged out I can only see the headline but not the content. If I put the '&zat=topsecret' at the end of the URL I can see the content but instead of my name it shows "Dear Guest/LieberGast".
Looks reasonable to me.

neue medienordnung plus

Wed, 15 Nov 2017 20:04:20 +0100

OK, is my fallacy. And for advanced serverside access control at the paragraph level need hubzilla developer such tools how AJAX with ACL Support - right?

Mike Macgirvin

Wed, 15 Nov 2017 20:35:55 +0100

And for advanced serverside access control at the paragraph level need hubzilla developer such tools how AJAX with ACL Support - right?

It needs a whole lot more than that. You're welcome to give it a go.