Media privacy

[Gawrion]

Hey. I think that You should implement some mechanism to protect media (photos) from access from guest accounts. Now i can grab url of photo simply pasting its filename from media directory. It can be done by changing directory of media outside www root and make php to grab it dependant on account rights. There are many possiblities but i think that You should adress it.

[David-Baron]

Hello. On a web application, you can not protect the media, they are necessarily public with a url. Currently you have a possibility:

• make a public tree without the photos
• make a tree with photos and an identification for the people to whom you want to give access. Another solution would be to have only one tree with an identification option to see the photos, I do not think it exists and I know that the author of the application is already overloaded by other modifications.

This not being a "problem" I invite you to go to the forum where you will find more help and advice for using this application.

[Gawrion]

Hey David. Of course u can protect them. For example: u place photos outside a www root directory and serve them dynamically by php script that checks if u re authorized to use. It's not just only theory - i use protecting files this way at my website. I can provide some example code.

[David-Baron]

Hello Gawrion. So re read what I told you. I give you the currently applicable solutions and those that could be applicable in a future ipotetic. You can also make the necessary code changes and propose them here in a PR.

[Gawrion]

Hey. Protecting photos by having a tree without photos is absurdal solution... Sorry but none of your solutions solves my problem and none adresses the issue proffesionally. Other thing is that u don't have time to implement, don't want to do that - i'm not urging to do that. I just adressing an important issue according to GDPR law and privacy. Privacy issueas should always have high priority. And other thing is that there is no problem for coding that. Of course serving private protected files also involves making a custom code to save those files in a certain directory, but it's as EZ as serving them.

Here is some code in separate php file i use to serve png/jpg files based on URI parameter for "file name":

<?php
session_start();
if (isset($_SESSION['loggedin']) && isset($_GET['picture']) && isset($_GET['uid']) && $_GET['uid'] === $_SESSION['uid']) {
    $directory= 'directory_with_all_private_files';
    //users directory
    $dir = $directory. "/" . $_SESSION['uid'];
    $dir = realpath($dir);
    $picture= $dir . '/' . basename($_GET['picture']);
    $picture= realpath($picture);
    if (is_file($picture)) {
        header('Content-Type: image/png');
        header('Cache-Control: private, max-age=3600');
        header('Pragma:');
        header('Expires: ' . gmdate('D, d M Y H:i:s \G\M\T', time() + (60 * 60))); // 1 hour cache
        readfile($picture);
    }
    } else {
    //global function to give 404 header
    ustawHeader404();
    }

Implementing that function/way should be as EZ as parsing file name (u have that already in database under humo_events (event_event) by above function/php file. Maybe some minor changes should be done also.

This is a real file URL i get photos by when im logged in ("obrazek" means "picture" - i changed variables names to english so u can ez understand the code): https://my.oodo.pl/modules/profile/daj_obrazek.php?obrazek=9b4a10e70eaf3b951eaa542410a45040.png&uid=37

In my browser it serves image as i'm authorized. In Your browser it will give U 404 code:

[David-Baron]

I think you didn't understand my message but it's not important. On the other hand: "I just addressing an important issue according to GDPR law and privacy" has nothing to do with this unless you use and distribute images that you are not the author of or that you do not have the authorizations, (so you just want to hide them hummm) "global function to give 404 header" This does not correspond to a clean code, should be "401 Unauthorized" In addition, the majority of users index (SEO) their site and their images, therefore contrary to the current use of humo-gen. Nothing prevents you from doing a search to find an application that corresponds to your needs, or possibly doing it yourself.

[Gawrion]

1. Im lawyer specialized in GDPR topics. U (or other authorized ppl) can have legal basis for personal use of some photos under article 2 GDPR, but giving access to others will be violation of GDPR. It's obvious for me. In similar way u share some private rosources with ppl u want but not whole world with Google Docs and hundreds other tools. Obvious things.
2. Give header as U wish. Good practice is to inform not authorized user that resource do not exists than that it exists and he can find a workaround way to get it. But give headers as u wish. I use 404. For example for password retrieval i also do not inform that e-mail is/insn't in database ;) Standards in privacy are changing - u re talking about standards 2 decades ago. Do as u wish.

HumoGen is an excelent tool - i dont need other. I can contribute to this tool and make it better. U seem to be kind of person that rather finds a problems, not solutions. Not a good person to represent this tool with a high standards. U re rather not good informed, rather rude than helpfull.

[David-Baron]

1 - I invite you to read and reread the scope of this article 2 paragraph 2c and you will then understand that it does not apply. In addition, humogen has a function that corresponds to the GDPR to hide the personal data of the people you want. (that you use on your own site) 2 - For SEO and some other reasons that I will not develop here, you must indicate why some images are available and others not to the browser. 3 - "Privacy standards are evolving - you are talking about standards from 2 decades ago" you are talking about something that you do not yet master because I saw a uid pass in GET in your code.

In fact, I just came to give you "palliative" solutions that you interpret in an incomprehensible way, sorry but I can't do anything for you. exept if you are interested in collaborating, we can work together to put together a solution that works for you and benefits the project.

[HuubMons]

At this moment i'm having a small vacation. I will check this thread and added code later.

Op zo 17 nov 2024 11:34 schreef David Baron @.***>:

1 - So you are (maybe) a lawyer, I invite you to read and reread the scope of this article 2 paragraph 2c and you will then understand that it does not apply. In addition, humogen has a function that corresponds to the GDPR to hide the personal data of the people you want. 2 - For SEO, you must indicate why some images are available and others not to the browser. 3 - "Privacy standards are evolving - you are talking about standards from 2 decades ago" you are talking about something that you do not yet master because I saw a uid pass in GET in your code.

In fact, I just came to give you "palliative" solutions that you interpret in an incomprehensible way, sorry but I can't do anything for you.

— Reply to this email directly, view it on GitHub https://github.com/HuubMons/HuMo-genealogy/issues/47#issuecomment-2481155037, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQKFF6LL2AVHYTIQ2CTZ7L2BBWJZAVCNFSM6AAAAABRPQ4UAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBRGE2TKMBTG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Gawrion]

David - sorry but i don't want to talk with u more. I do not see the point.

HuubMons - thanks. I can do some code changes and tests, but for now i don't know the philosophy of code. Before i'll do that it would be nice to hear few words about the code logic from U, rather than analyze it by myself.

[David-Baron]

Your code example is an old code that is more than 15 years old and is not secure, so we will not put it in humogen. So I reassure you, you have nothing to do, the code is almost finished, it will soon be available to Huub. But thank you for your participation.

[Gawrion]

Lol. David. U can't put that code to humogen - it's only example of technique/logic u can serve the files based on authorisation. Real piece of code must fit to humogen architecture/logic. In Poland we call ppl like You, trying to be smarter that they really are: "głupiomądry". For someone who writes the code it's obvious. For You - it isn't.

This technique (as it is) can't be secure/not secure becouse it's just simple technique:

if (userIsAuthorizedToTakeTheFile($user)) {
    giveUserTheFile($picture);
} else {
    dontGiveUserTheFile();
}

But for sure it's more secure than:

if (anyoneWantsTheFile()) {
    giveAnyoneTheFile($picture);
}

U understand? :)

