Seenthis
•
 
Identifiants personnels
  • [mot de passe oublié ?]

 
  • #p
  • #pa
  • #pad
RSS: #padding

#padding

  • #paddington
  • @b_b
    b_b @b_b PUBLIC DOMAIN 6/02/2023
    8
    @jeanmarie
    @biggrizzly
    @sandburg
    @gblin
    @rastapopoulos
    @hassan_nya
    @ericw
    @cy_altern
    8

    Visual #design #rules you can safely follow every time
    ▻https://anthonyhobday.com/sideprojects/saferules

    You do not have to follow these rules every time. If you have a good reason to break any of them, do. But they are #safe to follow every time.

    – Use near-black and near-white instead of pure black and white
    – Saturate your neutrals
    – Use high #contrast for important elements
    – Everything in your design should be deliberate
    – Optical #alignment is often better than mathematical alignment
    – Lower letter spacing and line height with larger #text. Raise them with smaller text
    – Container borders should contrast with both the container and the background
    – Everything should be aligned with something else
    – #Colours in a palette should have distinct brightness values
    – If you saturate your neutrals you should use warm or cool colours, not both
    – Measurements should be mathematically related
    – Elements should go in order of visual weight
    – If you use a horizontal grid, use 12 columns
    – #Spacing should go between points of high contrast
    – Closer elements should be lighter
    – Make drop shadow blur values double their distance values
    – Put simple on complex or complex on simple
    – Keep container colours within brightness limits
    – Make outer padding the same or more than inner padding
    – Keep body text at 16px or above
    – Use a line length around 70 characters
    – Make horizontal #padding twice the vertical padding in buttons
    – Use two #typefaces at most
    – Nest corners properly
    – Don’t put two hard divides next to each other

    b_b @b_b PUBLIC DOMAIN
    • @sandburg
      Sandburg @sandburg CC BY-SA 6/02/2023

      #ux Finitions.
      J’ai l’impression qu’on redit toujours un peu les même choses depuis 15 ans.
      Et surtout que ce sont les pratiques de PAO qui débouchent sur le web.

      Sandburg @sandburg CC BY-SA
    • @cy_altern
      cy_altern @cy_altern CC BY-SA 7/02/2023

      #saferules #design_system #webdesign

      cy_altern @cy_altern CC BY-SA
    Écrire un commentaire
  • @kassem
    Kassem @kassem CC BY-NC-SA 14/04/2019
    2
    @simplicissimus
    @sandburg
    2

    BBC - Capital - Why airlines make flights longer on purpose
    ▻http://www.bbc.com/capital/story/20190405-the-secret-about-delays-airlines-dont-want-you-to-know

    http://ichef.bbci.co.uk/wwfeatures/live/624_351/images/live/p0/75/n0/p075n08y.jpg

    Ils appellent ça le #padding : même si l’avion ne part pas l’heure, il arrive à temps, parce que la ponctualité (quant à l’arrivée) compte plus que le « bilan carbone »

    Ever wondered why flight times seem to be getting longer? It’s called “padding”, a phenomenon that helps airlines arrive on time – but at a cost.

    Le comble est que même comme ça, l’objectif (inavoué) n’est pas toujours atteint,

    “On average, over 30% of all flights arrive more than 15 minutes late every day despite padding,” says Captain Michael Baiada, president of aviation consultancy ATH Group citing the US Department of Transportation’s Air Travel Consumer Report. The figure used to be 40% but padding – not operational improvements – boosted on-time arrival rates. “By padding, airlines are gaming the system to fool you.”

    #avion #vol

    Kassem @kassem CC BY-NC-SA
    Écrire un commentaire
  • @stephane
    Stéphane Bortzmeyer @stephane CC BY-SA 11/05/2016

    RFC 7830 : The EDNS(0) Padding Option

    Ce nouveau #RFC fait partie de la série de ceux qui tentent d’améliorer la situation du #DNS pour tout ce qui concerne la protection de la #vie_privée. Parmi les efforts dans ce domaine, il y a une possibilité de chiffrement des communications DNS, dans le futur RFC DNS-sur-TLS. Elle utilise le protocole TLS. Ce dernier ne fait rien pour dissimuler la longueur des requêtes et réponses DNS. Or, de telles #métadonnées peuvent suffire à identifier les requêtes faites. Il est donc important de compléter le chiffrement avec un mécanisme de #remplissage (#padding). C’est ce que permet la nouvelle option #EDNS normalisée dans ce RFC.

    ▻http://www.bortzmeyer.org/7830.html

    Stéphane Bortzmeyer @stephane CC BY-SA
    • @cocoadaemon
      alban @cocoadaemon 11/05/2016

      Merci c’est très intéressant. Ça éveille chez moi quelques questions :

      # Quand les serveurs « standards » disponibles dans les distributions Linux proposeront ils le chiffrement, comme par exemple bind ?
      # Et il faut bien avoir un client qui supporte également ce chiffrement ?
      # Le chiffrement des requêtes « internes » faites par les applis (ex : getaddrinfo) sera-t-il activé ? Ça signifie intégrer ça au noyau ? Est-ce prévu par le projet Linux ? Sur la base de quelles RFC ?
      # Quels logiciels / solutions peut-on utiliser pour avoir aujourd’hui du chiffrement DNS en logiciel libre ?
      # Enfin... « As-t-on du code » est-il bien français ? « A-t-on » me semble plus indiqué cf. ▻https://fr.wiktionary.org/wiki/t-on

      alban @cocoadaemon
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 11/05/2016

      @cocodaemon

      – Unbound a déjà DNS-sur-TLS. Pour BIND, je ne sais pas, il faut demander à ses auteurs. ▻https://indico.dns-oarc.net/event/22/session/2/contribution/2/material/slides/1.pdf

      – oui, le chiffrement change le protocole, client et serveur doivent le gérer

      – getaddrinfo n’est pas dans le noyau. Pour une machine Linux typique, plutôt que de modifier la libc, il faudra sans doute, soit un résolveur local sur la machine, soit un relais (proxy) comme tproxy.

      – aujourd’hui, la seule solution publiée est DNScrypt mais DNS-sur-TLS aura l’avantage d’être normalisé

      – j’ai corrigé le barbarisme :-)

      Stéphane Bortzmeyer @stephane CC BY-SA
    • @x_cli
      X_Cli @x_cli 16/05/2016

      Une idée sur pourquoi cette option a été restreinte aux cas d’usage du chiffrement ? Cela aurait excellent pour l’anti-DDoS : on pad une question avec un nombre d’octets calculé par heuristique sur la taille anticipée de la réponse. Si la réponse excède la taille de la question de N%, elle est tronquée, sinon, elle est répondue. Cela permet de limiter le facteur d’amplification tout en restant en UDP, et cela sans maintenir d’état additionnel (notamment dans le cas du prefetch)

      X_Cli @x_cli
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 18/05/2016
      @x_cli

      @X_cli le RFC dit que c’est pour éviter tout risque d’attaque par amplification. (En TLS ou DTLS, on est sûr de l’adresse du pair.)

      Stéphane Bortzmeyer @stephane CC BY-SA
    • @x_cli
      X_Cli @x_cli 19/05/2016

      En fait, la terminologie dans le RFC est assez pauvre et manque clairement de rigueur, puisqu’elle confond chiffrement et authentification de la source de la donnée. Maintenant, concernant les attaques par amplification, je ne vois pas en quoi une requête claire plus grosse pourrait accroître l’amplification. La décision de mettre du padding est « hop-by-hop ». Au mieux, on diminue l’amplification puisqu’on pose une plus grosse question que nécessaire, pour générer une même réponse. La logique de raisonnement du RFC est complètement cassée. Je ne comprends pas comment un working group a pu laisser passer ça...

      X_Cli @x_cli
    • @stephane
      Stéphane Bortzmeyer @stephane CC BY-SA 22/07/2016
      @x_cli

      @X_cli Cette possibilité (« padder » les requêtes DNS) est discutée en ce moment sur la liste DNSOP. Les problèmes que cela pourrait poser : « this can affect some cases such as query packets not making it to the server due to size, lack of ability of the client to guess what the answer’s message size may be, and also EDNS UDP payload size behavior. In DNS over UDP and its poor-man’s-pMTU-discovery, it’s the client that
      drives the discovery of what works - the server has no idea of whether a
      query+answer roundtrip has succeeded in a reply successfully delivered
      to the client, whereas the client does. The client can use this to tweak
      the UDP payload size, but if the query itself may get dropped, it can’t
      tell if it was the query or the reply that disappeared - there is some
      faith that an unpadded question-only DNS message will go through
      somewhat reliably. »

      Et on me signale que la première mention de cette possibilité était apparue dans ▻https://www.ietf.org/mail-archive/web/dnsop/current/msg12999.html

      Stéphane Bortzmeyer @stephane CC BY-SA
    • @francis1
      Francis Dupont @francis1 22/07/2016

      Pour le support de DNS-over-TLS dans bind9 lire :
      ▻https://kb.isc.org/article/AA-01386/0/DNS-over-TLS.html

      Francis Dupont @francis1
    • @x_cli
      X_Cli @x_cli 24/07/2016
      @stephane

      @stephane Merci Stéphane d’avoir porté cela à mon attention. Je comprends la position, mais je ne la partage pas.
      En effet, un serveur répondant TC à une question non paddée pourrait également répondre une option EDNS (en écho à l’option vide dans la question), avec la taille prévue pour la réponse. Le résolveur pourrait alors mémoriser (ou non) ces informations :
      1) Le serveur comprend cette option
      2) La taille de la réponse est prévue d’être XxX

      Ce n’est pas garanti de fonctionner puisque :
      – l’enregistrement peut changer de contenu entre les deux requêtes... mais ce doit être un cas relativement rare.

      – le problème peut être situé sur un boitier intermédiaire

      Il reste le risque que la requête, finalement pas beaucoup plus longue qu’une requête standard, soit droppée car l’option est inconnue et le comportement est anormal... On retombe alors sur un cas de classique de découverte de capacité du serveur, comme il est déjà fait pour EDNS dans BIND.

      X_Cli @x_cli
    Écrire un commentaire
  • @cdb_77
    CDB_77 @cdb_77 28/12/2014
    1
    @reka
    1
    @reka @visionscarto

    #Paddington, l’orsetto #no_border

    La prima volta che ho visto Paddington è stato su un muro, sotto forma di stencil, accompagnato dalla frase “#Migration_is_not_a_crime”. Ero convinta che fosse opera di Banksy (ma c’è chi sostiene che non sia da attribuire a lui).

    http://media.internazionale.it/images/2014/12/24/103402-md.jpg http://media.internazionale.it/images/2014/12/24/103406-md.jpg http://media.internazionale.it/images/2014/12/24/103407-md.jpg

    ▻http://www.internazionale.it/opinione/francesca-spinelli/2014/12/24/paddington-l-orsetto-no-border
    #graffiti #film #migration #frontière

    @reka : et si on demandait à Francesca (qui parle très très bien français) d’en faire une traduction en français pour @visionscarto ? Je peux le faire, si jamais...

    CDB_77 @cdb_77
    Écrire un commentaire
  • @nhoizey
    Nicolas Hoizey @nhoizey CC BY-NC-SA 26/05/2014

    Spacing elements with #margin and #padding
    ▻http://simurai.com/blog/2014/05/25/spacing-elements

    "So let’s say we have a “bar” with some items inside. Like a header or footer. Let’s also say we want those items to be spaced evenly, meaning they have the same gab everywhere. Shouldn’t be a big problem." Tags: margin padding #espacement #éléments #menu #CSS

    Nicolas Hoizey @nhoizey CC BY-NC-SA
    Écrire un commentaire