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.

changing ACL for tokenized content

neue medienordnung plus

Tue, 14 Nov 2017 06:20:27 +0100 last edited: Tue, 14 Nov 2017 08:08:26 +0100

I created webpage WPB http://dummy.org/page/wpb on channel B with [observer=1/0] protected content
WPB contains image ImA, that be accesible only for selected vistor
I allowed visibility for ImA for token TImA
but image ImA is not visible for token TImA
image ImA be visible for token TImA, if I upload/include image ImA after change of ACL for image ImA

Is this beahavior a bug or a feature? I anticipate, that image ImA be visible for token TImA without new upload image ImA after allowing visibility for ImA for token TImA.

#tokenized #tokenizedcontent #protectedcontent #visibility @Hubzilla Development+ @Hubzilla Support Forum+

tokenized visibility protectedcontent tokenizedcontent ACL

show all 7 comments

Haakon Meland Eriksen (Parlementum)

Tue, 14 Nov 2017 07:20:33 +0100

Are you talking about Zot Access Token/Guest Access Token? If so, the resource needs to be available to Anybody authenticated + restricted to the ZAT/GAT.

neue medienordnung plus

Tue, 14 Nov 2017 08:38:37 +0100 last edited: Tue, 14 Nov 2017 08:41:48 +0100

@Haakon Meland Eriksen (Parlementum) I talking about Hubzilla Guest Access Token. Can yo say me, how can I implement:

the resource to be available to Anybody authenticated + restricted to the ZAT/GAT

in this context:

public webpage PWP
area AOAPWP in PWP, protected with [observer=1][/observer] markup[/i]
area AOAPWP contains images, that receive permissions here

And the Hubzilla behavior of this solution is so, how abowe describe. I mean, that this behavior is a bug.

I understand not, how works this protection

resource to be available to Anybody authenticated + restricted to the ZAT/GAT.

Is your solution approach different from my solution above? Can you give me one example?

#GuestAccessToken #ZATGAT #ZATGATexample #ZotAccessToken

protection authenticated

Haakon Meland Eriksen (Parlementum)

Tue, 14 Nov 2017 11:39:02 +0100 last edited: Tue, 14 Nov 2017 13:18:36 +0100

I will have to get back to you on this, but I think there is some confusion between ZAT and observer.

observer can only tell if you are logged in or not, it does not really care about who you are.

ZAT does know who you are.

In other words, it makes sense to only use one of them.

Suppose you have a public web page of type BBcode with ImageA and ImageB. ImageA is visible to everyone on the Internet, since the page is public. However, using the BBCode observer-tag, you can hide ImageB from the Internet.
Case closed.

Now, suppose you now want to hide the public page, and only allow those who have a ZAT-link to it to view it.
Then you need to create a new ZAT - e.g. OnlyYouAreWelcome, change the permission of the public page so View is only allowed for OnlyYouAreWelcome.

People with the ZAT-link can now view the protected page, if your webpages are generally visible, else you need to change this to at least "Anybody authenticated" if not "Anybody on the Internet" in your privacy settings.

The people who view the protected page are authenticated, i.e. they are an observer=1 and will be able to view both ImageA and ImageB. If you want this to be reversed, you need to switch observer from 1 to 0, i.e. you are hiding something from someone who is authenticated, which may be sensible if the text or image is of a general nature and you want to get it out of the way.

neue medienordnung plus

Tue, 14 Nov 2017 11:57:26 +0100

@Haakon Meland Eriksen (Parlementum)
With this

However, using the BBCode observer-tag, you can hide ImageB from the Internet.

solution is ImageB still accessible/ visible for not authenticated visitor, which visit the channel cloud/ or photos. I need one solution for robust protect/ hide of ressources for all not authenticated visitor.

Haakon Meland Eriksen (Parlementum)

Tue, 14 Nov 2017 13:11:25 +0100

Right, you need two folders, one for restricted files and one for public files.

ImageB must be under a restricted folder in Files, e.g. Restricted Files, while ImageA is in a public folder in Files, e.g Public Files.

Add the ZAT for OnlyYouAreWelcome to Restricted Files.

Add the ZAT-link to ImageB to the webpage.

I may have got this wrong.

neue medienordnung plus

Tue, 14 Nov 2017 13:46:59 +0100

I assume, that with your solution I must all webpages, where include Restricted Objects also declare to Restricted Webpages. Otherwise see other authenticated user without access to image logo.png this message:

Haakon Meland Eriksen (Parlementum)

Tue, 14 Nov 2017 14:46:39 +0100

Well, as described just those with the ZAT-link are allowed in, but you can add other people to the Restricted Files folder. I am going to a meeting now, so good luck!