Sorry, dubbel (waarom staat de knop "bewerken" niet onderaan?)

En weet je wat het leukste is?


Deze...

From: no reply a organisation
To: Erik
Subject: webform

Dear Eric , thanks for reaching out to us
If you have questions about our products, please look at our website; www


:)
Regards, No Reply

Security freak klaagt over webform dat gebouwd is op maximale security .

Heel strakke filtering van karakters (waarschijnlijk alleen maar a-zA-Z0-9 ) , zodat allerlei escape/quote/injectie opties beperkt zijn.
Lengte beperking voorkomt DoS / overflow aanval.

Vanzelfsprekend geen rechtstreeks email adres zodat de berichten die "de organisatie" ingaan van buiten hoe dan ook herkenbaar zijn als 'extern untrusted source" (het zal wel in een verwerkings of ticketing applicatie komen, met een FROM WEBFORM) , waardoor allerlei spoofing opties en malicious attachments niet mogelijk zijn.

Nou dat is PRECIES wat "wij experts" toch altijd willen ? Tenminste, aan de verdedigende kant.

En zoals het security experts betaamt, met helemaal schijt aan de gebruikers, want zekjoerity boven alles !

Nadeel van die webforms is soms groter dan gewoon een losse e-mail zenden:
- soms slaan ze de informatie op in de database van de website en daar blijft die informatie dan plakken.
- of je krijgt meteen een nieuwsbriefabonnement.

Voordeel is wel:
- ze vragen alle informatie die ze nodig hebben om je goed te helpen (je wordt dus sneller geholpen)
- ze kunnen als je een attachment mag sturen goede scanning op verwerking uitvoeren (e-mail is minder geschikt voor bijlagen)
- je weet zeker dat jouw bericht aankomt bij degene die je bedoelt (https certificaat) en dat er geen MitM is (bij e-mail weet je dat minder zeker), mits natuurlijk ze hun webforms goed op orde hebben.

Ik zou slechts vragen: maak op elke webform pagina ook een link aan die gewoon kan mailen, met daarin de velden benoemd die je wilt dat je klant invult. Werkt stuk beter als je een alternatief hebt.

Je kunt niet zien wat er achter de schermen gebeurt. Als de mail wordt doorgestuurd naar een Google of Microsoft account is dat niet zichtbaar. Zet je een link in zo'n bericht en andere persoonsgegevens, dan blijft die gegarandeerd niet privé.

Vaak is zo'n formulier voorzien van allerlei onnodige en overbodige tracking van o.a. Google. Dat varieert van fonts en "analytics" tot het afschuwelijke en niet werkende Recaptcha.

Er zijn geen voordelen voor de invuller van het formulier.

Kan wél, hoor!: 2 Vingers op het scherm, en dan spreiden. Zoals de Vulcan groet.

Wat je nog meer kan vingeren kan je in de uitgebreide gebruiksaanwijzing van je android vinden. ;-)

Grootste probleem is tegenwoordig dat vaak een webform en mailadres ontbreken, dit vrijwel altijd bij bedrijven met een matig serviceniveau (recente zeer negatieve ervaringen met de NS, FBTO, Postnl, Ziggo en Rabobank, denk dat daar het woord service verdwenen is). Je mag het dan met een chat doen (die via een derde partij loopt, waarbij je geen idee hebt wat met jouw gegevens gebeurt) waarbij het voorbij de robot komen erg lastig gemaakt is en de klant onnodig lang moet wachten. Uiteraard kun je bellen, echter de nonsens die daar vaak uitgekraamd wordt heb je liever op papier. Niet dat je er veel aan hebt maar het is een makkelijker bewijs dan een opgenomen gesprek.
De Rabobank heeft dan wel een klachtenformulier, daar mag je twee regels tekst invoegen en dat is het. Daarbij moet je jouw mailadres opgeven echter wordt deze niet gebruikt voor de afhandeling, dit moet telefonisch. Ben je niet bereikbaar, bellen maximaal drie keer (vier keer overlaten gaan) krijg je een standaard brief. Dat je hun kunt bellen, uiteraard geen behoefte aan en daarna is voor hun de klacht/opmerking afgehandeld. Veel klantonvriendelijker gaat het niet worden.

Daar lijkt het volgende aan de hand te zijn:

CSS heeft de mogelijkheid om voor HTML-elementen een resize-attribuut in te stellen. Dat heeft als default-waarde 'none', maar voor een textarea-element hanteren veel browsers als default 'both', wat wil zeggen dat je zowel horizontaal als vertikaal de grootte kan aanpassen. Zie voor een beschrijving:

