Use the host path when current_folder points to the document storage

[xhorak]

Addressing issue #982

[ebassi]

Please, conform to the coding style of the rest of the project.

[ebassi]

Would have been faster, if github had the ability to deal with suggestions involving more than one line.

[xhorak]

Addressed also: xhorak@b3c3f56#r111467974

[matthiasclasen]

Niggle: move the { to the next line

[matthiasclasen]

Apart from that, this looks good to me now.

[jadahl]

The indentation is wrong too

[jadahl]

The commits should be squashed and turned into the first one before landing.

[xhorak]

@ebassi could we please finish this?

[matthiasclasen]

From my perspective, this is good to go

[ebassi]

Same here, so I guess I get to press the green button. 😄

[lissyx]

So while it helps re-open the folder with a "nice name" we still save an XDG document path. Is it possible we have this feature exposed somehow ? Via DBus ? Or maybe it is already doable ? @matthiasclasen @ebassi ?

[ssokolow]

Isn't unprivileged code always seeing an XDG document path part of the point for ensuring that unnecessary information that may be contained in the names of ancestor folders isn't leaked?

[ebassi]

@lissyx Please, open an issue. Commenting on a closed merge request isn't going to help in tracking issues.

[ebassi]

@ssokolow The document storage is not for avoiding "leaking" the original path: it's for providing access to a file. There's no expectation of privacy to be "leaked" in the first place.

[lissyx]

@lissyx Please, open an issue. Commenting on a closed merge request isn't going to help in tracking issues.

I was asking a question, not reporting a bug

[ssokolow]

@ssokolow The document storage is not for avoiding "leaking" the original path: it's for providing access to a file. There's no expectation of privacy to be "leaked" in the first place.

In that case, I'm mildly surprised that the FUSE filesystem doesn't just present a grant for /home/you/Documents/foo.pdf as $DOCUMENT_PORTAL_PREFIX/home/you/Documents/foo.pdf with new grants just appearing as new paths within that virtual filesystem.

It'd make it much easier for things like some text editors' $PWD-relative or current-document-relative rendering of other documents' paths to Just Work™ more often.

[voidpointertonull]

@ssokolow The document storage is not for avoiding "leaking" the original path: it's for providing access to a file. There's no expectation of privacy to be "leaked" in the first place.

So was privacy provided just by coincidence with no plan of supporting this aspect in the future?
It's a quite important detail as many of us started preferring Flatpak due to the shift from just packaging programs to also isolating them which used to be desired mostly to just protect the system, but nowadays it's almost as important to prevent unnecessary data collection done so aggressively that the behavior would have been classified as malware-like earlier.

I'm curious if my expectations are really out of the scope of the project, but what I seek in Flatpak is mostly what I used to seek in browsers which is keeping unknown, often hostile by design programs in check including privacy ("data security") too to some degree.
For example browsers exhibit an I believe decent compromise which is the same what could be observed during the usage of the file access portal: Files are provided with their original name, but no path information gets leaked to the target as the path is meaningless to the vast majority of benign targets while it possibly contains sensitive information useful for malicious purposes.