[Gawrion]

One more thing. If you're serving file dynamically by php with headers i gave in above example, when u try to save the file (rendered inline in browser) it will have name of php file. Now i think in humogen it will be more usefull when file would have original name when saved. U can do it adding: header('Content-Disposition: inline; filename="' . $filename . '"');

[HuubMons]

HuubMons - thanks. I can do some code changes and tests, but for now i don't know the philosophy of code. Before i'll do that it would be nice to hear few words about the code logic from U, rather than analyze it by myself.

I'm rebuilding all scripts. The original scripts were mixed PHP and HTML (the first version was around 2005, there wasn't CSS and seperated scripts then. We used less scripts because it was faster reading these files at webservers).

Several scripts are now extracted into MVC model (under construction): index.php -> link to controller. controller script -> get data from model script. index.php -> shows view script.

At this moment I'm not convinced about moving photos outside the www root directory.

1) If a user sees a photo it's always possible to copy this photo. Because this photo is allready in the cache of the browser, and it's possible to just create a screenshot.

2) There is allready a privacy filter build in HuMo-genealogy. If the privacy filter is active, photo's will not be shown.

3) Photo's are shown using glightbox (maybe replaced with bootstrap in the future). I'm not sure if an added script to secure photo's will work in combination with glightbox.

4) All photo scripts will be changed. Because of this forum topic: https://humo-gen.com/genforum/viewtopic.php?t=3069

But: I actually don't care to add a new function to HuMo-genealogy if needed for security.

[Gawrion]

Finally some words i fully understand ;)

I saw this controllers logic. Seems straight and clean, but i will need time to analyze it.

Of course u know all the relations and potential problems better than me. Now - when i work with a new version i see that its some hybrid (old, static html and some new things in ajax). Not whole UX is nice - that confirmation at the top is most annoying.

1. Dynamically serving photos behaves (as far as i know) the same as static - u can also set header for cache. U can always save the photo. Difference is only URL with php parameter. What screenshot do U mean?
2. Privacy filter do not protect photos. It only prevents from displaying. U can still download a photo knowing the name of file. Im afraid of some brute force crawlers etc.
3. It's been a long time i touched lightbox (last time few years ago in Drupal). Now i checked - asked GPT if Lightbox2 can create it's show with dynamic links - GPT - says it can - it only needs valid url, no matter if it;s static or dynamic.
   
4. OK. I see u have some work to do with thumbnails. I agree that logic where: photo uploaded=thumbnail generated - is much more better, and there wont be timeouts with large media dir. Agree. But for thumnails u can apply the same logic as for the original files - the same parser function checking the same privileges (logically its the same media, but smaller ;))

Ok. I understand that u don;t want to adress that issue, but im, a little bit concerned. In a few weeks i'll try to analyze the code and do some stuff and maybe create pull request after testing or fork.

When U plan to do some bigger changes to code, so we can do some synergy?

[HuubMons]

When U plan to do some bigger changes to code, so we can do some synergy?

It's a hobby project, I don't have a specific planning. Most recent development version can be found here: https://github.com/HuubMons/HuMo-genealogy/tree/prepare_next_version