https://developer.mozilla.org/en-US/docs/Web/CSS/resize

Ik heb de volgende minimale HTML-file gemaakt en die geopend in Firefox en Chromium (Linux desktop):

In beide browsers kan die textarea vergroot en verkleind worden. In beide browsers kan je met F12 de toegepaste CSS en ook de berekende CSS inspecteren, en dan blijkt voor Firefox resize op 'both' te staan en voor Chromium op de default-waarde 'none', al gedraagt Chromium zich alsof het 'both' is.

Security.nl heeft geen waarde ingesteld in de eigen CSS. Het resize-hoekje verandert de muispointer in een symbool dat zowel horizontaal als vertikaal resizen suggereert. Dat het in de praktijk alleen vertikaal is zal aan andere css-eigenschappen liggen die voor de breedte een vaste waarde forceren (dat heb ik niet uitgeplozen).

Ik vermoed dat op de smartphone-browser(s) die jij gebruikt de default 'none' gebruikt voor textareas (wat de standaard is).

In de desktop-versie van Firefox kan je er wat aan doen (al hoeft het daar niet) door in je profiel-directory het volgende css-bestand op te nemen of te wijzigen:

~/.mozilla/firefox/<profiel>/chrome/userContent.css

Dat bevat CSS-definities die in elke getoonde pagina worden geïnjecteerd. Daar kan je in opnemen:


Met !important wordt aangegeven dat deze definitie voorrang krijgt boven eventuele definities die de website in zijn CSS heeft opgenomen.

Voor zover ik weet hebben chrome-gebaseerde browsers niet een dergelijk mechanisme, en of de Firefox-versie voor smartphones dit ook heeft weet ik niet. Of je het met deze uitleg voor elkaar gaat krijgen weet ik dus ook niet. Dan geeft deze uitleg in ieder geval een indruk van waar in het geheel van de opmaak-verwerking van browsers dit speelt.

De gedachte komt bij me op dat het verschil tussen desktop- en smartphone-browsers hierin een bewuste keuze kan zijn met een goede reden. Ik heb zelf geen smartphone dus kan ik niet uitproberen hoe het uitpakt, maar ik kan me voorstellen dat het makkelijk is voor een gebruiker om een textarea op een smartphone met een onbedoelde veeg per ongeluk groter dan het scherm te maken en dat het resultaat dan makkelijk verwarrend is.

Webforms hebben voor en nadelen.

Dat jij een email terug krijgt zonder alle CR, wil niet zeggen, dat het bericht dat bij de ontvanger aangeleverd is, dit ook heeft.
Vaak zit er een ticket systeem achter, waarin deze informatie bewaard is/wordt.
Daar dat hoeft natuurlijk ook weer niet.

Het heeft zo zijn voor en nadelen, zijn positieve en negatieve eigenschappen.

Een website die browser afhankelijk is?
Dan zal de maker geen ICT opleiding hebben gehad, iets dat veel zegt over de instantie.

Maar wel voor de ontvanger.
En alle argumenten die je gebruikt zijn natuurlijk onzin, want dat weet je ook niet als je een email stuurt. Als jij de email naar de NS stuurt is de kans bijzonder groot dat deze gewoon bij Microsoft uit komt hoor, dacht je dat alle bedrijven nog zelf mail servertjes draaien?
En de website heeft de tracking, niet het formulier zelf. Zeker nog nooit gewerkt aan de kant van een website bouwer?

Sterker nog: de links, code e.d. wordt er expres uit gefilterd en zou HELEMAAL NIET terug gestuurd worden naar de indiener/aanvrager, alleen een bevestiging van ontvangst.

Ik heb al bij twee organisaties meegemaakt dat een webform gebruikt wordt door chinese bot's om spam te verzenden, doordat het invoerveld wordt gestuurd in de mail naar de indiener. Hint: als ik daar JOU email adres in voer, en bij het bericht zeg dat je vooral moet kijken op de pagina waar je gratis kan gokken, dan krijg JIJ een mail met dat bericht... En dat gebeurd dan tientallen keren met minuut, zelfde bericht, andere indiener...

Hij heeft wel een punt. Cr/lf strippen is zeer irritant

Verder boeit het mij niet zo, in deze fake matrix wereld is toch alles nep

Waar je rekening mee moet houden is dat mem alles wat je in een form typed kan vastleggen, zelfs als je het form niet verstuurd... Auto fill is makkelijk maar soms behoorlijk onwenselijk

