dead

[legacy]

• 

dead

[Nonefonow]

• 

con thehalloween che ha messo un po' di gpdr, a modo suo 

Forse troppo

[Nonefonow]

• 

O non gli piace il DNS open usato
O non gli piace il fatto che il sito sia HTTP, piuttosto che HTTPs

[Nonefonow]

• 

Prova ad accedere da qui 

L'indirizzo diretto funziona meglio.  Sono riuscito ad accedere usando i miei vecchi soprannome a passaparola.

Pero' non riesco a vedere dentro il baule.

[Nonefonow]

• 

Tutti i collegamenti che mi hai listato mi portano sempre sul paese delle meraviglie, oppure CISCO mi dice no - non si puo'.

Mi sa devo provare da casa.
 

[Z80Fan]

• 

Quest'ultimo ha un check per le dimensioni dello schermo (e del browser usato) e vorrei che fosse fruibile anche sugli smartphone dove lo screen e' tipicamente 420x260 o giu' di li 

Non hai bisogno di controlli programmatici (es. in JS) per adattarti alla dimensione dello schermo, basta che usi un layout flessibile, che HTML di suo nasce già, devi solo star attento o a non dare dimensioni o posizioni fisse (che non siano in %) in CSS (eccetto per un eventuale min-width che volente o nolente a un certo punto dovrai dare una dimensione minima al sito), oppure organizzare elementi (tipo pulsanti) in tabelle (che è un enorme taboo nel web-development moderno).

Diciamo che la tua home page già adesso è largamente flessibile; l'unico problema sono i tre pulsanti principali (vedi prima figura); si potrebbe risolvere la cosa togliendo la table e mettendo dei div flottanti a sinistra (così quando non c'è spazio a destra cadono uno sotto l'altro), oppure inserirli in un layout flessibile in modo che si ridimensionino.
Come buona pratica sarebbe da evitare di usare le table per il layout, però metodi "comodi" per ottenere lo stesso risultato (flexbox) sono tecnologie relativamente moderne (HTML5 e CSS3), e assumendo che si voglia lasciare il sito accessibile a browser più vecchi, si può lavorare con le table in layout fixed:

Codice: [Seleziona]

<table style="table-layout: fixed; width:100%; max-width: 600px; margin: 0 auto 0 auto">
<tbody>
<tr>
<th>
<a href="reloaded/durcheinander/">
<img style="width:95%" src="index_full_data/icon-harlock.png" alt="Durcheinander (secteur privé)"></a>
</th>

<th>
<a href="chunk_of/stuff">
<img style="width:95%" src="index_full_data/icon-folder-pirate.png" alt="Chunks"></a>
</th>

<th>
<a href="reloaded/bazaar/mylast.php">
<img style="width:95%" src="index_full_data/icon-marketplace.png" alt="Bazaar"></a>
</th>
</tr>

<tr>
<th>Durcheinander</th>
<th>Chunks</th>
<th>Bazaar</th>
</tr>

</tbody>
</table>
Come tocco finale metterei un "min-width: 350px" sullo style del body, e ottieni un risultato come nella seconda figura.

[Z80Fan]

• 

ma come fai ad avere 3000-mila pixel scrreen? un errore-di-sbaglio? un magheggio alla Neo dentro matrix? magia voodoo? 

Con uno schermo 21:9
Ho solo dovuto vendere un rene e mezzo ma poi sai che visuale.

[saimon69]

• 

ed con un suggerimento di TheHalloween ha addirittura trovato un modo per embeddare le immagini (le icone) nelle stesse pagine HTML: a me sembra magia pura 

E in efetti e' sconcertante vedere i base-64 di SVG e PNG nei siti moderni, mi chiedo nella mia parziale ignoranza dei framework moderni se sia fatto a manina o usando i vari webpack e soci...

[Z80Fan]

• 

Cosa ne pensate?

Che in questo modo potresti non presentare l'agreement a una persona che putacaso ha lo stesso IP di un'altra che ha già confermato (ad esempio se entrambi stanno su una rete privata che esce dallo stesso IP pubblico).

Comunque noto che c'è tanta confusione dietro cosa dice e non dice il GDPR: non è che dice di non dover memorizzare nessun dato sensibile, ma semplicemente dice che ogni volta che tu memorizzi un dato sensibile, devi documentare per cosa lo usi, perchè ti è necessario memorizzarlo e per quanto tempo prevedi di memorizzarlo. Diciamo che "l'innovazione" del GDPR rispetto a leggi precedenti (complesa la porcata italiana) è che non ci sono più regole fisse e checkbox da riempire per essere in regola, ma regna il concetto di risk assestment dove tu gestore del dato sensibile dichiari i tuoi processi, le tue motivazioni, e i metodi che usi per memorizzare, gestire e proteggere il dato sensibile.

Considerando che (credo) tu non devi memorizzare alcun dato sensibile anche solo per leggere il contenuto del sito pubblico (quindi non ti serve essere loggato), non dovresti aver bisogno di mostrare alcuna informativa, mentre ad esempio quando un utente si registra o accede per la prima volta con un nuovo profilo, puoi presentare la schermata di accettazione e quando l'utente conferma ti segni un booleano nel database per dire che l'utente ha accettato l'informativa. In questo modo non hai bisogno di trafficare con i cookie quando un utente non è loggato, e quando uno è loggato avrà o un cookie o il token di sessione nell'URL (come fanno vari framework se si accorgono che i cookie sono disabilitati), e quindi con quello puoi risalire all'agreement guardando i dati dell'utente associato a quel token.

[saimon69]

• 

il commento di Madame, in coro con TheHalloween: - Some people are too paranoid, seriously

Nun me fa commenta' :/ - cmq parlando degli steits la paranoia e' quasi un requisito nazionale...

[saimon69]

• 

mi chiedo, ma sarebbero contenti, o continuerebbero a rimbalzare queste frignacce in giro per la rete?

e' la seconda che hai detto

[Z80Fan]

• 

2) e che tra browser e server, anche senza HTTPs, ci sarebbe un tunnel criptato

Occhio che hashare la password sul client non vuol dire "cifrare", perchè l'hash stesso diventerebbe la password: metti che la password "hunter2" viene hashata in "12345", e viene inviata al server (che eventualmente fa un secondo hash+salt per compararla a quella memorizzata nel DB), effettivamente è come se "12345" fosse la password in se, e quindi al malintenzionato che ti ha fatto MITM e ha letto il traffico basta fare un replay della tua procedura di autenticazione (trasferendo quindi l'hash) per farsi tornare un token di autenticazione.

E' vero che questo impedisce al MITM di avere la password originale ("hunter2") (semprechè la funzione di hash eseguita dal client sia crittograficamente forte, altrimenti con delle semplici rainbow tables si possono trovare vari plaintext per un certo hash), però non previene la protezione dell'account.

[Z80Fan]

• 

Client-Server asymmetric encryption

Chiamasi HTTPS.

è inutile creare soluzioni "casalinghe" quando ci sono sistemi già rodati inclusi nei browser.
Qualsiasi browser che supporti Javascript già implementa HTTPS, ed è attivo anche se l'utente ha disabilitato gli script.
Inoltre JS è decisamente più lento di un codice nativo, nonostante gli incredibili JIT che ormai includono tutti i browser principali.

[saimon69]

• 

I could be at the risk of catching a virus or something, I went ahead and clicked on your link.  It took me to a page that immediately made me feel my computer was imminently about to receive some nefarious code.  I'm really jumpy when it comes to my computer so you'll have to forgive me. 

LOL

Poi magari si scarica l'update di flash farlocco che viene su dal popup di ytmp3

[Allanon]

•