Protezione dei dati di un defunto

So che l'argomento non è dei più leggeri, soprattutto vista l'estate e la crescente voglia di vacanze, ma la questione a mio avviso guadagnerà sempre più importanza man mano che la generazione dei nativi digitali (ma anche un po' la mia, nato nel '75) avanzerà con gli anni.
La domanda è semplice: cosa accade a tutti i miei dati memorizzati in centinaia di banche dati quando un sarò mancato all'affetto dei miei cari?
Chi potrà accedere alla mia posta elettronica? Chi potrà gestire il mio account facebook?
I miei discendenti potranno accedere alle mie foto salvate lungo tutta una vita nel mio account flikr?

Ma la domanda più importante è: che diritti potranno vantare i miei successori nei confronti di chi questi dati li gestisce (i vari Google, Facebook, Microsoft,...)?

A questa domanda sembra dare una risposta semplice e, a mio avviso, sorprendente il nuovo regolamento europeo sui dati personali.

Il considerando numero 27 del GDPR cita, testualmente:
"Il presente regolamento non si applica ai dati personali delle persone decedute. Gli Stati membri possono prevedere norme riguardanti il trattamento dei dati personali delle persone decedute".

Cosa significa quindi?

Sembrerebbe che i colossi dell'informazione potranno utilizzare i miei dati a loro libero piacimento, senza doverne rispondere a nessuno.

Possibile?

In realtà questo sembra stridere con uno dei principi cardine della carta dei diritti dell'unione europea da cui il regolamento sulla protezione dei dati prende forma, ovvero la salvaguardia della dignità del interessato.

Forse tutto questo sembrerebbe perdere di significato, dato che risulta difficile pensare che i vari Facebook, Google, ... vengano a sapere che un proprio utente sia passato a miglior vita; e ancor meno potrà sapere se l'account è stato ceduto ad un erede.

Non ci resta che attendere i primi casi: saranno di sicuro interesse.

Localization with Angular.JS

In a previous post covering the use of Angular.JS on an ASP.NET (or better, DotNetNuke) web app, a was wondering how to solve the problem of localize the js content.

In fact I discovered pretty soon that many strings of the presentation layer were specified inside the js file, defining the angular app, controller, directive,....

So my first thought was to create a specific handler in order to generate the javascript at runtime so that I would have the capability to use the native localization management of ASP.NET or DotNetNuke.

IMHO the handler would have as many cons than pro, or even worst; for example, every js file would have been addressed by the unique handler, breaking the easy file organization of each DNN module or ascx control, ...: much work for a small problem.

So I passed to another approach:
why not concentrate all the strings to localize in a js object inside the ascx file?
the Angular.JS app (controller/directive,...) would be kept in a separate pure js file, with the capability to access the variable once on the client's browser.

The solution is composed by:
1) a method to run on load, in a base class of the module (or User control), with a couple of properties override-able in the specialized module class.

     protected void LoadResourcesToJavascript()
        {
            if (this.ResourceKeysToJavascript.Count() > 0)
            {
                System.Text.StringBuilder sb = new System.Text.StringBuilder();
                sb.Append("var " + this.ResourceJSVariableName + " = {};\n");

                foreach (String s in this.ResourceKeysToJavascript)
                {
                    sb.Append(this.ResourceJSVariableName + "." + s + "= '" + Localization.GetString(s + ".Text", LocalResourceFile) + "';\n");
                }

                Page.ClientScript.RegisterClientScriptBlock(this.GetType(), this.ResourceJSVariableName + "Resources", sb.ToString(), true);
            }
        }

        protected virtual List ResourceKeysToJavascript
        {
            get
            {
                return new List();
            }
        }
        protected virtual String ResourceJSVariableName
        {
            get
            {
                return this.ID;
            }

        }

Note: I use the DNN method to get the localized string. Change it in case of standard ASP.NET project.
Note: The javascript variable name is the control's ID, but it can be specialized in the inherited module class.

2) in the inherited module / user control specialize the ResourceKeyToJavascript list with the resource string required in the javascript.

 protected override List ResourceKeysToJavascript
        {
            get
            {
                return new List() { 
                                "ConfirmRemoving",
                                "SailingName",
                                "Types",
                                "UnableToFindFriend",
                                "Saved",
                                "Error"};
            }
        }

3) in javascrpit file use the variable name (ASP.NET control's ID) to access the single resource strings:

var str = CrewMemberCollectionV2View.ConfirmRemoving;
if (confirm(str.replace("{sailingName}", entity.SailingName))) {
     //do something  
}

4) last but not least, use the standard resx files to add the required resource strings.

Security using client-side javascript frameworks

In a previous post I put the focus on the security of Angular.JS.

I found a quite easy way to solve this problem:

the problem simply... does not arise.

I am going to explain a bit deeper this concept.

Usually security has to address one main goal: allow to access data/services only if the user has the right authorization.
There is a second, less important goal: adapt the presentation layer to the gained authorization.

Example: if I do not have the the authorization to change the info in a form, the "save button" should be absent on the page!

IMHO this is the real difference between standard "server-side-generated" page (php, asp.net,....) and "client-side-generated" page (Angular.JS,...); this difference can be summarized in this question:

"Who is going to decide if the button should or should not be shown?"

The first solution solve the complete security logic server side, sending to the client only the strictly necessary functions (if not authorized, the server will not even send the the button to the page), while the second solution delegates part (even significant one) of the security logic to client side.

This means that, Angular.JS (as every client side technology) can not solve the security issue itself: all the security logic has to be addressed by separate APIs entitle to check every service exchange among client web page and server web app.

But,even if I put in place this logic (server or client side) I should not forget to put in place the main security check: verify that the operation put in place is allowed!

Conclusion:

Working with client side logic helps a lot to focus on security issue leading to the correct sw architecture, and avoiding to mix up the main security goal with the secondary one.

My first time with Angular.js

I have started learning Angular.JS from scratch and here my first impressions:

• Very coll (impressive!)
• A real way to easy down the UI interface (my nightmare!)
• It seems simple... too simple...
• Yes, but wait... remember... nothing more than the presentation layer.

I was worried by a couple of things:

• how to use security in Angular JS;
• how to localize the strings that have to be set during js runtime.

I am going to explain how I solved these two worries in my next posts.

My first "test projects" for practicing on Angular.JS were focused on:

• simplest ng-module in order to receive info via json and render them to the page;
• simplest form bidirectional (coming / going to db);
• UI grid;
• Google Map (have to try!!);
• put everything in DotNetNuke!

I found this link particularly helpful:
angular-ui.github.io

I found a quite easy way to solve the second problem (I am going to write something about that in another post).

The first problem was solved pretty soon:
the problem simply... does not arise.

I am going to explain a bit deeper this concept.

Usually security has to address one main goal: allow to access data/services only if the user has the right authorization.
There is a second, less important goal: adapt the presentation layer to the gained authorization.

Example: if I do not have the the authorization to change the info in a form, the "save button" should be absent on the page!

IMHO this is the real difference between standard "server-side-generated" page (php, asp.net,....) and "client-side-generated" page (Angular.JS,...); this difference can be summarized in this question:

"Who is going to decide if the button should or should not be shown?"

The first solution solve the complete security logic server side, sending to the client only the strictly necessary functions (if not authorized, the server will not even send the the button to the page), while the second solution delegates part (even significant one) of the security logic to client side.

This means that, Angular.JS (as every client side technology) can not solve the security issue itself: all the security logic has to be addressed by separate APIs entitle to check every service exchange among client web page and server web app.

But,even if I put in place this logic (server or client side) I should not forget to put in place the main security check: verify that the operation put in place is allowed!

Conclusion:

Working with client side logic helps a lot to focus on security issue leading to the correct sw architecture, and avoiding to mix up the main security goal with the secondary one.

FileSystemWatcher

La classe FileSysnteWatcher è un componente con delle potenzialità notevoli.
Riesce a mettersi in ascolto di una cartella e "avverte" quando una modifica è accaduta.
Con modifica intendo, la creazione, la modifica, la cancellazione di files o sotto cartelle.

Premetto che non l'ho ancora utilizzato in alcuna produzione ma questo strumento è decisamente interessante in quanto la mia esperienza ha mostrato che ancora oggi il sistema più usato per scambiare dati tra processi diversi è il deposito di un file in una cartella di scambio e di un loop che controlla l'esistenza di nuovi file (in moltissime realtà il concetto stesso di soap service non è ancora arrivato).
Ebbene, questa classe consente invece di evitare la creazione del loop ma affidarsi agli eventi scatenati, con ovvi benefici in sicurezza, affidabilità e robustezza.

Come usaer Page_Load e Page_Init

Nel Page_Init bisogna lanciare tutto quello che riguarda la costruzione della pagina (o del controllo in generale) che NON RIGUARDA I DATI che eventualmente possono essere caricati da un post.

Nel Page_Load invece si mette tutto ciò che è inerente alla manipolazione del dato da visualizzare.

Ad esempio: il caricamento dinamico di una drodownlist deve avvenire in init, almeno nel caso in cui il caricamento non fosse in funzione di dati della pagina stessa.

Questa distrinzione vale anche per i partial postback di Ajax.
Da ricordarsi comunque che in questo caso this.IsPostBack è sempre a true.

Resizing image on the fly

Per risolvere questo problema in maniera definitiva ho deciso di creare un servizio on line di ridimensionamento delle immagini "al volo".
Il sistema è molto semplice:
1) registrarsi al servizio contattandomi marco@ghizzi.it e comunicandomi la cartella delle immagini pubblicate on line.
2) vi verrà fornito un codice utente.
3) utilizzare il link del seguente tipo anziché l'immagine locale:
htttp://www.ghizzi.it/outimage/<codice_utente>/<nome_immagine_compresa_di_estensione>.ashx
4) a questo url aggiungere in query string uno o più parametri dei seguenti:
width=<larghezza_in_pixel>, height=<altezza_in_pixel>, align=<near_far_o_center>, color=<colore_di sfondo>
5) al posto di tali settaggi si può precaricare dei preset identificati da dei codici all'atto della registrazione.

Per ulteriori informazioni, contattatemi alla email marco@ghizzi.it