Wanneer Google Recaptcha gebruikt wordt, wordt er een screenshot gemaakt en geüpload naar Google (nooit word je hier voor gewaarschuwd).
Google kan dan dus gewoon de ingevoerde velden zien. En ja je kunt je hier tegen wapenen, echter het formulier verzenden zal dan nooit lukken. Naast uitermate klantonvriendelijk (je blokkeert tenslotte standaard alles van Google in jouw browser) is het ook nog eens volstrekt illegaal.

Geen idee hoe de techniek werkt he?
Het is ook niet zo dat als je in een webwinkel van alles in je mandje duwt en dan het venster sluit iedereen daar verzucht dat de bestelling niet door gaat..,

Ik kon hier niet 123 iets van vinden op Internet dat dit gedaan wordt. Heb je ook extra informatie hierover?

Dank voor de vele reacties. Ik ga in op enkelen en haal slechts relevante (voor mijn reactie) gedeeltes aan:

Je hebt duidelijk mijn post bovenaan niet gelezen.

Megabytes wil ik geloven, maar niet 1 of enkele kilobytes.

Waarom zouden beiden niet ook gelden als je een e-mail zou kunnen sturen?

Dat geldt vooral voor webforms waar je allerlei info over jezelf moet invullen, zoals klantnummer, bestelnummer, datum dat product geleverd werd etc. - maar daar was hier geen sprake van.

Waarom zou e-mail minder geschikt zijn voor bijlagen? (Heel grote inderdaad, maar die wil je ook niet geüpload hebben).

Tot mijn positieve verrassing zag ik dat de website van de PvdD nog een EV (Extended Validation) certificaat gebruikt (zie https://crt.sh/?q=www.partijvoordedieren.nl). Helaas heeft dat nauwelijks nog zin, want:

a) In o.a. Firefox onder Android en iOS kan ik geen certificaten meer bekijken - helaas pindakaas;

b) Een bezoeker wéét niet, a priori, dat de echte website van de Partij van de Dieren een EV-certificaat gebruikt. Als die persoon, op welke manier dan ook, naar een nepsite (zoals partijvandedieren[.]com) was gestuurd, en die site een Let's Encrypt (of ander DV-) certificaat gebruikt, hoe zou die persoon dan moeten weten dat het om impersonatie gaat?

Daarmee zoom je de hele webpagina. Je krijgt er geen letter extra door te zien in het invulveld (de letters worden slechts groter).

Dank, ik ben kennelijk niet de enige die zich groen en geel ergert.

Dat zou kunnen, maar waarom zou een webontwikkelaar überhaupt harde returns verwijderen uit tekst ingevoerd in een invoerveld? En áls je dat doet, waarom zou je dat dan wél doen in de ontvangstbevestiging (dit is NIET hoe ik het geschreven en bedoeld heb; de integriteit van mijn bericht is niet gehandhaafd), doch niet (wat jij voor mogelijk houdt) in het bericht zoals de beoordelaars het onder ogen krijgen?

Smartphones hebben flinke beperkingen, vooral in vergelijking met de loeigrote monitoren die velen tegenwoordig op hun PC's aansluiten. Nog veel te weinig webontwikkelaars houden er rekening mee dat steeds meer mensen internetten via hun smartphone.

Als de website door Microsoft, Google of Amazon wordt gehost, al dan niet via CloudFlare, Fastly etc. dan heb je ook nul,nul privacy. Ik kon het gisteravond niet laten:

Daar waarschuwde ik ook voor, zie punt 4). Op zich vind ik het een goed idee dat je kunt zien wat je precies geschreven hebt, en hoe dat is overgekomen.

Ik heb er nauwelijks over nagedacht, maar wellicht zou er in de bevestigingsmail niet een kopie van de tekst, maar een link (met een op basis van een CSPRNG gegegereerde GUID o.i.d.) kunnen staan naar een pagina met jouw reactie zoals ontvangen, en pas op die pagina daarbij een knop "verzend als e-mail".

Inderdaad, en het ontgaat mij waarom je dat zou doen (als er een goede reden voor is, waarschuw daar dan vóóraf voor - dat dan, zodat ik me niet als een niet serieus genomen malloot voel).

Aangezien '<' en '>' niet worden geblokkeerd, sluit ik (stored) XSS aanvallen niet uit, maar ik vond het te ver gaan om dat te proberen.

En als ze er wel rekening mee houden doen ze maar al te vaak weer net alsof dat grote desktop-beeldscherm niet meer is dan een smartphoneschermpje. Ik vind de manier waarop bijvoorbeeld transactieoverzichten van banken niet meer in tabelvorm staan maar als een lijstje dat veel minder informatie in een oogopslag geeft een forse achteruitgang.

De ergernis kan dus twee kanten op werken. In beide gevallen is het probleem dat voor een klein en een groot beeldscherm verschillende ontwerpkeuzes voor de schermlayout optimaal zijn maar men met één ontwerp klaar wil zijn omdat dat minder kost aan ontwikkeling en onderhoud.

Mij valt altijd op hoe makkelijk men vergeet dat deze automatisering fysieke vestigingen en het personeel daarvoor heeft uitgespaard. Het is geen kostenpost om een goede interface voor iedereen neer te zetten, het zou de besparing wat kleiner maken, maar het is nog steeds een besparing, een kostenreductie.

Bijvoorbeeld: https://keyed.de/blog/google-recaptcha-dsgvo/

Dat heeft te maken met het scherm, niet met de browser.
In de CSS is het relatief simpel om de browser het scherm te laten indelen.

Daar is een eenvoudig antwoord op: de email die jij stuurt wordt in een of ander webplatform weergegeven aan de ontvanger, dus de 'opmaak' van jouw email wordt omgezet naar HTML. Een CR/LF wordt vervangen door een <br /> (line break).

De kopie van de email die ter bevestiging naar jou toe wordt gestuurd, wordt uit veiligheids- en praktische overwegingen gestript van alle HTML (platte tekst wordt altijd correct weergegeven, HTML-weergave kan nogal eens wisselen tussen mailprogramma's of -platforms). Daarmee gaan dus ook de line-breaks verloren en krijg je in jouw email dus één lopende tekst te zien. Dat is doorgaans niet dezelfde weergave die de ontvanger voor zich krijgt.

De karakters < en > worden overigens omgezet naar de expliciete karakters &lt; en &gt; (lower than en greater than) en blijven visueel bewaard, maar worden niet langer verwerkt als HTML-code.

Dit is echt al heel lang niet meer het geval. Mobile-first en responsive webdesign waren meer dan tien jaar geleden al de grote toverwoorden en zijn echt heel erg standaard heden ten dage. Zo'n beetje alleen waar er nog gebruik gemaakt wordt van hele oude platformen of gespecialiseerde omgevingen waar smartphones/tablets geen factor zijn, vind je nog websites die niet goed schalen.

Wel geldt dat er een aantal dingen zijn die op mobiele browsers soms niet (goed) ondersteund worden, of waar het lastig is om inhoud op groot formaat naar een klein scherm te schalen. Voor wat betreft de resize property zoals op een textarea geldt, de ondersteuning in browsers is als volgt: https://caniuse.com/css-resize.

Ik stuurde helemaal geen e-mail.

Vooruit, "het bericht dat je via het webformulier hebt verstuurd en waarvan je graag had gewild dat je het als een e-mail had kunnen versturen."

E-mail kost de betreffende organisatie teveel tijd=geld.
Zo simpel is het:
"digitaliseren" moet natuurlijk niet meer geld kosten dan het oplevert voor het betreffende bedrijf.
Geen "ordinair" maar 'functioneel' machtsmisbruik dus,
maar zeker nogal wrang bij organisaties die niet (meer) aan gewone brieven doen.

Zie zegt dat dit een email is richting het bedrijf?

Kans is groot, dat dit een API gaat voor verdere verwerking.

Toevallig krijg ik net een bounce op een ingevuld webformulier. Ik heb een Ziggo mail adres gebruikt bij het invullen en kreeg ook netjes per omgaand een reply op mijn mailadres dat het formulier ontvangen was.

Maar daarna ging het mis. Ik kreeg van <postmaster@hun-domein.nl> een bounce mailtje met de melding:


en daarnaast de inhoud van de oude header in de mail zelf. met o.a. het volgende stuk:


Het lijkt erop dat mijn ingevulde webformulier intern doorgestuurd wordt met mijn mail adres als afzender. En dan klopt het oude afzend IP niet meer. (Bij een webformulier is er zelfs geen afzend IP) Ziggo gebruikt een DMARC policy van "reject" en dus bounced hun mailserver dit 'gespoofde' mailtje omdat het natuurlijk niet door ziggo verzonden is.

Het ergste is dat ze aangeven dat het druk is en het 6 tot 8 week kan duren voordat er een reply komt. Waarschijnlijk kan het tot eeuwig duren als deze interne mail hun enige manier is om verder te gaan met het webformuier. Gespoofde mail doorsturen komt zo amateuristisch over. Het verbaast me dat zoiets anno 2024 nog gebeurd.

@Briolet: dank!